Software Engineering Note

https://www.coursera.org/course/algo 2013년에 들었던 수업.. 알고리즘 문제 푸는것에 관심이 있어 처음 들었던 수업이었다. 교과서를 읽는듯한 수업이 아니고 정말 머리속에 있는 지식을 펼쳐내는 듯한 강의에 감탄 했었지.. 프로그래밍 과제를 풀고 정답임을 확인할때는 어찌나 짜릿했던지.. Part2도 듣고자 하였으나 게으름으로 인해 아직까지 안듣고 있다. 언젠간 들어야지

(이 장에서는 주로 외부 라이브러리나 패키지를 사용하는 방법을 다룬다.) 외부코드 사용하기 wrapping 클래스를 만들어 제한된 메소드만을 제공하여 악용할 소지를 없앤다. Map과 같은 경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출이 되지 않도록 주의한다. (clear() 같은 메소드로 날릴 수도 있다.) Map 인스턴스를 공개 API의 인수로 넘기거나 반환 값으로 사용하지 않는다. 학습 테스트 외부코드를 이용할 때는 곧바로 우리쪽 코드에 반영해서 구현부터 하지말고 테스트부터 하자. (= 학습테스트) 학습 테스트에 드는 비용은 없다. 어쨌든 API를 배워야 한다. 오히려 필요한 지식만 확보하는 손쉬운 방법이다. (이해도를 높여주는 정확한 실험) 아직 존재하지 않는 코드사..

오류 코드보다 예외를 사용하라 오류 코드를 확인하는 방법은 호출자 코드를 복잡하게 만든다. (if result == YES.. 따위) 함수를 호출한 즉시 오류를 확인해야 하기 때문이다. 오류가 발생하면 예외를 던지는 편이 낫다. => 호출자 코드가 더 깔끔해진다. 논리가 오류 처리코드와 뒤섞이지 않는다. 미확인 예외를 사용하라 (RuntimeException 같은) 확인된 예외는 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 전부 고쳐야 한다. 최하위 함수를 변경해 새로운 오류를 던진다 -> 선언부에 throws 절 추가 -> 연쇄 수정 발생 결과적으로 최하위 함수에서 던지는 예외를 알아야 하므로 캡슐화가 깨진다! 예외에 의미를 제공하라 호출자를 고려해 예외 클래스를 정의하라 외부 API를 사..

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

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

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

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

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

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

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