고오급 개발자가 되는길

르블랑의 법칙(Leblanc’s Law) - 나중은 결코 오지 않는다 업무의 일정, 예상치 못한 이슈들로 나중에 코드를 수정하겠다는 마음가짐으로 코드를 작성하게 된다면 르블랑의 법칙을 떠올려라 나쁜 코드로 계속 진행된다면 추후에 발생하는 나쁜 코드는 더욱 더 많이 양산된다. 원초적 난제 기한을 맞추기 위해서는 나쁜 코드를 양산하기 쉽지만, 결과적으로 봤을 때는 오히려 나쁜 상태로 속도가 더 느려지게 된다. 오히려 빨리가는 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다. 깨끗한 코드란? 1. 보기에 즐거운 코드 - 다른 사람이 코드를 보는 사람에 있어서 보기에 쉽고 즐거운 코드를 생산하라 2. 철저한 오류처리 - 오류 처리 부분을 확실히 하며, 세세한 사항까지 꼼꼼히 처리하라 3. 가독성이 좋은..

객체지향 설계 안에 존재하는 세가지 상호 연관 관점 1. 개념관점 - 설계는 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현한다. - 실제 도메인의 규칙과 제약을 최대한 코드에 유사하게 반영해야 한다. 2. 명세관점 - 사용자의 영역인 도메인을 벗어나 개발자의 영역인 소프트웨어로 초점이 옮겨진다. - 객체가 협력을 위해 무엇을 할 수 있는가에 초점을 맞춘다. 3. 구현관점 - 객체의 책임을 어떻게 수행할 것인가에 초점을 맞추어 인터페이스를 구현하는 데 필요한 속성과 메서들을 클래스에 추가한다. 이 세가지 관점대로 순서대로 개발하는 것이 아닌 클래스를 세 가지 다른 방향에서 바라보는 관점이 중요하다. 클래스는 세 가지 관점을 모두 수용할 수 있도록 개념, 인터페이스, 구현을 함께 드러내야 하며, 동..

유일하게 변하지 않는 것은 모든 것이 변한다는 사실 뿐이다 - 헤라클레이토스 위와 같은 인용문구를 통해 애플리케이션을 개발할때 신경써야 하는 부분은 애플리케이션을 개발함에 있어 사용자의 요구사항은 언제든지 변할 수 있고 그 변화에 대응할 수 있도록 객체지향적 설계를 해야 한다 라는 것입니다. 자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성하여 객체지향 설계를 해야 합니다. 기능 설계 대 구조 설계 기능 설계 - 제품이 사용자를 위해 무엇을 할 수 있는지에 초점을 맞추어 설계 하는것 - 사용자에게 제공할 기능 구조 설계 - 제품의 형태가 어떠해야 하는지에 대해 초점을 맞추어 설계 하는것 - 기능을 담을 안정적인 구조 설계는 기능, 구조 설계 이 두가지를 조화롭게 이루도록 설계를..

자율적인 책임 - 자율적인 객체란 스스로 정한 원칙에 따라 판단하고 스스로의 의지를 기반으로 행동하는 객체이다 - 객체가 자율적이기 위해서는 객체에게 할당되는 책임의 수준 역시 자율적이어야 한다. EX) 앨리스 이야기에서 왕이 모자장수에게 증언을 요청하면 모자장수는 어떠한 방법을 사용하던 상관없이 증언이라는 책임만 수행하면 된다 너무 추상적인 책임 - 너무 포괄적이고 추상적인 책임을 선택하는 것은 협력의 의도를 파악하게 더 어렵게 할 수 있다 - 협력에 참여하는 의도를 명확하게 설명할 수 있는 수준 안에서 추상적이여야 한다. EX) 재판에서 설명하다 라는 책임은 애매하게 들릴 수 있다. 증언하다라는 책임이 협력의 의도를 뚜렷하게 표현할 수 있다. '어떻게'가 아니라 '무엇'을 - 자율적인 책임의 특징은 ..

정규화 (Normalization)란? - 기본 목표는 테이블 간에 중복된 데이터를 허용하지 않는다 라는 것 - 중복된 데이터를 허용하지 않음 으로써 데이터의 무결성을 유지할 수 있으며 DB 저장 용량 역시 줄일 수 있다. - 이상(Anomaly)를 제거하기 위해 중복성 및 종속성을 배제하는 방법 ※ 데이터의 무결성 : 데이터의 정확성과 일관성을 유지하고 보증하는 것 (개체 무결성, 참조 무결성, 범위 무결성) ※ 이상(Anomaly) : 테이블 내의 데이터 중복성에 의하여 발생되는 데이터의 불일치 현상 (갱신 이상, 삽입 이상, 삭제 이상) 정규화의 4가지 단계 제 1 정규화 - 테이블의 컬럼이 원자값을 갖도록 테이블을 분해하는 것 ※ 원자값 : 하나의 값을 가지고 있는 것, 한 컬럼에 두가지 이상의..

