Software Engineering Note

객체와 자료- 객체는 비공개 자료를 가지고 있고, 자료를 제어하는 함수를 제공- 자료는 공개 변수만을 가짐 자료를 세세하게 공개하기보다는 추상적인 개념으로 표현하는 편이 좋다.인터페이스나 조회/설정 함수만으로는 추상화가 이뤄지지않는다.개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다.아무 생각 없이 조회/설정 함수를 추가하는 방법이 가장 나쁘다. 객체와 자료구조는 근본적으로 양분된다.- 객체지향 코드에서 어려운 변경은 절차적인 코드에서 쉽다. (기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다!)- 절차적인 코드에서 어려운 변경은 객체 지향 코드에서 쉽다. (기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다!) => 다형성을 이용한 경우 interface에..

프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야한다.- 간단한 규칙을 정하고 따라야 한다.- 팀이 합의해 규칙을 정하고 모두가 따라야 한다.- 규칙을 자동으로 적용하는 도구를 활용한다. 형식을 맞추는 목적- 의사소통이다.- 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드이 품질에 지대한 영향을 미친다. 적절한 행 길이를 유지해라 신문 기사처럼 작성하라 개념은 빈 행으로 분리하라- 빈 행은 새로운 개념을 시작한다는 시각적 단서다. 세로 밀집도- 서로 밀접한 코드 행은 세로로 가까이 놓여야 한다. 수직거리- 서로 밀접한 개념은 세로로 가까이 둬야 한다.- 연관성이 깊은 두 개념이 멀리 떨어져 있으면 코드를 읽는 사람이 소스 파일과 클래스를 여기저기 뒤지게 된다. 변수선언- 사용하는 위치에 최대한 가까이 인스턴..

우리는 코드로 의도를 표현하지 못해, 실패를 만회하기 위해 주석을 사용한다. 주석이 필요한 상황에 처하면 곰곰이 생각하기 바란다. => 상황을 역전해 코드로 의도를 표현할 방법은 없을까? 주석은 나쁜 코드를 보완하지 못한다. 좋은 주석 (그나마 남아있어도 되는 주석?)- 법적인 주석- 정보를 제공하는 주석- 의도를 설명하는 주석- 의미를 명료하게 밝히는 주석- 결과를 경고하는 주석- TODO 주석- 중요성을 강조하는 주석 (자칫 대수롭지 않다고 여겨질 뭔가의 중요성을 강조하기 위해)- 공개 API에서 Javadocs 나쁜 주석(대다수 주석...)- 주절거리는 주석- 같은 이야기를 중복하는 주석- 오해할 여지가 있는 주석- 의무적으로 다는 주석- 이력을 기록하는 주석 (코드관리 시스템에 맡기자)- 있으나 ..

작게 만들것! 블록과 들여쓰기- if / else / while 문 등에 들어가는 블록은 한 줄이어야 한다.- 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안된다. 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한가지만을 해야 한다!! 의미있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다. 한 함수 내에 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈린다. => 사람들이 함수에 세부사항을 점점 더 추가한다.- 한 함수에 다른 함수를 호출하는 부분도 들어있고, 다른 함수에서 해야할 일을 하는 부분도 섞여있는 경우 내려가기 규칙- 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아진다. switch문 => 다형성을 이용한다. 서술적..

이름 짓기에 대한 장 의도를 분명이 밝혀라 - 존재이유는? 수행기능? 사용방법은?- 주석이 필요없게끔, 주석을 넣을거면 그냥 변수 이름을 잘 지어라 문제는 코드의 단순성이 아니라 코드의 함축성이다. - 코드 자체에 맥락이 명시적으로 드러나도록 할 것 그릇된 정보는 피할 것 - 실제 컨테이너가 List가 아니라면 xxxList와 같은 이름은 피한다. => 개발자가 List로 오해할 수 있음- 실제 컨테이너가 List인 경우라도 컨테이너 유형을 이름에 넣지않는 것이 좋다. 읽는 사람이 차이를 알도록 이름을 지어라 발음하기 쉬운, 검색하기 쉬운 이름을 사용하라 (ex: 대문자로 정의하는 상수, MAX_NUM 같은) 인코딩을 피하라 - 여기서 인코딩은 뭔가 의미를 내포한 축약형 글자따위를 의미한다.- 헝가리식 ..

르블랑의 법칙 - 나중은 결코 오지않는다. - 맞다. 나쁜 코드가 보이는대로 바로바로 수정하자. 나중은 없다. 나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. 좋은 코드를 사수하는 일은 프로그래머들의 책임이다.나쁜 코드의 위험을 모르는 관리자의 말을 그대로 따르는 행동은 전문가답지 못하다. - 시간이 들더라도 코드에 더 신경을 써야겠다. 기한을 맞추는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관이다. - 잘만되면 정말 맞는 말 같다. 하나 둘 눈감기 시작하면 그 양이 방대해지리라. 깨끗한 코드와 나쁜 코드를 구분하는 능력?열쇠는 '코드감각' 이다. 어떤 사람은 타고나고, 어떤 사람은 투쟁해서 얻어야한다. - 이건 좀 슬픈데 ㅠㅠ 그래도 노력하면 얻을 수 있고, 그래서 많은 책들도 나오지않았던가..

깨끗한 코드를 잘 만들기 위한 시작! 코드리뷰 할 때 들었던 커맨트의 진정한 의미를 깨닫고 싶었고, 나도 느낌이 아닌 지식에 기반한 이야기를 하고싶었다. 언젠가는 스터디를 하고싶었는데 팀원 중 한분이 시동을 걸어서 나도 참여했다. Clean Code(클린 코드)저자로버트 C. 마틴 지음출판사인사이트 | 2013-12-24 출간카테고리컴퓨터/IT책소개나쁜 코드도 돌아는 간다. 하지만 코드가 깨끗하지 못하면 개발 ... 이것이 교재.. 사내에도 스터디 자료가 있어서 함께 활용하기로 했다. 굿럭! :)