고오급 개발자가 되는길

하나의 시스템을 만드는데 있어 모든 소프트웨어를 직접 개발하는 경우는 드물다. 외부 API 혹은 라이브러리를 사용할 수도 있으며 단순히 DB접근을 하더래도 흔히 다른 소프트웨어를 사용하곤 한다. 이러한 외부 코드를 우리의 코드에게 깔끔하게 통합해야할 필요가 있다. 외부코드 사용하기 인터페이스 제공자는 많은 사람들이 인터페이스를 사용하게 끔 많은 환경에서 돌아가게끔 하고, 사용자는 자신에게만 알맞는 인터페이스를 찾기 원한다 이에 따른 시스템 경계에 따른 문제들이 있는데 대표적인 예로 Map 이 있다. Map 같은 경우는 누가 선언을 했던 지우는 권한은 누구에게나 있으며 key 값을 자유로이 선언할 수 있어 어떠한 객체든 추가 할 수도 있다. 이렇게 되면 사용자가 사용함에 있어 혼돈이 있을 수 있고 어떻게 ..

상당수 코드 기반은 전적으로 오류 처리 코드에 좌우된다. 하지만 오류처리에 몰두한 나머지 기존 로직에 대해 이해도를 떨어트리고 오히려 더 복잡한 예외 처리는 더러운 코드로 가는 지름길이 된다. 그러기에 오류를 처리하는 기법과 고려사항 몇가지를 서술 해보도록 하겠다. 오류코드보다 예외를 사용하라 단순히 로깅 같은 기능들을 이용하여 오류코드를 남기는 것보다 예외를 던져서 어떠한 오류 사항인지 확인하는 것이 좋다. 오류를 처리하는 부분 (catch 와 같이)과 사용되는 로직을 분리하여 코드가 같이 섞이지 않을 수 있기 때문이다. Try-Catch_Finally 문 부터 작성하여라 예외가 발생할 코드를 짤 때는 Try-Catch_Finally 문으로 시작하는 것이 좋다. 그러면 try블록에서 무슨일이 생기든지 ..

변수를 private으로 선언 하더라도 각 값마다 조회 함수와 설정 함수 (getter, setter) 함수를 제공 한다면 구현을 외부로 노출하는 셈이 되므로 변수에 대한 정보를 함수로 표현한다고 해서 구현을 감추는것은 되지 않는다. 그러하여 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스이다. 자료를 세세하게 공개하기 보다는 추상적인 개념으로 표현하는 편이 좋다 새로운 함수보다 새로운 자료 타입이 필요한 경우는 클래스와 객체 지향 기법이 적합하며, 새로운 자료타입이 아니라 새로운 함수가 필요한 경우는 절차적인 코드와 자료구조가 좀 더 적합하다. 디미터 법칙 모듈은 자신이 조작하는 객체의 속 사정을 몰라야 한다는 법칙 즉, 객체는 조회 함수로 내부 ..

코드의 형식은 의사소통의 일환이다. 오늘 구현한 코드는 다음날 바뀔 확률이 매우 높다 그러하여 형식을 잘 맞춰 놓은 코드는 가독성이 좋아 유지보수 용이성과 확장성에 계속하여 영향을 미치게 된다. 형식을 맞추는 방법 1. 적절한 행 길이를 유지하라 통계에 따르면 대부분 500줄을 넘지 않으며 200줄 정도로 파일을 유지하는 시스템이 시스템을 더 이해하기 쉬웠다고 한다 2. 신문 기사처럼 작성하라 신문기사처럼 이름은 간단하면서도 설명이 가능하게 짓도록 하고 상단에서 고차원 개념을 설명하고 아래로 내려갈 수록 의도록 세세하게 묘사하며 마지막에는 가장 낮은 차원의 함수와 세부내역을 나타내는것이 바람직 하다 무작위적인 순서보다 형식에 맞춘 순서에 따라 코드를 작성하라 3. 개념은 빈 행으로 분리하라 생각 사이는..

