12Dev

📋 목차. 9. 단위 테스트 .TDD 법칙 세 가지 .깨끗한 테스트 코드 유지하기 .테스트는 유연성, 유지보수성, 재사용성을 제공한다. .깨끗한 테스트 코드 .테스트 당 assert 하나 .테스트 당 개념 하나 .F.I.R.S.T .결론 ✔️ 내용. 9. 단위 테스트 제대로 된 테스트 케이스를 작성하는 방법 .TDD 법칙 세 가지 TDD는 실제 코드를 짜기 전에 단위 테스트부터 짜라고 요구한다. 단위 테스트를 짜는데 중요한 세 가지 법칙이 있다. 1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 위 세 가지 규칙을 따르면 개발과 테스..

📋 목차. 8. 경계 .외부 코드 사용하기 .경계 살피고 익히기 .학습 테스트는 공짜 이상이다. .아직 존재하지 않는 코드를 사용하기 .깨끗한 경계 ✔️ 내용. 8. 경계 시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다. 패키지를 사기도 하며 오픈소스를 이용한다. 사내 다른 팀이 제공하는 컴포넌트를 사용하는 경우도 있다. 어떤 식으로든 외부 코드를 우리 코드에 깔끔하게 통합해야 한다. 이번 장에서는 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교를 살펴본다. .외부 코드 사용하기 자주 사용 Collections인 Map을 예로 보자 // 1 Map sensors = new HashMap(); Sensor s = (Sensor)sensors.get(sensorId); // 2 Map sen..

📋 목차. 7. 오류 처리 .오류 코드보다 예외를 사용하라 .Try-Catch-Finally 문부터 작성하라 .미확인(unchecked) 예외를 사용하라 .예외에 의미를 제공하라 .호출자를 고려해 예외 클래스를 정의하라 .Null을 반환하지 마라 .Null을 전달하지 마라 .결론 ✔️ 내용. 7. 오류 처리 깨끗한 코드와 오류 처리는 연관성이 있다. 상당수 코드 기반은 전적으로 오류 처리 코드에 좌우된다. 여기저기 흩어진 오류 처리 코드 때문에 실제 코드가 하는 일을 파악하기 어렵다는 의미이다. 오류 처리는 중요하다. 하지만 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다. .오류 코드보다 예외를 사용하라 if/else를 사용하여 특정 에러 발생 시 처리를 하기보..

📋 목차. 6. 객체와 자료구조 .자료 추상화 .자료/객체 비대칭 .디미터 법칙 .집중 구조 .자료 전달 객체 .활성 레코드 .결론 ✔️ 내용. 6. 객체와 자료구조 변수를 비공개(private)로 정의하는 이유가 있다. 남들이 변수에 의존하지 않게 만들고 싶어서다. 그렇다면 조회(get) , 설정(set) 함수를 당연하게 공개(public)해 비공개 변수를 외부에 노출할까? .자료 추상화 변수 사이에 함수라는 계층을 넣는다고 구현이 저절로 감춰지지는 않는다. 구현을 감추려면 추상화가 필요하다. 그저 get/set 함수로 변수를 다룬다고 클래스가 되지 않는다. 그보다는 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다. 아래의 예제 모두 자료를 세세..

📋 목차. 5. 형식 맞추기 .적절한 행 길이를 유지하라 .신문 기사처럼 작성하라 .개념은 빈 행(줄 바꿈)으로 분리하라 .세로 밀집도 .수직 거리 .변수 선언 .인스턴스 변수 .종속 함수 .개념적 유사성 .가로 형식 맞추기 .가로 공백과 밀집도 .들여쓰기 무시하기 .팀 규칙 ✔️ 내용. 5. 형식 맞추기 코드 형식은 중요하다! 너무 중요해서 무시하기 어렵다. 너무 중요하기 때문에 융통성 없이 맹목적으로 따르면 안 된다. 코드 형식은 의사소통의 일환이다. 의사소통은 전문 개발자의 일차적인 의무다. 어쩌면 '돌아가는 코드가'가 전문 개발자의 일차적인 의무라 여길지도 모르지만 책을 읽으며 생각이 바뀌었기를 바란다. 오늘 구현한 기능이 다음 버전에서 바뀔 확률은 아주 높다. 그런데 오늘 구현한 코드의 가독성은..

