programming

서론오류를 나누는 기준은 여러가지가 있을 수 있습니다. 개발자의 관점에서 에러는 처리의 대상이며 상황에 따른 적절한 처리를 위해  소프트웨어가 계속 작동할 수 있는 오류와 작동할 수 없는 오류로 구분할 수 있습니다. 이 포스팅에서는 에러를 복구 가능에러와 복구 불가능 에러로 구분하고 각 에러의 처리 방식에 대한 이야기를 나눠보겠습니다. 복구 가능한 오류시스템 전체에 영향을 미칠만큼 치명적이지 않으며 호출하는 곳에서 오류를 복구하는 것이 합리적인 경우입니다.대표적인 예로 로그인폼에 패스워드를 잘못입력하는 경우가 있습니다. 이 경우 앱을 멈추는 대신에 사용자에게 다시 비밀번호 입력을 유도하는 것이 더 이상적입니다. 일반적으로 복구 가능한 오류의 예에는 다음과 같습니다. 1.네트워크 오류외부 서비스에 연결할 ..

서론 좋은 코드의 조건을 다양합니다. 하지만 "표현이 직관적이며 동작이 예상 가능한 코드"가 좋은 코드라는 것에는 이견이 없을 것이라 생각합니다. 동작이 예상 가능한 코드라는 표현을 달리 말하면 오용하기 어려운 코드라고 할 수 있습니다. 오늘 주제는 코드의 제약 조건에 의해 발생하는 오용 가능성과 이런 제약 조건을 핸들링해서 오용 가능성을 좁히는 내용입니다.(이 내용은 좋은 코드, 나쁜 코드에 수록된 내용을 정리한 것임을 밝힙니다.)  제약 조건이 있는 코드오용하기 쉬운 코드는 암묵적 제약 조건이 많은 코드라고 할 수 있습니다. 제약 조건에 대한 이해가 있어야 제대로 사용할 수 있는 코드라는 말은 자칫 잘못 사용되기 쉬운 코드라는 말이 됩니다. 다음의 예제를 통해 코드에서 발생하 수 있는 제약조건에 대해..

서론우리 모두는 단일 책임 원칙 (Single Responsibility Principle, SRP) 에 대해 이미 알고 있습니다.하나의 모듈은 하나의 책임만 가져야한다는 객체 지향 프로그래밍의 설계 원칙입니다. 너무 명쾌한 내용이기에 이 원칙을 공감하지 못하는 분은 없을겁니다. 하지만 그럼에도 불구하고 우리는 비대한 모듈을 만들곤 합니다. 왜 일까요? 바로 "하나의 책임"이라는 말이 가지는 모호함때문입니다. 과연 어디까지 책임의 범위로 취급해야 할까요? 커피를 만드는 과정으로 예를 들어보겠습니다. 1. 물을 끊인다.2. 원두를 갈아 넣는다.3. 물을 커피에 붓는다.4. 커피를 컵에 따른다. 커피를 만드는 과정을 위 4가지 단계로 나눠보겠습니다. 그러면 각 단계가 각각 하나의 책임일까요? 한번 딴지를 걸..