TIL 23

• 문서화를 못한다는 것은 코딩을 못하는 것과 동일한가? => 맞는 것 같음. 문서화 못하는 사람들은 체계적으로 코드를 관리하지 못하는 것도 잘 못하는듯. 생각해보면 동일한 작업임.

• onion, clean, hexagonal 이야기를 직장 동료와 함. 그 분은 oop스럽게 clean 으로 가는 것이 js에서는 혼란스럽고 갈거면 fp로 가는 것이 나을 것 같다고 함. fp로의 접근도 고민해볼 필요있다고 생각이 듦.

• clean architecture srp, dip 읽음

TIL 24

Clean Architecture

• One of my coworker said => all other architectures(onion, clean, hexagonal etc.) are also layered architecture => I was shocked that 8 y o experience backend engineer said this. => seems like he had different philosophy about this. He said he thinks "layered architecture" equals "architecture that has layers". In my opinion they differ big time. Layered architecture is commonly used to refer to architecture that has infrastructure as the deepest layer.
• He also said everything that does two things equals not conforming to SRP. => also shocked me. => but seems like the opinion itself makes sense, but not commonly used. SoC is better way to put it. the philosophy itself seems to be ok. In my opinion, usually srp is for single module or single class, not for any "thing" in the world.

Clean Architecture 2

• ocp랑 dip랑 매우 밀접한듯? => DIP is one way to achieve OCP.

Clean Architecture 3

clean architecture에서는 Service를 domain, application으로 나눈다.

domain이 명사이고 application은 동사인 느낌이다.

domain에는 엔티티와 각 엔티티가 어떤 행위가 가능한지만 적혀있고 행위는 application의 usecase에 적힌다.

도메인 계층을 domain이라고 부르는 것은 별로 screaming 하지 못하다. 도메인 계층은 service-verbs, application 계층은 service-nouns가 더 직관적이고 screaming하다. domain, application은 너무 다른곳에서도 자주 쓰이는 표현이다…

공부에는 실무가 선행되는 것이 10x 개발자의 길

최근 반복적으로 느끼는 깨달음 - software 책은 그 자체로는 배우기가 어렵다. 속도가 매우매우 느리다. 관련 실무를 먼저 해야 압도적인 속도로 책을 소화하고 내것으로 만들 수 있다. 그렇기 때문에, 어떤 행위를 하기 위해 먼저 그 원칙들을 읽는 것은 미친짓이다. 무조건 수많은 실수를 실무에서 먼저 만들고, 그 원칙들을 읽으며 고민하는 것이 5~10배 이상 빠르다. 진짜다. 1달 내내 그런 책들을 달달 암기한 후에 실무 1달을 해도 어차피 다시 1달 동안 그 원칙들을 이해하고 소화하고 적용하고 고민해야한다.

고로,

• 관련 지식 먼저 읽기: 1달 이해 못하며 읽기 => 2달 실무하며 고민 엄청하며 적용해보려고 노력 => 1달 다시 고민하며 읽으며 수정
• 관련 실무 먼저 하기: 1달 실수 왕창하면서 나만의 방식으로 작성 => 1달 고민하며 읽으면 모든 인사이트 빠르게 흡수

시간만 보더라도 최소 2배빠름. 근데 내가 먼저 나만의 방법으로 해보는게 중요함. 뒤에 책 읽을 때 이해도가 몇 배가 늘어남.

위 내용을 깨닫고 뭔가 개발자로서 레버리지할 수 있고 가장 빠르게 잘해지는 방법론 자체를 책으로 집필할 수 있겠다는 근자감이 생김.