[Modify] 이력서 일부 수정 (#149)

* [Add] Book Commnet - 오브젝트 > 1장. 객체, 설계 (#147)

Co-authored-by: sanghunlee-711 <[email protected]>

* [Modify] Book Comment > Object 2장 객체지향 프로그래밍  마무리 (#148)

Co-authored-by: cloud <[email protected]>

* [Modify] 이력서 일부 수정

---------

Co-authored-by: sanghunlee-711 <[email protected]>
Co-authored-by: cloud <[email protected]>

pre-post/2023-09-14-object.md

@@ -0,0 +1,143 @@
+---
+slug: 2023-09-14-object
+title: Book comment - 오브젝트 (코드로 이해하는 객체지향 설계)
+summary: 코드로 이해하는 객체지향 설계
+author: Sanghun lee
+date: 2023-09-14 11:33:00 +0800
+categories: [OOP]
+folder: [post-personnel]
+tags: [OOP]
+math: true
+mermaid: true
+image:
+  src: '../static/images/posts/concepts-oop.png'
+  height: 585
+---
+
+# 작성 이유 ?
+
+일전에 읽은 객체지향의 사실과 오해를 이어 조영호님의 객체지향시리즈 2탄에 해당하는 **오브젝트**를 연달아서 읽어보려 한다.
+
+전에 역할, 책임, 협력을 이론적으로 감을 읽혀 추상적인 감을 읽힌 상태이므로 신나는 마음으로 읽어볼 수 있을 것 같다.
+
+---
+
+# 서론: 프로그래밍 패러다임
+
+## 1. 패러다임의 시대
+
+- 과학사에 대한 보편적인 시각은 발전의 누적과정으로 바라보는 것이었다.
+- ... 과학적 성취를 기반으로 새로운 발견을 누적시키거나 기존의 오류를 수정하면서 단계적으로 진보해 나가는 과정이다.
+- 과학혁명이란 과거의 패러다임이 새로운 패러다임에 의해 대체됨으로써 정상과학의 방향과 성격이 변하는 것을 의미한다.
+
+## 2. 프로그래밍 패러다임
+
+- 프로그래밍 패러다임은 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 함으로써 불필요한 부분에 대한 의견충돌을 방지한다. 또한 , 프로그래밍 패러다임을 교육시킴으로써 동일한 규칙과 방법을 공유하는 개발자로 성장할 수 있도록 준비시킬 수 있다.
+
+# 1. 객체, 설계
+
+- 추상적인 개념과 이론은 훌륭한 코드를 작성하는데 필요한 도구일 뿐이다. 프로그래밍을 통해 개념과 이론을 배우는 것이 개념과 이론을 통해 프로그래밍을 배우는 것보다 더 훌륭한 학습방법이라 생각한다.
+
+- 모듈은 실행중에 제대로 동작해야한다.
+- 변경하기 어려운 모듈은 제대로 동작하더라도 개선해야한다.
+- 읽는사람과 의아소통할 수 없는 모듈은 개선해야한다.
+
+- 이 코드는 하나의 클래스나 메서드에서 너무 많은 세부사항을 다루기 때문에 코드를 작성하는 사람뿐만 아니라 읽고 이해해야 하는 사람 모두에게 큰 부담을 준다.
+
+- *의존성*이라는 말 속에는 어떤 객체가 변경될 때 그 객체에게 의존하는 다른객체도 함께 변경될 수 있다는 사실이 내포되어 있다.
+- 우리의 목표는 어플리케이션의 기능을 구현하는데 필요한 최소한의 의존성만 유지하고 *불필요한 의존성을 제거*하는 것이다.
+- 객체 사이의 의존성이 과한 경우를 가리켜 *결합도*가 높다고 말한다. 반대로 객체들이 합리적인수준으로 의존할 경우에는 결합도가 낮다고 말한다.
+
+- 의도를 정확하게 의사소통하지 못하기 때문에 코드가 이해하기 어려워진 것이다.
+
+- 개념적이나 물리적으로 객체 내부의 세부사항을 감추는 것을 _캡슐화(encapsulation)_ 라고한다.
+
+  - 캡슐화의 목적은 변경하기 쉬운 객체를 만드는 것이다.
+  - 캡슐화를 통해 객체 내부로의 접근을 제한하면 객체와 객체 사이의 결합도를 낮출 수 있기 때문에 설계를 좀 더 쉽게 변경할 수 있게 된다.
+
+- 객체를 인터페이스와 구현으로 나누고 인터페이스만을 공개하는 것은 객체사이의 결합도를 낮추고 변경하기 쉬운코드를 작성하기 위해 따라야하는 가장 기본적인 설계 원칙이다.
+
+- 핵심은 객체 내부의 상태를 캡슐화하고 객체간에 오직 메시지를 통해서만 상호작용하도록 만드는 것이다.
+
+- 절차적 프로그래밍은 프로세스가 필요한 모든 데이터에 의존해야한다는 근본적인 문제점 때문에 변경에 취약할 수 밖에 없다.
+
+- 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍 하는 방식을 *객체지향 프로그래밍이*라고 부른다.
+
+- 적절한 객체에 적절한 책임을 할당하면 이해하기 쉬운 구조와 읽기 쉬운 코드를 얻게 된다.
+
+- 어떤 기능을 설계하는 방법은 한 가지 이상일 수 있다. 동일한 기능을 한가지 이상의 방법으로 설계할 수 있기 때문에 결국 설계는 트레이드오프의 산물이다. 어떤 경우에도 모든사람들을 만족시킬 수 있는 설계를 만들수는 없다. 설계는 균형의 예술이다. 훌륭한 설계는 적절한 트레이드오프의 결과물이라는 사실을 명심하라.
+
+- _설계란 코드를 배치하는 것이다_
+- 우리가 짜는 프로그램은 두가지 요구사항을 만족시켜야한다. 우리는 오늘 완성해야하는 기능을 구현하는 코들르 짜야하는 동시에 내일 쉽게 변경할 수 있는 코드를 짜야한다. 좋은 설계란 오늘 요구하는 기능을 온전히 수행하면서 내일의 변경을 매끄럽게 수용할 수 있는 설계다.
+
+# 2. 객체지향 프로그래밍
+
+### 도메인의 구조를 따르는 프로그램 구조
+
+- 문제를 해결하기 위해 사용자가 프로그램을 사용하는 분야를 도메인이라고 부른다.
+- 요구사항과 프로그램을 객체라는 동일한 관점에서 바라볼 수 있기 때문에 도메인을 구성하는 개념들이 프로그램의 객체와 클래스로 매끄럽게 연결될 수 있다.
+- 일반적으로 클래스의 이름은 대응되는 도메인 개념의 이름과 동일하거나 적어도 유사하게 지어야 한다. 클래스 사이의 관계도 최대한 도메인 개념사이에 맺어진 관계와 유사하게 만들어서 프로그램의 구조를 이해하고 예상하기 쉽게 만들어야 한다.
+
+- 클래스를 구현하거나 다른 개발자에 의해 개발된 클래스를 사용할 때 가장 중요한 것은 클래스의 경계를 구분 짓는 것이다.
+- 클래스는 내부와 외부로 구분되며 훌륭한 클래스를 설계하기 위한 핵심은 어떤부분을 공개하고 어떤 부분을 감출지를 결정하는 것이다.
+
+- 데이터와 기능을 함께 객체내부로 묶는 것을 _캡슐화_ 라고 부른다.
+- 객체 내부에 대한 접근을 통제하는 이유는 객체를 자율적인 존재로 만들기 위해서다.
+- *퍼블릭 인터페이스*에는 public 으로 지정된 메서드만 포함된다. 그 밖의 private 메서드나 protected 메서드, 속성은 *구현*에 포함된다.
+
+# 3. 할인 요금 구하기
+
+- 설계가 필요한 이유는 변경을 관리하기 위해서라는 것을 기억하라.
+- 여러분은 변경될 가능성이 있는 세부적인 구현내용을 private영역 안에 감춤으로써 변경으로 인한 혼란을 최소화할 수 있다.
+
+- 부모클래스에 기본적인 알고리즘의 흐름을 구현하고 중간에 필요한처리를 자식 클래스에게 위임하는 디자인 패턴을 TEMPLATE METHOD패턴이라고 한다.
+
+- 오버라이딩은 부모클래스에 정의된 같은 이름, 같은 파라미터 목록을 가진 메서드를 자식 클래스에서 재정의하는 경우를 말한다. 자식 클래스의 메서드는 오버라이딩한 부모클래스의 메서드를 가리기 때문에 부모 클래스의 메서드가 보이지 않는다.
+
+- 오버로딩은 메서드의 이름은 같지만 제공되는 파라미터 목록이 다르다. 오버로딩한 메서드는 원래의 메서드를 가리지 않기 때문에 이 메서드들은 사이좋게 공존한다.
+  - 자바에서는 하나의 클래스의 동일 이름의 메서드를 파라미터타입만 다르게 하여 외부에서 모두 호출할 수 있도록 만들어놓는 것이 가능하다.
+
+# 4. 상속과 다형성
+
+- 어떤 클래스가 다른 클래스에 접근할 수 있는 경로를 가지거나 해당 클래스의 객체의 메서드를 호출 할 경우 두 클래스 사이에 의존성이 존재한다고 말한다.
+- 코드의 의존성과 실행시점의 의존성이 서로 다를 수 있다는 것이다. 다시말해 클래스사이의 의존성과 객체 사이의 의존성은 동일하지 않을 수 있다. 그리고 유연하고 , 쉽게 재사용할 수 있으며, 확장 가능한 객체지향 설계가 가지는 특징은 코드의 의존성과 실행시점의 의존성이 다르다는 것이다.
+
+  - 한가지 간과해서는 안되는 사실은 코드의 의존성과 실행시점의 의존성이 다르면 다를 수록 코드를 이해하기 어려워 진다는 것이다.
+
+- 설계가 유연해질수록 코드를 이해하고 디버깅하기는 점점 더 어려워진다는 사실을 기억하라. 반면 유연성을 억제하면 코드를 이해하고 디버깅하기는 쉬워지지만 재사용성과 확장 가능성은 낮아진다는 사실도 기억하라.
+- 여러분이 훌륭한 객체지향 설계자로 성장하기 위해서는 항상 유연성과 가독성 사이에서 고민해야한다.
+
+- 부모클래스와 다른 부분만을 추가해서 새로운 클래스를 쉽고 빠르게 만드는 방법을 차이에의한 프로그래밍(Programming by difference)이라고 부른다.
+
+  - 기반(base) 클래스와 파생(derived)클래스라는 용어도 사용하기도 한다
+
+- 자식 클래스는 상속을 통해 부모클래스의 인터페이스를 물려받기 때문에 부모클래스 대신 사용될 수 있다. 컴파일러는 코드 상에서 부모 클래스가 나오는 모든 장소에서 자식 클래스를 사용하는 것을 허용한다.
+- 이처럼 자식 클래스가 부모클래스를 대신하는 것을 `업캐스팅(upcasting)`이라고 부른다.
+
+- 다형성은 객체지향 프로그램의 컴파일 시간 의존성과 실행시간 의존성이 다를 수 있다는 사실을 기반으로 한다.
+
+  - 이처럼 다형성은 컴파일 시간 의존성과 실행시간 의존성을 다르게 만들 수 있는 객체지향의 특성을 이용해 서로 다른 메서드를 실행할 수 있게 한다.
+
+- 다형성이란 동일한 메시지를 수신했을 때 객체의 타입에 따라 다르게 응답할 수 있는 능력을 의미한다.
+- 다형성을 구현하는 방법은 매우 다양하지만 메시지에 응답하기 위해 실행될 메서드를 컴파일 시점이 아닌 실행시점에 결정한다는 공통점이 있다. 다시 말해 _메시지와 메서드를 실행시점에 바인딩_ 한다는 것이다. 이를 `지연 바인딩(lazy binding)` 또는 `정적 바인딩(static binding)`이라고 부른다.
+- 그에 반해 전통적인 함수 호출처럼 컴파일 시점에 실행될 함수나 프로시저를 결정하는 것을 `초기 바인딩(ealry binding)`또는 `정적 바인딩(static binding)`이라고 부른다.
+- 객체지향이 컴파일 시점의 의존성과 실행 시점의 의존성을 분리하고 ,하나의 메시지를 선택을 서로 다른 메시지를 선택적으로 서로 다른 메서드에 연결할 수 있는 이유가 바로 지연 바인딩이라는 메커니즘을 사용하기 때문이다.
+
+# 5. 추상화와 유연성
+
+- 추상화를 사용하면 세부적인 내용을 무시한 채 상위 정책을 쉽고 간단하게 표현할 수 있다.
+
+- 책임의 위치를 결정하기 위해 조건문을 사용하는 것은 협력의 설계 측면에서 대부분의 경우 좋지않은 선택이다. 항상 예외 케이스를 최소화하고 일관성을 유지할 수 있는 방법을 선택하라.
+- 여러분이 작성하는 모든 코드에는 합당한 이유가 있어야한다. 비록 아주 사소한 결정이더라도 트레이드오프를 통해 얻어진 결론과 그렇지 않은 결론 사이의 차이는 크다. 고민하고 트레이드 오프하라.
+
+- 합성은 다른 객체의 인스턴스를 자신의 인스턴스 변수로 포함해서 재사용하는 방법을 말한다.
+
+- 상속은 객체지향에서 코드를 재사용하기 위해 널리 사용되는 기법이다. 하지만 두가지 관점에서 설계에 안좋은 영향을 미친다. 하나는 상속이 캡슐화를 위반한다는 것이고, 다른 하나는 설계를 유연하지 못하게 만든다는 것이다.
+
+  - 결과적으로 부모 클래스의 구현이 자식클래스에게 노출되기 때문에 캡슐화가 약화된다. 캡슐화의 약화는 자식클래스가 부모클래스에 강하게 결합되도록 만들기때문에 부모클래슬르 변경할 때 자식클래스도 함께 변경될 확률을 높인다.
+  - 상속은 부모클래스와 자식클래스사이의 관계를 컴파일 시점에 결정한다. 따라서 실행시점에 객체의 종류를 변경하는것이 불가능하다.
+
+- 인터페이스에 정의된 메시지를 통해서만 코드를 재사용하는 방법을 _합성_ 이라고 한다.
+  - 인터페이스에 정의된 메시지를 통해서만 재사용 가능하기 때문에 구현을 효과적으로 캡슐화 할 수 있다.
+  - 의존하는 인스턴스를 교체하는것이 비교적 쉽기때문에 설계를 유연하게 만든다. 상속은 클래스를 통해 강하게 결합되는데 비해 합성은 메시지를 통해 느슨하게 결합된다. 따라서 코드 재사용을 위해서는 상속보다는 합성을 선호하는것이 더 좋은 방법이다.
+  - 코드를 재사용하는 경우 상속보다 합성을 선호하는 것이 옳지만 다형성을 위해 인터페이스를 재 사용하는 경우에는 상속과 합성을 조합해서 사용할 수 밖에 없다.

pre-post/2023-10-04-review.md

@@ -0,0 +1,55 @@
+---
+slug: 2023-10-04-review
+title: 나의 멘탈은 안녕할까? 중간점검을 해보자
+summary: 길고도 짧은 3년여간의 개발커리어
+author: Sanghun lee
+date: 2023-10-04 11:33:00 +0800
+categories: [Career]
+folder: [post-personnel]
+tags: [Career]
+math: true
+mermaid: true
+image:
+  src: ''
+  height: 585
+---
+
+# 어디서부터 돌아봐야할까?
+
+어찌저찌 첫번째 커리어를 시작했다. 영세하고 그 당시에도 오래 되었다고 판단된 기술스택(제이쿼리, php..)에 옆 사무실에서 소리를 지르고 1층에 목욕탕이 있는 회사였다.
+
+왜 갔냐고 물어보면.. 당시에 주제에 비해 연봉도 높게 불러준 상태였고, 무엇보다 IT관련 회사에 대한 분위기와 보는 눈이 너무 없었기에 다녔던 것 같다.
+
+다녔다기도 뭐한것이.. 3달만에 전화업무를 시키려하길래 뒤도 안돌아보고 사직서를 내고 나왔다.
+
+그래서, 나의 이력서 어디에도 기재되어있지 않고 어디에서도 이야기하지 않는 곳이다.
+
+기억에 남는 개발을 한 것도 없었고, 앞으로 어떤것을 하고 싶은지도 개인적으로 이해가 되지 않는 곳이었다.
+
+그렇게 첫번째 회사를 그만두고 준비를 이직 준비를 하던 중, 지인분이 회사에 자리가 있다고 하여 또 한번 작은 회사로 입사를 하게 된다.
+
+인사관련 Saas 사업을 목표로 하는 곳이었고, 광화문 교보문고 안에서 일을 하게 되었다. 내부 인큐베이팅 프로그램에 선정되어 사무실을 이용하는 것이었다.
+
+캡슐커피도 있고, 교보문고 건물이라 기타 시설은 굉장히 좋았다. 또한, 동료로 만난 개발자분들이 모두 친절하고 인성이 좋으셔서 많은 이야기를 해보고, 배움을 얻을 수 있었다. 이시기에 만난 CTO분은 아직도 종종 연락을 할 정도로 개인적으로 귀인이다.
+
+여튼 이 회사도 스타트업, 그러니까 자그마한 회사답게 투자에 목말라 있었고 교보만의 투자를 기다리다 결국 실패를 맛보고 폐업을 하게 되었다.
+
+이 과정에서 3달여간 월급이 밀리기도 하였지만.. 아이러니하게도 이 시기에 개발이 많이 늘었다.
+
+다른 개발자분들은 임금 연체 소식이 들리자마자 이직을 하였고, 또 1년이 지난 상태라 이직을 하기도 좋은 상태셨다.
+
+하지만 나는 8~9개월만 재직한 상태에서 이직 준비를 할 여지도 없었고, 쌓아놓은 코드베이스에서 무언갈 더 하고싶은 욕망때문에 그만두지 못하였다.
+
+그래서 회사 내 개발자가 CTO와 본인뿐이었기에 이시기에 테스트코드를 작성하면서 레이어를 나눈다거나 클래스를 활용한다거나 리팩토링을 하는 접근법 등에 대해 많은 고민을 하게 되었고 많은 지식을 습득할 수 있게 되었다.
+
+여튼 그러다가 폐업이 목적에 다가오게 되었고, 재빨리 이직준비를 하여 많은 회사에 지원을 하게 되었다.
+
+# 두번의 망한 커리어, 세번째는?
+
+현재 회사 또한 자그마한 회사로 환경기반 IoT + Saas 서비스를 지향하고 있다.
+
+나름 수익을 내고 있고, 원래 환경공학을 전공하였고 관련회사를 짧지 않게 다녔기에 조금 더 적응하기 수월할 것으로 유추되었다.
+
+또한, 당장 수입을 가지며 살고 싶었기 때문에, 이것저것 재지 않고 크게 개발 동료들의 존재 + 자체 수익만 내면 무조건 입사하겠다는 생각으로 이직준비를 하고 있었다.
+
+입사 후, 같이 일하던 프론트엔드 두 분은 퇴사를 하셨다. 이 회사에서 정말 많은 것을 느끼고 있다.

src/pages/Resume/constants/experience.js

@@ -18,12 +18,6 @@ export const EXPERIENCE = [
               'yarn work space를 통해 각 프로젝트 별 코드 공유 사용 가능하게 변경',
             ],
           },
-          {
-            target: 'UI 일원화',
-            actions: [
-              'Storybook을 활용하여 디자이너와 컴포넌트 협업을 위한 Static사이트 개발로 협업능력 증대',
-            ],
-          },
           {
             target: '반복 개발 업무 개선',
             deployLink:
@@ -34,41 +28,6 @@ export const EXPERIENCE = [
           },
         ],
       },
-      {
-        title: '배달음식 일회용기 반납 후 보증금 반환을 위한 서비스',
-        deployLink: 'https://dish.lalaloop.app/',
-        githubLink: '',
-        detailList: [
-          {
-            target: '크로스 브라우징 및 디바이스 대응',
-            actions: [
-              '시멘틱 태그와 다양한 css기법을 이용하여 웹 & 모바일 및 크로스브라우징 대응',
-            ],
-          },
-        ],
-      },
-      {
-        title: 'IoT 기반 데이터 관리를 위한 사내 관리 시스템',
-        deployLink: 'https://oa-console.oysterable.com/',
-        githubLink: '',
-        detailList: [
-          {
-            target: '프로젝트 초기 구조 세팅',
-            actions: [
-              'React, Hooks, ContextAPI, React-Query를 적극 활용하여  도메인, 클라이언트 상태 분리 개념 적용으로 상태 구조 생성',
-              '테이블, 페이지네이션 등의 기반 컴포넌트와 그에 해당하는 재 사용될 로직들 구축으로 코드 재사용성 증대',
-            ],
-          },
-          {
-            target: '사내 업무 효율 증진',
-            actions: [
-              'ApexChart를 활용하여 다양한 데이터를 시각화 UX 제공',
-              '권한별 메뉴, 버튼 접근 등의 렌더링을 통한 다양한 UX 제공',
-              '앱의 실제 렌더 모습과 싱크로율을 맞춘 다양한 미리보기 기능 제공',
-            ],
-          },
-        ],
-      },
       {
         title: '오늘의 분리수거 앱 개선',
         deployLink: '',
@@ -145,8 +104,6 @@ export const EXPERIENCE = [
             target: 'UI/UX 유지보수',
             actions: [
               '앵귤러로 되어있던 메인페이지들의 디자인개선 작업과 동시에 리액트로 전환',
-              '모바일 사이즈에 대응하는 새로운 컴포넌트 구성',
-              '비즈니스 활용을 위한 유입 경로 추적 기능',
             ],
           },
         ],