📋 목차. 4. 주석 .좋은 주석 .나쁜 주석 ✔️ 내용. 4. 주석 주석이 필요한 상황마다 코드로 표현할 방법이 정말로 없는지 다시 한번 생각해본다. 주석은 오래도리수록 코드에서 멀어진다. 주석을 유지보수 하기란 현실적으로 어렵기 때문이다. 부정확한 주석은 없는 주석만 못하다. 코드만이 자기가 하는 일을 진실되게 말한다. 그러므로 주석을 가능한 줄이도록 꾸준히 노력한다. .좋은 주석 어떤 주석은 필요하거나 유익하다. 하지만 정말로 좋은 주석은, 주석을 달지 않는 방법이라는 것을 명심한다. - 법적인 주석 때로는 회사가 정립한 구현 표준에 맞춰 법적인 이유로 특정 주석을 넣으라고 명시한다. // Copyright (C) 2003,2004,2005 by Object Mentor, Inc, All right..

📋 목차. 3. 함수 .작게 만들어라! .한가지만 해라! .위에서 아래로 코드읽기:내려가기규칙 .서술적인 이름을 사용하라. .함수 인수 .많이 쓰는 단항 형식 .플래그 인수 지양 .인수 객체 .인수 목록 .동사와 키워드 .부수 효과를 일으키지 마라!. .출력 인수 .명령과 조회를 분리하라. .오류 코드보다 예외를 사용하라!. .try/catch 블록 뽑아내기 .Error.java 의존성 자석 .반복하지 마라. .함수를 어떻게 짜죠? .결론 ✔️ 내용. 3. 함수 .작게 만들어라! 함수를 만드는 첫째 규칙은 '작게!'이다. 블록과 들여 쓰기, if/else, while 문 등 블록은 한 줄이야 하는 의미다. 그러면 바깥을 감싸는 함수가 작아질 뿐 아니라, 블록 안에서 호출하는 함수 이름을 적절히 짓는다면,..

📋 목차. 2. 의미 있는 이름 .의도를 분명히 밝혀라 .그릇된 정보를 피해라 .의미 있게 구분하라 .발음하기 쉬운 이름을 사용하라 .클래스, 객체 이름 .메서드 이름 .해법/문제 영역에서 가져온 이름을 사용하라. ✔️ 내용. 2. 의미 있는 이름 이름을 잘 짓기 위한 몇 가지 규칙 소개 .의도를 분명히 밝혀라 변수나 함수, 클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야 한다. 존재 이유 수행 기능 사용 방법 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다. int d; // 경과 시간(단위: 날짜) // 이름 d는 아무 의미도 드러나지 않는다. 측정하려는 값과 단위를 표현하는 이름이 필요하다. int elapsedTimeInDays; int daysSinceCreation; int..

📋 목차. 0. 들어가면서 .5S 원칙 1. 깨끗한 코드 .르블랑의 법칙 .깨끗한/나쁜 코드란 .단순 코드 규칙 구현의 중요 순서 .중복 제거와 표현력에 집중하기 위한 아이디어 .작게 추상화 하기 .보이스카우트 규칙 ✔️ 내용. 0. 들어가면서 대다수의 프로그래머의 활동은 80% 이상이 유지보수라고 볼 수 있다. 유지보수에 초점을 맞춘 TPM(Total Productive Management) 품질 관리론이 등장하게 되었는데 TPM을 지탱하는 기둥 하나인 5S 원칙은 다음과 같다. 원칙 내용 정리(Seiri) or 조직(정렬(Sort)) 적절한 명명법 등과 같은 방법을 사용해 무엇이 어디에 있는지 알아야 한다. 정돈(Seidon) or 단정함(체계화) 코드는 누구나 예상하는 위치에 있어야 한다. 그렇지 ..

❓ 책 정보. 저자 : 로버트 C. 마틴 『Clean Code(클린 코드)』은 오브젝트 멘토(Object Mentor)의 동료들과 힘을 모아 ‘개발하며’ 클린 코드를 만드는 최상의 애자일 기법을 소개하고 있다. 소프트웨어 장인 정신의 가치를 심어 주며 프로그래밍 실력을 높여줄 것이다. 여러분이 노력만 한다면. 어떤 노력이 필요하냐고? 코드를 읽어야 한다. 아주 많은 코드를. 그리고 코드를 읽으면서 그 코드의 무엇이 옳은지, 그른지 생각도 해야 한다. 좀 더 중요하게는 전문가로서 자신이 지니는 가치와 장인으로서 자기 작품에 대한 헌신을 돌아보게 된다. ✏️ 선정 이유. - 깨끗한 코드를 작성하기 위해! 📋 진행 방식. - 주 마다 독서 후 정리 내용 발표 - 온라인 모임 - 모임 일 📝 계획. - 2022..