개발 관련78 6. 객체와 자료 구조 자료 추상화 자료를 세세하게 공개하기보다는 추상적인 개념으로 표현하는 것이 좋다. 인터페이스나 조회/설정 함수만으로는 추상화가 이뤄지지 않는다. 개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다. 아무 생각 없이 조회/설정 함수를 추가하는 방법이 가장 나쁘다. 자료/객체 비대칭 객체와 자료 구조는 근본적으로 양분된다. 객체 지향 코드에서 어려운 변경은 절차적인 코드에서 쉬우며, 절차적인 코드에서 어려운 변경은 객체 지향 코드에서 쉽다. 복잡한 시스템을 짜다보면 새로운 함수가 아니라 새로운 자료 타입이 필요한 경우가 생기는데, 이 때는 클래스와 객체 지향 기법이 가장 적합하다. 반면, 새로운 자료 타입이 아니라 새로운 함수가 필요한 경우도 있는데, 이 때는 절차적인 자료 구조.. 2022. 7. 13. 5. 형식 맞추기 형식을 맞추는 목적 오늘 구현한 기능이 다음 버전에서 바뀔 확률은 매우 높다. 그리고 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 오랜 시간이 지나 원본을 찾기 힘들정도로 코드가 변해도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 계속 영향을 미친다. 적절한 행 길이를 유지하라 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다. (그만큼 모듈화가 되어있다는 뜻) 일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다. 신문 기사처럼 작성하라 최상단에 기사를 몇 마디로 요약하는 표제가 나온다. 독자는 표제를 보고서 기사를 읽을지 말지 결정한다. 첫 문단은 전체 기사 내용을 요약한다. 세세한 사실은 숨기고 커다란 그림을 보여준다. 쭉 읽으며 내려가면 세세한 사실이 조금씩.. 2022. 7. 13. 4. 주석 나쁜 코드에 주석을 달지 마라. 새로 짜라 주석은 나쁜 코드를 보완하지 못한다. 코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다. 주석을 달기보단, 그 코드를 깔끔하게 개선하는데에 시간을 투자해라. 코드로 의도를 표현하라! if(employee.isEligibleForFullBenenfits() 같이 주석을 대신해 함수로 충분히 표현이 가능하다. 좋은 주석 하지만 어떤 주석은 필요로 한다. 그 주석의 종류를 열거하자면, 법적인 주석 - 회사가 정립한 구현 표준에 맞춰 법적인 이유로 특정 주석을 넣는 경우 정보를 제공하는 주석 - 기본적인 정보를 주석으로 제공하면 편리함. 혹은 파라미터 등에서 어떤 포멧인지 (하지만, 필수는 아님. 함수명을 변경함으로 충분히 대체 가능) 의도를 설명하는.. 2022. 7. 13. 3. 함수 작게 만들어라 중첩 구조가 생길만큼 함수가 커져서는 안된다는 뜻이다. 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안 된다. 당연한 말이지만, 그래야 함수는 읽고 이해하기 쉬워진다. 한 가지만 해라 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. 함수 당 추상화 수준은 하나로 함수가 확실히 한 가지 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다. 한 함수 내에 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈린다. 특정 표현이 근본 개념인지, 아니면 세부사항인지 구분하기 어려운 탓이다. 그리고 구분하기 어려워지면 세부사항에 세부사항을 더 붙이는 복잡한 함수가 된다. 위에서 아래로 내려가기 규칙 코드는 위에서 아래로 이야기처럼 읽혀야 좋다. 한 .. 2022. 7. 13. 2. 의미 있는 이름 의도를 분명히 밝혀라 로직이 간단한 것보단, 이름이 간단 명료한 것이 좋다. 그릇된 정보를 피하라 유사한 개념은 유사한 표기법을 사용한다. 일관성이 떨어지는 표기법은 그릇된 정보이다. 개발자는 대부분 (객체에 달린 상세한 주석이나 제공하는 다른 목록을 보고 선택하기 보다는 이름만 보고 객체를 선택하는 경우가 대다수이다.) 의미있게 구분하라 customerInfo 와 customer / accountData 와 account 는 구분이 가지 않는다. 읽는 사람이 차이를 알도록 이름을 지어라. 발음하기 쉬운 이름을 사용하라 genymdhms (generate date, year, month, day, hour, minute, second) 라는 단어의 조합은 발음하기도 어렵고, 토론하기도 어렵다. 검색하기 .. 2022. 7. 13. 1. 깨끗한 코드 코드가 존재하리라 어느 수준에 이르면 코드의 도움 없이 요구사항을 상세하게 표현하기란 불가능 하기에 코드가 사라질 가망은 없다. 궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심 나쁜코드 나쁜 코드에 발목이 잡혀 고생한 기억은 많다. 실제로 고행이라는 이름도 있다. 어째서 나쁜 코드를 짰는가? -> 당장 급해서, 서두르느라 자신이 짠 쓰레기 코드를 쳐다보며 나중에 고쳐야겠다고 생각한다. But, 나중은 오지 않는다. (르블랑의 법칙) 나쁜 코드로 치르는 대가 나쁜 코드는 개발 속도를 크게 떨어뜨린다. -> 코드를 고칠 때마다 엉뚱한 곳에서 문제가 생기기 때문 -> 결국 생산성이 0에 수렴 -> 재설계를 시작 -> 기존의 것을 100% 수용하지 않으면 관리층에서는 대체하려고 하지 않을 것이고, 오.. 2022. 7. 13. 이전 1 ··· 10 11 12 13 다음