개인/책9 [개발] 소프트웨어 장인:프로페셔널리즘/실용주의/자부심 문제는 어린나이에 조금이라도 경험이 있으면 쉽게 오만해 진다는 것이다. 나 자신이 그렇게 잘난 사람이 아니라는 것과 배워야 할 게 아직 많음을 알았다. 그리고 겸손해져야 한다는 것도. 일을 끝내는 것 자체로는 부족하다는 것. 그 일을 어떻게 하느냐가 더 중요하다는 것, 특히 팀에서 일할 때는 더욱 그러하다는 것을 배웠다. 나의 동료와 클라이언트를 존중하고, 형편없는 코드를 남겨서는 안된다는 것을 알았다. 2018. 1. 12. [클린코드] 시스템, 창발성 시스템 시스템은 역시 깨끗해야 한다. 깨끗하지 못한 아키텍처는 도메인 논리를 흐리며 기민성을 떨어뜨린다. 도메인 논리가 흐려지면 제품 품질이 떨어진다. 버그가 숨어들기 쉬워지고, 스토리를 구현하기 어려워지는 탓이다. 기민성이 떨어지면 생산성이 낮아져 TDD가 제공하는 장점이 사라진다. 모든 추상화 단계에서 의도는 명확히 표현해야 한다. 그러려면 POJO를 작성하고 관점 혹은 관점과 유사한 메커니즘을 사용해 각 구현 관심사를 분리해야 한다. 시스템을 설계하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자. 창발성 켄트 벡이 제시한 단순한 설계 규칙 네가지 - 모든 테스트를 실행하라 - 중복을 없애라 - 프로그래머의 의도를 표현하라 - 클래스와 메서드 수를 최소로.. 2015. 7. 2. [클린코드] 경계, 단위 테스트, 클래스 경계 외부 코드 사용하기 - 외부 코드 사용시에 클래스 변경에 대하여 주의하자 경계 살피고 익히기 - 외부 API 사용시 충분한 테스트를 거친다. 단위 테스트 TDD를 이용한 개발 테스트 코드는 실제 코드만큼 중요하다. 클래스 클래스는 작아야 한다. - 단일 책임 원칙(SRP) - 높은 응집도 변경이 쉬운 클래스 SRP (Single Responsibility Principle) - 모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 함 - 하나의 서브시스템, 모듈, 클래스, 함수에 대해서도 한 가지 이상의 변경 이유가 있어서는 안 된다는 것 - https://arload.wordpress.com/2012/01/30/single-responsibility-princinple/ OC.. 2015. 7. 2. [클린코드] 오류처리 오류처리 오류 코드보다 예외를 사용하라. - 논리와 오류 코드가 뒤섞이지 않게 하라. Try-Catch-Finally 문부터 작성하라. 미확인 예외를 사용하라(런타임 익셉션을 사용하라.) - checked 익셉션이 제공하는 장점보다는 단점이 더 많다. 예외에 의미를 제공하라. 호출자를 고려해 예외 클래스를 정의하라. - 외부 API를 이용할 때 래퍼(Wrapper) 클래스를 이용하여 의존성을 줄여준다. 정상 흐름을 정의하라. - 특수 사례 패턴을 이용하여 예외적인 상황을 캡슐화해서 처리하도록 한다. n 반환할 값이 없을 때 익셉션을 던지지 않고, 기본값을 가진 객체를 반환하도록 한다. null을 반환하지 마라. - null 을 반환하기 보다는 예외를 던지거나 특수 사례 객체를 반환한다. null을 전달하.. 2015. 7. 2. [클린코드] 객체와 자료 구조 객체와 자료 구조 자료 추상화 - 자료를 세세하게 공개하기보다는 추상적인 개념으로 표현하는 편이 좋다. - 개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다. - 아무 생각 없이 조회/설정 함수를 추가하는 방법이 가장 나쁘다. God Bad public interface Point { double getX(); double getY(); void setCartesian(double x, double y) double getR(); double getTheta(); void setPolar(double r, double theta ) public class Point { public double x; public double y; } public interface Veichl.. 2015. 7. 2. [클린코드] 형식 맞추기 형식 맞추기 형식을 맞추는 목적 - 코드는 의사소통의 일환이다. 적절한 행 길이를 유지하라. 신문 기사처럼 작성하라. - 제목(함수명)만 보고 내용을 상상할 수 있도록 개념은 빈 행으로 분리하라. 팀규칙에 따르라. 어쩌면 돌아가는 코드'가 전문 개발자의 일차적인 의무라 여길지도 모르겠다. 오늘 구현한 기능이 다음 버전에서 바뀔 확률은 아주 높다. 그런데 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바뀌어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. 원래 코드는 사라질지라도 개발자의 스타일과 규율은 사라지지 않는다. 2015. 7. 2. [클린코드] 주석 주석 주석은 나쁜 코드를 보완하지 못한다. 코드로 의도를 표현하라! 좋은 주석 - 법적인 주석 - 정보를 제공하는 주석 - 의도를 설명하는 주석 - 의미를 명료하게 밝히는 주석 - 결과를 경고하는 주석 - 중요성을 강조하는 주석 나쁜주석 - 주절거리는 주석 - 같은 이야기를 반복하는 주석 - 오해할 여지가 있는 주석 - 의무적으로 다는 주석(javadoc의 모든 변수에 다는 주석) - 이력을 기록하는 주석 - 있으나 마나 한 주석 - … 2015. 7. 1. [클린코드] 함수 함수 작게 만들어라. 한 가지만 해라. - 함수는 한 가지를 해야 한다. 그 한가지를 잘 해야 한다. 그 한가지 만을 해야 한다. 함수당 추상화 수준은 하나로!(추상화 수준이 동일하여야 한다.) - getHtml() 은 추상화 수준이 높다. - String pagePathName = PathParser.render(pagepath); 는 추상화 수준이 중간 - str.append(“\n”) 는 추상화 수준이 낮다. 위에서 아래로 코드 읽기 - 코드는 위에서 아래로 이야기처럼 읽혀야 한다. switch 문은 추상화해서 사용 - 길어진 switch 문은 추상 팩토리 패턴으로 대체하는 방법을 연구 서술적인 이름을 사용하라. 함수 인수는 작을수록 좋다. 부수 효과를 일으키지 마라. - 한가지 작업만 하라. 명령.. 2015. 7. 1. [클린코드] 의미 있는 이름 클린코드(로버트 C.마틴) 요약 의미 있는 이름 의도를 분명하게 밝혀라 Bad Good int d; int elapsedTimeInDays; int daysSinceCreation; 그릇된 정보를 피하라 의미 있게 구분하라 - sourceFile, destinationFile 등 발음하기 쉬운 이름을 사용하라. 검색하기 쉬운 이름을 사용하라. - i, j, k 등과 같이 search 힘든 이름은 피하라. 자신의 기억력을 자랑하지 마라. 클래스 이름은 명사, 명사구로 메소드 이름은 동사, 동사구로 기발한 이름은 피하라. 한 개념에 한 단어를 사용하라. - fetch, retrieve, get 등 제각각 부르면 혼란스러움 2015. 6. 30. 이전 1 다음