12Dev

📋 목차. 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. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 위 세 가지 규칙을 따르면 개발과 테스..

📋 목차. 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 문 등 블록은 한 줄이야 하는 의미다. 그러면 바깥을 감싸는 함수가 작아질 뿐 아니라, 블록 안에서 호출하는 함수 이름을 적절히 짓는다면,..