그냥 그때마다 이 양반은 이렇게 생각하는구나 처럼


거진 프로그래밍 실무서적이라는게 대부분


문제 정의를 어떻게 하느냐 라는 일종의 프레임 제시라서


언어라는 도구의 결이 달라지니까 사용법도 달라지고 이렇다보니 문제 정의방법도 달라짐


00년대 책들보면 객체지향,과잉 추상화


10년대는 SOLID와 클린 코드


20년대는 FP,DOP와 실용주의 


그리고 저자의 성격마다 코드 강점이 다르고


구글 경험자들 책은 대부분 규약 중시하고,


펌쟁이 개발자들은 대부분 인터페이스 API랑 테스트 중시하고


그렇다보니 도메인 넘나들면서 문제 정의를 보는거지.


당장 패턴도 과잉 패턴 설계가 될때가 있으니


가령 00년대 OOP에서는 AbstractFactoryImpl 같은거 많이 나왔단 말이지. 이게 뭐냐면 그냥 전체적으로 변경을 존나 쉽게 하지만 실 구현이 없어서 살 붙이기가 힘들었음


그다음 10년대 들어서는 이런 고차 추상화나 과잉 추상화를 없애고 읽기 좋은 코드라는 클린 코드 위주의 중심이고


20년대 책 들어서는 불변성, 모나드를 전제로 데이터를 흐름으로 전제하는데 사실 분산 시스템상에서 state를 관리가 힘든거고


실제로 책들보면 보편적 진리를 말하는듯하지만 한 걸음 뒤에서 보면 자기 도메인에서의 최적해임


구글 출신들 책보면 일관성,린트, 컨벤션을 중시하라 하지만


막상 사실 뭐 현장 코드에서는 린트,컨벤션보다는 API 경계랑 테스트만 명확하면 내 영역밖에 있는 부분 전체를 다 관리할 수가 없는 공장형 코드가 되는 경우가 대부분


전체 코드를 조망할 수 있는 사람은 거의없다보니.


결국 프로그래밍이라는게 패턴을 쓰는것보다 안 써야 할때를 아는게 더 대단하다 생각.


그렇다보니 코딩 서적보면 저자 이력 먼저 가장 먼저 보고 저자가 싸웠던 문제가 무엇인가 생각하게됨


당장 MSA도 그런 유형에서 나온 문제였고


당장 자바 개발자가 객체 만드는것부터 생각하지만 C#개발자는 이벤트 기반의 흐름을 생각하듯 


내가 든 망치가 무엇이냐에 따라서 세상 모든 문제가 망치에 맞는 못으로 보이는거지.


결국 책이 중요한게 아니고, 내 앞에 놓인 문제에 대해서 올바른 도구를 선택할 수 있는 그 지향점의 마인드가 프로그래머가 아닌가 싶기도 하다.