1부 소개, 2부 프로그래밍 패러다임, 3부 설계원칙(SOLID)를 읽으면서 이 책이 무엇을 말하고싶은지는 이해했고,
당장 아무런 설계와 고민 없이 코드를 짰던 지난 기간을 반성했다.
SOLID, 컴포넌트 원칙, 아키텍쳐 그리고 후반부의 이야기들 모두 같은 맥락으로 말하고 있다.
내가 이번에 가지고 가려고 했던 것
첫번째는 프로젝트를 컴포넌트 단위부터 함수 단위까지 크고 작게 어떤 방식으로 설계를 해야하는지 고민하기 위한 방향성을 잡은 것이고,
두번째는 책에서 무엇을 이야기 하고싶은지 나름대로 파악을 했으니 그걸 어디에서든 적용할 수 있게 책에 나온 모든 케이스를 뜯어보는 것이었다. 한 번이라도 제대로 읽어본 케이스는 빠르게 넘겨 읽었을 때보다 당장 적용하기 쉽기 때문이다.
실제로, 한 기능을 구현하기 위해서 필요한 여러 API를 만들어야 하는데 입사 초반(아직도 겨우 5개월이 안됐지만)에 무작정 작동하는 코드부터 짜서 수정하는 일이 많았다면, 이제는 필요한 API가 무엇인지부터 보고 input, output을 결정하고 스켈레톤 코드를 먼저 작성한다. 어떤 데이터와 로직이 필요한지 스켈레톤 코드로 작성하고 나니 SOLID 원칙을 적용하기가 쉬워졌고, 컴포넌트 단위로 생각하기가 쉬워졌다. 어떤 로직이 어떤 컴포넌트에 위치해야하는지 먼저 결정하고 세부사항을 구현하는 순서로 바꿀 수 있었다. 물론 아직 미처 생각하지 못하는 부분들이 많다는 걸 느끼지만 그래도 당장 한달전보다는 발전했다고 생각하기로 했다.
스켈레톤 코드를 작성하고 실제로 로직을 구현할 때 유스케이스 부분을 읽었는데, 여태껏 내가 구현해놓고 수정하는 일이 많았던 건 유스케이스를 기획서에 보이는대로만 생각했기 때문인 것 같았다. 내가 직접 이 기능을 사용하는 사용자 입장에서 어떤 동작을 할 것인지 생각해보고 필요한 로직이 무엇인지, input과 output은 어떻게 결정해야하는지 생각하고, 기획서에서 고려되지 않은 부분이 무엇인지 개발자 입장으로서도 기획자와 얘기를 해야하는데 그런 고려가 전혀 없어서 화면에서 에러를 띄우고 나서야 아 이게 필요하구나 했다. 깨달은 이상 앞으로는 더 나아지도록 할 것이다.
어떤게 중요하고 중심적인 것이며 세부적인 것인지 구분하려고 하기 시작했다. 그러고 나니 어떤 요소가 어디에 위치해야하는지 조금씩 보이기 시작했다. 그래서 그런지 개인적으로 진행했던 프로젝트 코드는 뜯어보기도 싫어졌지만 입사하고 난 후의 코드는 어느정도 유지보수를 할 수 있을 것 같다.
