12Dev

📋 목차. 17. 냄새와 휴리스틱 .주석 .환경 .함수 .일반 .자바 .이름 .테스트 .결론 ✔️ 내용. 17. 냄새와 휴리스틱 마틴 파울러는 'Refactoring'에서 다양한 코드 냄새를 거론한다. 이 장의 목록에서는 마틴이 맡은 냄새에 저자가 맡은 냄새를 추가한다. 또한 코드를 짜면서 사용하는 기교와 휴리스틱도 포함한다. 아래 목록들은 '왜?'라고 자문한 다음 답을 기록하였다. .주석 - C1: 부적절한 정보 다른 시스템에 (VCS, 버그 추적 시스템 등) 저장할 정보는 주석으로 적절하지 못하다. 변경 이력, 날짜 등은 소스 코드만 번잡하게 만든다. 일반적으로 작성자, 최종 수정일, SPR(Software Problem Report) 번호 등과 같은 메타 정보만 주석으로 넣는다. 주석은 코드와 설계..

📋 목차. 16. SerialDate 리펙터링 .결론 ✔️ 내용. 16. SerialDate 리펙터링 저자가 SerialDate 라는 Date 클래스를 탐험하며 부족한 테스트 케이스와 리펙토링을 하는 일련의 과정을 보여주는 장이다. 이 역시 14, 15장과 마찬가지로 책의 코드를 보며 리펙터링 과정을 훑어보는 걸로 마쳤다. .결론 이 장 역시 결론 적으로는 보이스카우트 규칙을 따랏다. 체크아웃한 코드보다 좀 더 깨끗한 코드를 체크인하게 되었다. 시간은 걸렸지만 가치있는 작업으로 테스트 커버리지가 증가했으며, 몇개의 버그를 고쳤고 코드 크기를 줄이고, 코드를 명확히 했다. 다음에 코드를 읽게 될 사람은 좀 더 쉽게 이해할 수 있게되리라. 그래서 우리보다 코드를 좀 더 쉽게 개선하리라. 📝 느낀점. - 전반..

📋 목차. 15. JUnit 들여다보기 .결론 ✔️ 내용. 15. JUnit 들여다보기 JUnit은 자바 프레임워크 중 가장 유명하다. 개념은 단순하며 정의는 정밀하고 구현은 우아하다. 이 장 역시 앞선 '14장 점진적 개선'과 마찬가지로 코드로 작성된 페이지로 간단하게 확인만 하였다. .결론 캠프장은 처음 왔을 때보다 더 깨끗하게 해 놓고 떠나라 보이스카우트 규칙 이 장에서는 코드 개선을 보여주었다. 보이스카우트 규칙을 지키며 처음 모듈보다 조금 더 깨끗한 모듈을 만듦에 포인트를 주어 개선해 나가는 과정을 보여주었다. 그렇다 하여 원래 깨끗하지 못했다는 말이 아니다. 우수한 모듈을 만들었지만 세상에 개선이 불필요한 모듈은 없다. 코드를 처음보다 조금 더 깨끗하게 만드는 책임은 우리 모두에게 있다. 📝 ..

📋 목차. 14. 점진적인 개선 .점진적으로 개선하다. .결론 ✔️ 내용. 14. 점진적인 개선 점진 적인 개선을 코드로 보여주는 장으로 많은 내용이 없다. 프로그래밍은 과학보다 공예에 가깝다. 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다. 돌아가는 프로그램을 목표로 잡아서는 안된다. 이런 행동은 전문가로서 자살 행위이다. .점진적으로 개선하다. 프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위다. 어떤 프로그램은 그저 그런 '개선'에서 결코 회복하지 못한다. '개선' 전과 똑같이 프로그램을 돌리기가 아주 어렵기 때문이다. 그래서 저자는 테스트 주도 개발(TDD)이라는 기법을 사용했다. TDD는 언제 어느 때라도 시스템이 돌아가야 한다는 원칙..

