Jiyong Park Jiyong Park

변수를 비공개(private)로 정의하는 이유가 있다. 남들이 변수에 의존하지 않게 만들고 싶어서다. 충동이든 변덕이든, 변수 타입이나 구현을 맘대로 바꾸고 싶어서다. 그렇다면 어째서 수많은 프로그래머가 조회(get) 함수와 설정(set) 함수를 당연하게 공개(public)해 비공개 변수를 외부에 노출할까? 자료 추상화(119.p) 구현을 감추려면 추상화가 필요하다! 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다. 아무 생각 없이 조회/설정 함수를 추가하는 방법이 가장 나쁘다. 자료/객체 비대칭 객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다. 자료 구조는 자료를 그대로 공개하여 별다른 함수는 제공하지 않는다.

1. 형식을 맞추는 목적 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바뀌어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확정성에 계속 영향을 미친다. 2. 적절한 행 길이를 유지하라 3. 신문 기사처럼 작성하라 독자는 표제를 보고서 기사를 읽을지 말지 결정한다. 쭉 읽으며 내려가면 세세한 사실이 조금씩 드러난다. 소스 파일도 신문 기사와 비슷하게 작성한다. 이름은 간단하면서도 설명이 가능하게 짓는다. 아래로 내려갈수록 의도를 세세하게 묘사한다. 4. 세로 밀집도 서로 밀접한 코드 행은 세로로 가까이 놓여야 한다. 5. 수직 거리 함수 연관 관계와 동작 방식을 이해하려고 이..

나쁜 코드에 주석을 달지 마라. 새로 짜라. 잘 달린 주석은 그 어떤 정보보다 유용하다. 경솔하고 근거 없는 주석은 코드를 이해하기 어렵게 만든다. 오래되고 조잡한 주석은 거짓과 잘못된 정보를 퍼뜨려 해악을 미친다. 우리는 코드로 의도를 표현하지 못해, 그러니까 실패를 만회하기 위해 주석을 사용한다. 주석은 언제나 실패를 의미한다. 그러므로 주석이 필요한 상황에 처하면 곰곰이 생각하기 바란다. 상황을 역전해 코드로 의도를 표현할 방법은 없을까? 주석을 달 때마다 자신에게 표현력이 없다는 사실을 푸념해야 마땅하다. 주석은 오래될수록 코드에서 멀어진다. 오래될수록 프로그래머들이 주석을 유지하고 보수하기란 현실적으로 불가능 하기 때문에 완전히 그릇될 가능성도 커진다. 코드는 항상 변화하고 진화하기 때문에 주석..

1. 한 가지만 해라! 함수는 한 가지를 해야한다. 그 한 가지를 잘 해야한다. 그 한 가지만을 해야 한다. 지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 한다고 볼 수 있다. 2. 내려가기 규칙 코드는 위에서 아래로 이야기하는 것 처럼 읽혀야 좋다. 3. Switch문 47.p 참고 4. 서술적인 이름을 사용하라! 함수 이름이 길어도 어떤일을 하는지 더 잘 표현한 함수 이름이 훨씬 좋은 이름이다. 5. 깨끗한 코드 코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행하면 깨끗한 코드이다. 6. 함수 인수 함수에서 이상적인 인수는 0개(무항)이다. 다음은 1개이고, 그 다음은 2개이다. 3개는 가능한 피하는 편이 좋다. 4개 이상은 특별한 이유가 필요하다...

의도를 분명히 밝혀라 1. 이름이 정말로 중요하다. 2. 변수 혹은 함수나 클래스의 존재 이유, 수행 기능, 사용 방법이 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다. int d; //경과 시간(단위:날짜) 이름 d는 아무 의미도 드러나지 않는다. 경과 시간이나 날짜라는 느낌이 안든다. 측정하려는 값과 단위를 표현하는 이름이 필요하다. 의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다. 3. 23 페이지 참고 23 페이지의 코드 처럼 함수들에 의미 있는 이름들을 정해주고 코드의 전체적인 맥락을 보면 단순히 이름만 고쳤는데도 함수가 하는 일을 이해하기 쉬워졌다. 바로 이것이 좋은 이름이 주는 위력이다. 4. 그릇된 정보를 피하라 코드에 그릇된 단서를 남겨서는 안 된다. 그릇된 ..

프로그래머로써 가져야할 습관 1. 좋은 코드를 사수하는 일은 전적으로 프로그래머들의 책임이다. 2. 언제나 코드를 깨끗하게 유지하는 습관이다. 3. 나쁜 모듈을 보면 좋은 모듈로 개선할 방안을 떠 올려보려는 습관을 가지자 깨끗한 코드란? 1. 보기에 즐거운 코드 2. CPU 자원을 낭비하는 코드, 실행 속도가 느린 코드 3. 세세한 사항까지 꼼꼼하게 처리하는 코드 4. 한 가지를 잘 하는 코드 = 한가지에 '집중'한다. 5. 테스트 케이스가 없는 코드는 깨끗한 코드가 아니다. 6. 시간을 들여 주의깊게 깔끔하고 단정하게 정리한 코드 7. 켄트 백이 제안한 단순한 코드 규칙 7.1. 모든 테스트를 통과한다. 7.2. 종복이 없다.(집중) 7.3. 시스템 내 모든 설계 아이디어를 표현한다. 7.4. 클래스,..

서론 1. 소프트웨어의 기능이 점차 복잡해지면서 개발자를 더 많이 투입 2. 하지만 현실은 프로젝트에 투입된 개발자는 많아졌지만 소프트웨어를 개발하는 속도와 기능 추가 속도는 비례하지 않는다. 3. 새로운 기능을 추가하거나 버그 수정하면 다른 기능에서 버그가 새롭게 생겨나 상황이 더욱 나빠질 수 있습니다. 4. 즉 개발자가 버그를 관리하지 못하면서 소프트웨어는 신뢰성을 잃고, 사용자는 하나 둘 떠나기 시작한다. 5. 그래서 소프트웨어의 신뢰성을 높이기 위해서 개발자들은 소스코드를 이해하기 쉽게 만드려고 합니다. 6. 의식의 흐름대로 자연스럽게 읽혀서 소프트웨어가 어떤 동작을 하는지 쉽게 이해되는 코드가 좋다. 7. 이 글은 소프트웨어의 복잡성을 줄이기 위한 정리이다. DRY 원칙 1. 하나의 기능이 여러..