주석은 때때로는 코드에 대한 부연 설명을 해주는 기능을 가지고는 있지만 시간이 지나면서 코드가 의도한 바가 아닌 내용을 부연 설명 할 수 있는 경우가 있다. 이와같이 부정확한 주석보다 차라리 없는 주석이 더 나으며 코드에다가 내용을 알기 쉽게 표현하는것이 더 중요하다. 하지만 가끔은 주석으로 표현할 수 있는 표기들이 있는데 이에 대하여 정리하여 보겠습니다. 좋은 주석 1. 법적인 주석 회사가 정립한 구현 표준에 맞춰 법적인 이유로 특정 주석을 넣어야 할 때 명시하는 주석 2. 의도를 설명하는 주석 코드를 작성함에 따라 결과는 동일하게 나타내지만 내부 구현에 따른 각자마다 차이점이 있을 수 있고 어떠한 의도로 내부 구현을 했는지 의도를 작성하는 의미로 쓰일 수 있다. 3. 의미를 명료하게 밝히는 주석 표준..

함수를 만드는 규칙 1. 작게 만들어라 함수의 코드 길이는 20줄 이내로 작성해야하며 최대한 적은 수의 줄로 이루어 지는 것이 좋다. 그렇기에 함수 하나가 단 한가지의 기능만을 하도록 선언해주는 것이 좋다. 단 한가지 기능이라는 것이 애매할 수 있다 적정한 추상화 수준이 하나인 단계만 수행하는것이 좋고 그 안에서 의미없는 기능 나누기는 필요가 없다. 2. 위에서 아래로 코드 읽기 : 내려가기 규칙 코드는 위에서 아래로 이야기처럼 읽혀야 좋으며 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수를 호출한다. 필자가 생각한 한 단계 낮은 함수는 한 기능을 담당하는 public 함수가 있다면 그 안에서 추상화 수준이 한 단계 낮은 함수를 만들어 private 함수를 바로 밑에다가 작성하는 규칙이라 생각한다. ..

코드를 작성함에 있어 변수, 함수, 인수, 파일, 클래스 등 많은 곳에 이름을 지정해야 하는 경우가 있다. 이름만 잘 지어도 해당 용도를 파악하는데에 크게 도움을 줄 수 있다. 의도를 분명히 밝혀라 의도가 분명하게 이름을 지어라 코드를 읽는 다른 사람이 코드를 보고 어떠한 의도로 사용했는지 쉽게 알게끔 EX) int d => int daysSinceCreateion, theList => gameBoard 해당 이름이 충분한 정보를 제공할 수 있도록 명명하라 그릇된 정보를 피하라 1. 다른 시스템에서 널리 사용하고 있는 의미를 가진 이름을 사용하지 말라 2. List, Data, Info 등 주요단어에 추가하여 애매한 의미를 나타내고 있는 단어를 사용하지 말라 3. 흡사한 이름을 사용하지 않도록 주의하라 ..

르블랑의 법칙(Leblanc’s Law) - 나중은 결코 오지 않는다 업무의 일정, 예상치 못한 이슈들로 나중에 코드를 수정하겠다는 마음가짐으로 코드를 작성하게 된다면 르블랑의 법칙을 떠올려라 나쁜 코드로 계속 진행된다면 추후에 발생하는 나쁜 코드는 더욱 더 많이 양산된다. 원초적 난제 기한을 맞추기 위해서는 나쁜 코드를 양산하기 쉽지만, 결과적으로 봤을 때는 오히려 나쁜 상태로 속도가 더 느려지게 된다. 오히려 빨리가는 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다. 깨끗한 코드란? 1. 보기에 즐거운 코드 - 다른 사람이 코드를 보는 사람에 있어서 보기에 쉽고 즐거운 코드를 생산하라 2. 철저한 오류처리 - 오류 처리 부분을 확실히 하며, 세세한 사항까지 꼼꼼히 처리하라 3. 가독성이 좋은..