📋 목차. 13. 동시성 .동시성이 필요한 이유? .난관 .동시성 방어 원칙 .라이브러리를 이해하라. .실행 모델을 이해하라. .동기화하는 부분을 작게 만들어라 .올바른 종료 코드는 구현하기 어렵다. .스레드 코드 테스트하기 .결론 ✔️ 내용. 13. 동시성 객체는 처리의 추상화다. 스레드는 일정의 추상화다. - 제임스 O. 코플리엔 동시성과 깔끔한 코드는 양립하기 아주 어렵다. 이 장에서는 여러 스레드를 동시에 돌리는 이유를 논한다. 여러 스레드를 동시에 돌리는 어려움도 논하며 이런 어려움에서 어떻게 깨끗한 코드를 작성하는지 방법도 제안한다. 마지막으로, 동시성을 테스트하는 방법과 문제점을 논한다. .동시성이 필요한 이유? 동시성은 결합을 없애는 전략이다. 즉, 무엇과 언제를 분리하는 전략이다. 단일 ..

📋 목차. 12. 창발성 .창발적 설계로 깔끔한 코드를 구현하자. .단순한 설계 규칙 1 : 모든 테스트를 실행하라 .단순한 설계 규칙 2~4 : 리펙터링 .중복을 업애라 .표현하라 .클래스와 메서드 수를 최소로 줄여라 .결론 ✔️ 내용. 12. 창발성 .창발적 설계로 깔끔한 코드를 구현하자. 1. 모든 테스트를 실행한다. 2. 중복을 없앤다 3. 프로그래머 의도를 표현한다. 4. 클래스와 메서드 수를 최소로 줄인다. 켄트 벡이 제시한 위의 4가지 규칙을 따르면 우수한 설계가 나오고, 코드 구조와 설계를 파악하기 쉬우며 SRP, DIP 같은 원칙을 적용하기 쉬워진다. 또한 설계는 단순하다고 말한다. 순서는 중요도 순이다! .단순한 설계 규칙 1 : 모든 테스트를 실행하라 검증이 불가능한 시스템은 절대 출..

📋 목차. 11. 시스템 .시스템 제작과 시스템 사용을 분리하라 .확장 .횡단 관심사 .테스트 주도 시스템 아키텍처 구축 .의사 결정을 최적화하라 .명백한 가치가 있을 때 표준을 현명하게 사용하라 .시스템은 도메인 특화 언어가 필요하다. .결론 ✔️ 내용. 11. 시스템 "복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만드다" - 레이 오지, Microsoft CTO 하나의 도시를 한 사람이 관리할 수는 없다. 각자의 역할에 맞는 팀과 사람이 있어야 잘 돌아가게 된다. 도시가 돌아가는 또 다른 이유는 적절한 추상화와 모듈화 때문이다. 그래서 큰 그림을 이해하지 못하여도 개개인이 관리하는 '구성'요소'는 효율적으로 돌아간다. 소프트웨어 팀도 도시처럼 구성한다...

✏️ Info. - DB Update 가 계획되어있어서 서버 다운 됐을 때 점검 중 페이지를 띄워줘야 했다. - Front, Android, AOS 각 Client가 있기에 Html이 아닌 Json 형식으로 필요 변수들을 내려주었다. 📋 List. 1. 점검.json File 생성 2. Nginx Config File 생성 3. Nginc 설정 ✔️ Content. 1. 점검.json File 생성 - 생성에 있어 경로를 기억해 둔다. 경로 : /home/maintenacne/maintenance.json { "name": "점검중", "start-time": "2022.08.03 11:00:00", "end-time": "2022.08.03 16:00:00" } 2. Nginx Config File 생..

📋 목차. 10. 챕터 .클래스 체계 .캡슐화 .클래스는 작아야 한다!. .단일 책임 원칙 .응집도 .변경으로부터 격리 ✔️ 내용. 10. 클래스 깨끗한 클래스를 다루는 방법 .클래스 체계 클래스를 정의하는 표준 자바 관례 변수 목록 static public 변수 static private 변수 private 변수 private 인스턴스 변수 공개 변수 공개 함수 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다 (세로거리) .캡슐화 변수와 유틸 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다. 때로는 변수나 유틸 함수를 protected로 선언해 테스트 코드에 접근을 허용하기도 한다. 같은 패키지 안에서 테스트 코드가 함수를 호출하거나 변수를 사용해야 한다면 그 함수나 ..

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