닭발개발

24일차. 클린코드[4주차_ 토요일] 216-223pg #요약 12. 창발성 1) 창발적 설계로 깔끔한 코드를 구현하자. - 켄트 벡이 제시한 단순한 설계 규칙 네 가지가 소프트웨어 설계 품질을 높여줄 수 있다. ( 중요도 순 ) 🎈 모든테스트를 실행한다. 🎈 중복을 없앤다. 🎈 프로그래머 의도를 표현한다. 🎈 클래스와 메서드 수를 최소로 줄인다. 2) 단순한 설계 규칙1 : 모든 테스트를 실행하라 - 테스트가 가능한 시스템을 만드려고 애쓰면 설계 품질이 더불어 높아진다. 3) 단순한 설계 규칙 2 ~ 4 : 리팩터링 - 코드를 정리하면서 시스템이 깨질까 걱정할 필요없다. 테스트 케이스가 있어서. - 리팩터링 단계에서는 소프트웨어 설계 품질을 높이는 기법이라면 무엇이든 적용해도 괜찮다. 4) 중복을 없애..

11일차. 클린코드[2주차_금요일] 95-102pg #요약 1. 깨끗한 코드 2. 의미 있는 이름 3. 함수 4. 주석 5. 형식 맟추기 - 프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다. - 팀으로 일한다면 팀이 합의해 규칙을 정하고 모두 그 규칙을 따라야 한다. 1) 형식을 맞추는 목적 - 코드형식은 너무 중요해서 융통성없이 맹목적으로 따르면 안된다. - 코드형식은 의사소통의 일환이고 의사소통은 전문 개발자의 일차적인 의무다. 2) 적절한 행 길이를 유지하라 - 자바에서 파일 크기는 클래스 크기와 밀접하다. - 코드의 세로길이가 조금만 차이나도 실제 크기는 크게 달라진다. - 보통 세로길이가 500줄을 넘어가는 파일이 없고 대다수가 200줄 미만이다. -> 200줄 미만의 파일로도 큰 시스템을..

8일차. 클린코드[2주차_화요일] 67-74pg #요약 1. 깨끗한 코드 2. 의미 있는 이름 3. 함수 4. 주석- 주석은 실패를 의미한다. 내가 코드로 풀어내지 못했다는 뜻 - 코드로 의도를 풀어내야 한다. - 주석은 오래될수록 코드에서 멀어진다. - 부정확한 주석은 아예 없는 주석보다 훨씬 나쁘다. 1) 주석은 나쁜 코드를 보완하지 못한다. - 코드 품질이 나쁘니까 주석을 추가한다. 2) 코드로 의도를 표현하라! - 주석으로 달려는 설명을 함수로 표현할 수도 있다. 3) 좋은 주석 - 주석을 달지 않을 방법을 찾아낸 주석이 좋은 주석이다. // 법적인 주석 : 저작권정보와 소유자 정보 // 정보를 제공하는 주석 : 가능하면 함수이름에 정보를 담자 // 의도를 설명하는 주석 : 결정에 깔린 의도까지 ..

7일차. 클린코드[2주차_월요일] 57 - 66pg #요약 1. 깨끗한 코드 2. 의미 있는 이름 3. 함수 1) 작게 만들어라! 2) 한 가지만 해라! 3) 함수 당 추상화 수준은 하나로! 4) Switch문 5) 서술적인 이름을 사용하라! 6) 함수 인수 7) 부수 효과를 일으키지 마라! 8) 명령과 조회를 분리하라 - 함수는 뭔가를 수행 or 답하기 둘 중 하나만 해야 한다. 9) 오류 코드보다 예외를 사용하라! - 명령 함수에서 오류 코드를 반환하는 방식은 명령/조회 분리 규칙을 미묘하게 위반한다. - try/catch 블록은 추하다. 따라서 블록을 별도 함수로 뽑아내는 편이 좋다. - 함수는 한 가지 작업만 해야하는데, 오류 처리도 한 가지 작업에 속한다. - 오류코드 대신 예외를 사용하면 새 ..

5일차. 클린코드[1주차_금요일] 35 - 45pg #요약 1. 깨끗한 코드2. 의미 있는 이름소프트웨어에서 이름은 어디에나 쓰이기 때문에 이름을 잘 지으면 여러모로 편하다. 1) 의도를 분명히 밝혀라 2) 그릇된 정보를 피하라 3) 의미있게 구분하라 4) 발음하기 쉬운 이름을 사용하라 5) 검색하기 쉬운 이름을 사용하라 6) 인코딩을 피하라 7) 자신의 기억력을 자랑하지 마라 8) 기발한 이름은 피하라 9) 한 개념에 한 단어를 사용하라 10) 말장난을 하지 마라 11) 해법 영역에서 가져온 이름을 사용하라 12) 문제 영역에서 가져온 이름을 사용하라 13) 의미 있는 맥락을 추가하라 - 맥락을 계산하면 함수를 쪼개기가 쉬워져서 알고리즘도 더 명확해진다. 14) 불필요한 맥락을 없애라 15) 마치면서 ..

