클린코드 - 17.냄새와 휴리스틱
2022. 8. 15. 20:28
개발 서적/클린코드
1. 주석 - 부적절한 정보 변경 이력 등의 주석은 적절하지 못하다 소스 코드 관리 시스템, 버그 추적 시스템, 이슈 추적 시스템 등 다른 시스템에서 저장하도록 맡기자 - 쓸모 없는 주석 주석은 빨리 낡는다 쓸모 없어질 주석은 달지 않는 편이 가장 좋으며 쓸모 없어진 주석은 재빨리 삭제하는 편이 좋다 - 중복된 주석 코드만으로 충분한 경우 중복된 주석을 달지 않는다 i++; // i 증가 - 성의 없는 주석 문법과 구두점을 올바로 사용하고 간결하고 명료하게 작성한다 - 주석 처리된 코드 얼마나 오래된 코드인지 중요한 코드인지 아닌지 알 길이 없어진다 정말 필요하다면 소스 코드 관리 시스템(형상 관리 시스템)에서 이전 버전을 가져와 사용하면된다 2. 환경 - 여러 단계로 빌드하는 경우 빌드는 간단히 한 단..
클린코드 - 15.JUnit 들여다보기 & 16.SerialDate 리팩터링
2022. 8. 13. 21:14
개발 서적/클린코드
1. JUnit 프레임워크 Junit은 자바 프레임워크 중에서 가장 유명하다 테스트 코드 역시 좋은 구조가 필요하다 오히려 테스트 코드는 더욱 읽기 편해야 한다 2. 보이스카우트 규칙 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라 잘 짠 코드가 전부는 아니다 시간이 지나도 언제나 깨끗하게 유지해야 한다 한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다 변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if 문 하나를 정리하면 충분하다 3. 결론 세상에 개선이 불필요한 모듈은 없다 코드를 처음보다 조금 더 깨끗하게 만드는 책임은 우리 모두에게 있다 마무리 느낀 점 15장과 16장은 대부분 코드를 통해 설명되어있어서 정리할 내용이 많지 않았다 이..
클린코드 - 14.점진적인 개선
2022. 8. 13. 20:54
개발 서적/클린코드
1. 깨끗한 코드 프로그래밍은 과학보다 공예에 가깝다 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다는 의미다 2. 점진적으로 개선하라 프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위다 어떤 프로그램은 그저 그런 개선에서 결코 회복하지 못한다 개선 전과 똑같이 프로그램을 돌리기가 아주 어렵기 때문이다 변경 전후에 시스템이 똑같이 돌아간다는 사실을 확인하려면 언제든 실행 가능한 자동화된 테스트 슈트가 필요하다 단위 테스트와 인수 테스트를 활용하자 리팩터링을 하다보면 코드를 넣었다 뺐다 하는 사례가 아주 흔하다 단계적으로 조금씩 변경하며 매번 테스트를 돌려야 하므로 코드를 여기저기 옮길 일이 많아진다 리팩터링은 루빅 큐브 맞추기와 비슷하다 큰 목표..
클린코드 - 13.동시성
2022. 8. 13. 20:25
개발 서적/클린코드
객체는 처리의 추상화다. 스레드는 일정의 추상화다. - 제임스 O. 코플리엔 동시성과 깔끔한 코드는 양립하기 아주 어렵다 1. 동시성이 필요한 이유 정보를 대량으로 분석하는 시스템의 경우 정보를 나눠 병렬로 처리할 수 있다면 효율이 증가한다 - 동시성이 항상 성능을 높여주는 것은 아니다 동시성은 때로 성능을 높여준다 대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우에만 성능이 높아진다. 어느 쪽도 일상적으로 발생하는 상황은 아니다 - 단일 스레드 시스템과 다중 스레드 시스템은 설계가 판이하게 다르다 일반적으로 무엇과 언제를 분리하면 시스템 구조가 크게 달라진다 - 컨테이너 동작방식을 알아야 동시성을 사용할 수 있다 컨테이너..
클린코드 - 12.창발성
2022. 8. 12. 16:36
개발 서적/클린코드
창발성(創發性) 이란? 남이 모르거나 하지 아니한 것을 처음으로 또는 새롭게 밝혀내거나 이루어 내는 성질. 1. 창발적 설계로 깔끔한 코드를 구현하자 모든 테스트를 실행하라 중복을 없애라 프로그래머 의도를 표현하라 클래스와 메서드 수를 최소로 줄여라 2. 모든 테스트를 실행하라 테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질도 함께 높아진다 단일 책임 원칙을 준수하는 클래스는 테스트가 훨씬 더 쉽다 결합도가 높으면 테스트 케이스를 작성하기 어렵다 그러므로, 테스트 케이스를 많이 작성할수록 개발자는 DIP와 같은 원칙을 적용하고 의존성 주입, 인터페이스, 추상화 등과 같은 도구를 사용해 결합도를 낮춘다 테스트 케이스를 작성하면 코드를 정리하면서 시스템이 깨질까봐 걱정할 필요가 없어진다 응집도를 높이고,..
클린코드 - 11.시스템
2022. 8. 11. 18:51
개발 서적/클린코드
1. 시스템 제작과 시스템 사용을 분리하라 제작과 사용은 다르다 따라서 애플리케이션에서도 관심사를 분리해야 한다 관심사 분리는 가장 오래되고 가장 중요한 설계 기법 중 하나이다 Main 분리 시스템 생성과 시스템 사용을 분리하는 한 가지 방법이다 생성과 관련된 코드는 모두 main이나 main이 호출하는 모듈로 옮겨서 애플리케이션이 main이나 객체가 생성되는 과정을 전혀 모르게 한다 팩토리 객체가 생성되는 시점을 애플리케이션이 결정해야 할 경우 사용 main 분리와 마찬가지로 모든 의존성이 main에서 OrderProcessing 애플리케이션으로 향한다 OrderProcessing 애플리케이션은 LineItem 인스턴스가 생성되는 시점을 완벽하게 통제 가능하고, 필요하다면 OrderProcessing에..
클린코드 - 10.클래스
2022. 8. 6. 19:14
개발 서적/클린코드
1. 클래스 체계 클래스를 정의하는 표준 자바 관례에 따르면, 가장 먼저 변수 목록이 나온다 static 상수 -> public 상수 -> private 변수 -> private 인스턴스 변수 -> public 변수 변수 목록 다음에는 public 함수가 나온다 private 함수는 자신을 호출하는 공개 함수 직후에 넣는다 즉, 추상화 단계가 순차적으로 내려간다 신문기사 처럼 읽혀야 한다 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 좋다 비공개 상태를 유지할 방법을 강구하고, 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다 2. 클래스는 작아야 한다! 단일 책임 원칙 클래스는 최대한 작게 만들어야 한다 '하나의 클래스는 하나의 책임만 가져야 한다 즉, 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 ..
클린코드 - 9.단위 테스트
2022. 8. 6. 17:18
개발 서적/클린코드
1. TDD 법칙 세 가지 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다 위 세 가지 규칙을 따르면서 일하게 될 경우 매일 수십 개, 매달 수백 개, 매년 수천 개에 달하는 테스트 케이스가 나온다 이렇게 일하면 실제 코드를 사실상 전부 테스트하는 테스트 케이스가 나온다 하지만 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다 2. 깨끗한 테스트 코드 유지하기 '테스트는 유연성, 유지보수성, 재사용성을 제공' 테스트 코드를 깨끗하게 유지하지 않으면 결국은 잃어버린다그리고 테스트 케이스가 없으면 실제 코드를 유연하게 만드..
[Study] 2022/07/18
2022. 7. 30. 13:49
개발 서적/클린코드
참여인원 (2명) 본인 wony - https://youn12.tistory.com/ 스터디 진행 방식 - 1~9 챕터 각자 정리한 내용 발표 - 챕터 별로 기억에 남았던 내용 및 느낀 점 논의 - 해당 내용들과 관련된 경험 논의 기억에 남는 내용 - 주석 주석을 지양해야 하는 것은 맞지만 회사에서 팀 내 방침에 따라 조금씩 다를 수 있을 것 같다는 의견 레거시 코드 없는 회사는 찾기 힘듦.... 잘 정리되지 않은 코드들이 많다면 즉, 레거시 코드가 많은 경우 더 지키기 어려운 규칙이라는 생각 - 개행 처리 POSIX 표준에 따라 파일 끝에는 항상 개행을 추가한다 많은 시스템과 도구들이 이 표준을 따라 구현되어 있어서 지키지 않을 시 예기치 않은 동작이 일어날 수 있음 행의 끝(terminating)은 ..
클린코드 - 8.경계
2022. 7. 6. 21:00
개발 서적/클린코드
1. 외부 코드 사용하기 시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다 개발하다 보면 패키지나 오픈 소스를 사용하게 되는데 이런 소스를 제공하는 입장에서는 더 많은 환경에서 돌아갈 수 있도록 적용성을 넓히려고 애쓴다 하지만 사용자 입장에서는 자신의 요구에 집중하는 인터페이스를 바라게 된다 이런 차이에서 경계가 발생한다 java.util.Map 을 예로 들어보자 Map은 마음만 먹으면 사용자는 어떤 객체 유형도 추가하거나 삭제할 수 있다 Map을 만들어서 여기저기 넘긴다고 가정한다면 어디서든 삭제나 추가가 가능하다는 문제가 생긴다 또한 Map 인터페이스가 변경될 경우 수정할 코드 양이 상당히 많아진다 Map sensors = new HashMap; Sensor s = sensors.get..