6장 오혜성 (#50)

6장/오혜성.md

@@ -0,0 +1,122 @@
+# 코딩하는 동안 해야 할 일들
+
+- 일단 코딩에 들어가면 컴퓨터가 실행할 수 있는 문장으로 바꾸는 일만 남는다는 생각이 일반적이다
+  - 이런 태도는 보기 흉하고, 비효율적이고, 구조가 엉망이고, 유지보수하기 힘들고, 한마디로 완전히 잘못된 프로그램이 많게된 가장 큰 원인이다.
+
+## 우연에 맡기는 프로그래밍
+
+- 행운과 어쩌다 오는 성공에 의존하는 프로그래밍을 하지 말아야 한다
+
+  - 대신 의도적으로 프로그래밍 해야 한다
+
+- 즐거운 우연과 주도면밀한 계획을 착각하기 쉬운 경우도 종종 있다
+
+  - 일단 잘 작동하니까 .. 괜히 건드렸다 일을 만들 필요가 있을까? 란 생각을 하기 쉽다
+    - 정말로 제대로 돌아가는 것이 아닐 수도 있고
+    - 라이브러리 업데이트에 따라 동작하지 않을 수도 있고
+    - 코드를 더 느리게 만들 수도 있고
+    - 새로운 버그가 생길 수도 있다
+  - 추측을 문서로 상세히 남겨라
+
+- 의도적 프로그래밍
+  - 언제나 자기가 지금 무엇을 하고 있는지 알아야 한다
+  - 어떤 상항에서 신뢰할 만한 것과 아닌 것을 판단하지 못하겠거든, 일단 가장 최악의 상황을 가정하라
+  - 과거의 노예가 되지 말라
+    - 기존 코드가 앞으로 짤 코드를 지배하도록 놓아두지 말라
+    - 더 이상 적절하지 않다고 생각되면 교체할 수 있다
+    - 염두할 것은 일정이 늦어져 발생하는 비용이 필요한 변화를 만들지 '않을' 경우의 비용보다 적어야 한다는 것
+
+> 저는 과거의 노예입니다.. 주인님 ...
+>
+> > 일정이 늦어지는 것과 교체하지 않았을 때의 트레이드 오프를 계산하는게 아직은 어렵고 낯설다
+> > 일단 기존의 것들은 잘 되니까 ... 지금 해야하는 것만 하자.. 라는 생각이 쉽게 들더라고용
+
+## 알고리즘의 속도
+
+- 실용주의 프로그래머는 이론적 기반과 실무적 기반을 모두 고려하려고 노력한다
+  - 추정을 했더라도, 실제 데이터를 입력받아 돌아가는 코드의 수행시간만이 정말로 의미있는 수치다
+
+> 관련한 경험이라면 ...
+> 구글 캘린더 같은 것을 만드는 과정이 있었는데요
+>
+> API 응답이 렌더링에 친화적이지 않은 형태라, 클라이언트에서의 연산이 많이 필요했어요 ...
+> 수가 크다면 버벅일 수도 있었겠지만 ... 한 멘토가 맡는 팀의 수나, 팀의 일정이 많지 않아서 그냥 냅다 렌더링될때마다 연산을 했다는...
+
+- 가장 빠른 알고리즘은 가장 좋은 알고리즘이 아니다
+  - 작성하고 디버깅하는데 걸리는 시간이 중요한 지표
+
+- 성급한 최적화는 만악의 근원이다
+  > 이모션 문서에서도 이렇게 이야기 하더라고용
+  > https://emotion.sh/docs/performance
+
+## 리팩터링
+
+- 소프트웨어는 건축보다 오히려 정원일에 가깝다
+
+  - 유기적이기 때문
+
+- 어떤 것이든 '잘못'되었다고 생각될 때, 그것을 변경하는 일을 주저하지 마라. 언제나 바로 지금이 최적이다.
+
+  > 뇌로는 알겠는데.. 엄두가 안나는 경우가 많은 거 같아요
+
+- 코드를 산산조각으로 해체하는 일을 주저하는 개발자들이 많은데, 그 까닭은 그런 일을 하면 절대로 안 될 것같기 때문이다.
+
+  > 절대로 안 될 것같은 이유는 ... 잘 되는게 펑~ 해버릴까 그런 것이라 저는 생각하는데요
+  > 이를 조금 편하게 .. 용기를 내기 쉽게 만들기 위해 테스트 코드가 존재하지 않을까 생각해용
+  >
+  > > 그치만 잘 짠...
+
+- 리팩터링해야 할 것들의 명단을 만들고 유지하라
+
+  > ㅠ
+
+- 간단한 조언
+
+  - 리팩터링과 새로운 기능 추가를 동시에 하지 마라
+  - 리팩터링 전 든든한 테스트가 있는지 확인
+  - 단계를 작게 나누어 신중하게 작업
+
+- 지금 고통스럽더라도, 앞으로 더욱 고통스러워질 것 같으면 지금 고치는 편이 낫다
+
+> 리팩터링? 좋다... 좋다 이거야...
+> 그치만 코드를 계속해서 싸면서,
+> 공부를 계속해.. 새로운 패러다임이나 .. 문법등을 알게 되고, 신기술도 나오는 것을 보면
+> 계속해서 리팩터링이 필요한 것들을 만드는 듯한 기분..
+>
+> > 늘어만 가는 TODO 코멘트들..
+
+## 테스트하기 쉬운 코드
+
+- 코드를 서로 연결하기 전에 하나하나 철저하게 테스트해라
+
+- 반환된 결과를 이미 알고 있는 값과 비교하거나, 이전에 돌렸을 때 나온 값과 비교하는 회귀 테스트
+  > https://vitest.dev/guide/snapshot
+  > snapshot을 이용한 테스트를 말하는 것 같았어요
+  > 저는 굉장히 재사용성이 높은 상수의 집합에 요것을 적용하고 있어요
+  > ex. 컬러 팔레트라던가 ... css var 맵 같은 것들... (근데 의미있나? 라고 생각해보면 아닐수도..)
+
+- 하위 컴포넌트들이 모두 검증된 후에야, 모듈 자체를 테스트할 수 있다
+
+- 계약을 잘 지키는지 테스트하는 것을 강조함으로써, 우리는 후반부에 벌어질 수 있는 재앙들을 피하기 위한 노력을 할 수 있다.
+> 이미 잘 아시겠지만, 테스트 코드가 인터페이스를 나타내는 문서처럼도 쓰이면 좋더라고요
+
+- 테스트 코드의 위치는 어떤 방식을 쓰던 간에 찾기 편한 위치가 아니면 쓰지 않게 될 것이라는 점을 기억하라
+> 저는 테스트에 필요한 공통 모듈들을 `src/__test__`에 넣고,
+> 찐 테스트 코드들은 바로 옆에 두고 ...
+> foo.ts라면, 유닛 테스트는 foo.test.ts, e2e 테스트라면 foo.spec.ts 같은 확장자를 선호해요
+
+- 테스트 문화
+  - 작성하는 코드는 언젠가는 테스트된다
+    - 우리가 하지 않으면, 사용자들이 하게 된다
+  - 테스트는 기술적이라기보다는 문화적인 것이다
+
+## 사악한 마법사
+
+- 마법사는 일방통행 길과 같음
+- 누구도 자신이 완전히 이해하지 못하는 코드를 내놓아서는 안 된다
+
+> 저는 개인적으로 다작을 하면서 스캐폴딩을 여럿 해봤는데,
+> 이 경험을 통해서도 생각보다 많이 배우더라고용
+
+
+