40일차. 오브젝트: 코드로 이해하는 객체지향 설계[7주차_목요일] 505-518pg #요약 **Chapter 14. 일관성 있는 협력** 01. 핸드폰 과금 시스템 변경하기 02. 설계에 일관성 부여하기. 03. 일관성 있는 기본 정책 구현하기 1) 변경 분리하기 2) 변경 캡슐화하기 3) 협력 패턴 설계하기 4) 추상화 수준에서 협력 패턴 구현하기 5) 구체적인 협력 구현하기 - 일관성 있는 협력은 개발자에게 확장 포인트를 강제하기 때문에 정해진 구조를 우회하기 어렵게 만든다. - 유사한 기능에 대해 유사한 협력 패턴을 적용하는 것은 객체지향 시스템에서 개념적 무결성을 유지할 수 있는 가장 효과적 방법이다. - 시스템이 일관성 있는 몇 개의 협력 패턴으로 구성된다면 시스템을 이해, 수정, 확장하는 데..

39일차. 오브젝트: 코드로 이해하는 객체지향 설계[7주차_수요일] 494-504pg #요약 **Chapter 14. 일관성 있는 협력** 01. 핸드폰 과금 시스템 변경하기 02. 설계에 일관성 부여하기. 1) 조건 로직 대 객체 탐색 2) 캡슐화 다시 살펴보기 - 데이터 은닉 : 오직 외부에 공개된 메서드를 통해서만 객체의 내부에 접근할 수 있게 제한함으로써 객체 내부의 상태 구현을 숨기는 기법 - 캡슐화는 데이터 은닉 이상이다. - GOF의 조언에 따르면 캡슐화란 단순히 데이터를 감추는 게 아님. - 소프트웨어 안에서 변할 수 있는 모든 '개념'을 감추는 것임 - 캡슐화의 가장 대표적 예) 객체의 퍼블릭 인터페이스와 구현을 분리하는 것. - 자주 변경되는 내부 구현을 안정적인 퍼블릭 인터페이스 뒤로..

Web Server 웹서버는 HTTP 프로토콜을 기반으로 클라이언트가 웹 브라우저에서 어떤 요청을 하면 그 요청을 받아 정적 컨텐츠를 제공하는 서버. (정적 컨텐츠 : HTML 문서, CSS, 이미지, 파일 등 즉시 응답 가능한 컨텐츠) 웹 서버가 정적 컨텐츠 말고 동적 컨텐츠를 요청 받으면 WAS에게 해당 요청을 넘겨주고, WAS에서 처리한 결과를 클라이언트한테 전달하는 역할도 함. ex) 아파치, NginX WAS (Web Application Server) WAS는 db조회나 다양한 로직처리를 요구하는 동적 컨텐츠 제공을 위해 만들어진 application 서버. http 프로토콜을 기반으로 사용자 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어. 주로 db 서버와 같이 수행됨. WAS는 JSP,..

24일차. 오브젝트: 코드로 이해하는 객체지향 설계[4주차_토요일] 305-321pg #요약 **Chapter 09. 유연한 설계** - 8장에서 유연하고 재사용가능한 설계를 만드려고 적용할 수 있는 다양한 의존성 관리 기법들을 소개했다면 9장에서는 이 기법들을 원칙이라는 관점에서 정리 01. 개방-폐쇄 원칙(Open-Closed Principle, OCP) 02. 생성 사용 분리 03. 의존성 주입 04. 의존성 역전 원칙 05. 유연성에 대한 조언 1) 유연한 설계는 유연성이 필요할 때만 옳다. - 유연하고 재사용 가능한 설계 : 런타임 의존성과 컴파일타임 의존성의 차이를 알고 같은 컴파일 타임 의존성으로부터 다양한 런타임 의존성을 만들 수 있는 코드 구조를 가지는 설계 2) 협력과 책임이 중요하다...

22일차. 오브젝트: 코드로 이해하는 객체지향 설계[4주차_목요일] 277-290pg #요약 **Chapter 08. 의존성 관리하기** 01. 의존성 이해하기 02. 유연한 설계 8) 컨텍스트 확장하기 - 결합도를 낮춤으로써 얻게 되는 컨텍스트의 확장이라는 개념이 유연하고 재사용 가능한 설계를 만든다. 9) 조합 가능한 행동 - 어떤 객체와 협력하느냐에 따라 객체의 행동이 달라지는 것은 유연하고 재사용 가능한 설계가 가진 특징 - 유연&재사용 가능한 설계는 객체가 어떻게 하는지를 장황하게 나열하지 않고도 객체들의 조합을 통해 무엇을 하는지를 표현하는 클래스로 구성됨. - 선언적으로 객체의 행동을 정의할 수 있음 **Chapter 09. 유연한 설계** - 8장에서 유연하고 재사용가능한 설계를 만드려고 ..