협력 - 협력은 다수의 요청과 응답으로 구성되며 전체적으로 협력은 다수의 연쇄적인 요청과 응답의 흐름으로 구성된다. - 객체들간의 요청과 응답으로 협력 관계를 이루어 각 객체가 수행할 책임을 정의한다. 책임 - 어떤 요청에 대한 응답이나, 적절한 행동을 할 의무가 있다는 것임을 나타내는것이 책임이다. - 책임은 객체에 의해 정의되는 응집도 있는 행위의 집합, 무엇을 할 수 있는가에 대한 초점으로 맞춰야 한다. - 책임은 객체의 공용 인터페이스 (public interface)를 구성한다. 책임의 분류 1. 하는것 (Doing) - 다른 객체에게 요청을 보내어 다른 객체가 행동을 시작하게 하는것 2. 아는것 (Knowing) - 다른 객체에 대한 정보를 알고 있는 것 EX) 토끼가 목격자가 모자 장수라는..

컴퓨터를 조작하는 것이 추상화를 구축하고, 조작하고, 추론하는것에 관한 모든 것 이라는것을 깨닫고 나면 컴퓨터 프로그래밍을 작성하기 위한 중요한 전제 조건은 추상화를 정확하게 다루는 능력이라는 것이 명확해 진다 - 키스 데블린 기존의 지형과 위치를 고려하여 나온 복잡한 지하철 노선도는 단순하고 직관적으로 역 간의 네트워크를 표현한 지하철 노선도가 나옴으로써 복잡하게 이해되고 보기 어렵던 노선도는 쉽게 파악되며 사용되어졌습니다. 추상화도 이 처럼 이해하기 쉽고 단순하며 목적에 부합하는 수준으로 설정하여 개발자에게 복잡성을 극복해 낼 수 있습니다. 추상화를 통한 복잡성 극복 - 위의 지하철 노선도 사례에서 봤을때 중요한 점은 역의 위치가 중요한것이 아니라 역과 역 사이의 연결 관계가 중요했던 것입니다. 그래..

Swagger UI 란? - Swagger 제품 중 RestAPI Controller를 자동으로 API Document를 시각화하여 보여줄 수 있는 Open Source이다 또한 Controller를 실행하여 테스트를 할 수 있으며 요청값을 전달하고 응답을 받을 수 있습니다. (Postman 과 같은 기능) Dependency 추가 1. Gradle implementation 'io.springfox:springfox-boot-starter:3.0.0' implementation 'io.springfox:springfox-swagger-ui:3.0.0' 2. Maven io.springfox springfox-boot-starter 3.0.0 io.springfox springfox-swagger-ui ..

객체지향 패러다임은 지식을 추상화하고 추상화한 지식을 객체 안에 캡슐화함으로써 실세계 문제에 내재된 복잡성을 관리한다. 해당 챕터에서는 앨리스 이야기를 기준으로 객체의 패러다임을 설명하고 있습니다. 앨리스는 이야기 중 작은 문을 통과해야하는데 문을 통과하려면 키가 작아야 통과를 할 수 있었는데, 음료를 마시거나, 부채질을 하거나 행동을 통하여 키를 줄이거나 늘릴 수 있습니다. 이러한 행동을 객체지향의 패러다임으로 보았을 때, 앨리스의 키를 변화 시키는 것은 앨리스의 행동(음료를 마시거나 부채질을 함) 이며, 앨리서의 행동에 따라 앨리스의 상태(키) 가 변하게 된다. 앨리스가 한 행동의 결과는 앨리스의 상태의 의존적이다, 음료를 마시거나, 부채질을 함으로써 키가 변하기 때문이다. 하지만 행동 간에 순서도 ..

많은 사람들이 객체지향이란 실세계를 직접적이고 직관적으로 모델링 할 수 있는 패러다임이라고 생각한다. 하지만 실제 세계의 방화벽은 화재의 확산을 막아주고, 소프트웨어의 방화벽은 네트워크 침입을 막는 용도로 사용된다. 이런 예시와 같이 의미적 거리 만큼이나 소프트웨어 객체와 실세계 사물이 존재하는 연관성은 희미할 수 있다. 실제로 애플리케이션을 개발하면서 객체에 직접적으로 대응되는 실세계의 사물을 발견할 확률은 그다지 높지 않다. 이러한 상황들을 봤을떄 객체지향의 목표는 실세계를 모방하는 것이 아니라, 오히려 새로운 세계를 창조하는 것이다. 하지만 실세계의 모방은 객체지향을 이해하고 학습하는데에는 효과적이다. 객체지향 이해를 위한 실세계 모방 커피 주문 과정에서의 역할과 책임 1. 손님 - 커피를 주문한..