개발과 일상

테스트를 도입하면서 다양한 정보를 얻고 싶어서 들은 강의 중 하나인데... 개인적으로는 솔직히 실망스럽다. 정확히는 제목 값한다는 표현이 맞다. 가장 강조되야할 부분은 "하루만에" 다. 다양한 사례나 테스트에 대한 본인의 철학이나 엣지 포인트들을 짚어주는 그런 강의를 기대하면 안된다. 테스트에서 가장 중요한 부분은 어떻게도 중요하지만, 무엇을, 왜, 언제라고 생각하는데 이게 딱 빠져있다. 무엇을 : 프로젝트에서 어떤 부분을 테스트해야 하는가? 테스트에는 어떤 방식이 있는가?왜 : 이 테스트가 왜 필요한가? 테스트를 안할 경우 어떤 문제가 생길 수 있는가?언제 : 언제부터 테스트가 필요한 상황일까? 이런 상황에서는 어떤 테스트를 적용해야하는가? 사실 어떻게도 부족한 것 같다. 정해진 시간에 많은 걸 담으려..

이 책의 제목을 보고 클린 코드고 클린 아케틱처고 이론은 다 알겠지만 복잡한 우리 회사 프로젝트에는 어떻게 적용할지 잘 와닿지 않았는데, 드디어 내가 원하던 그 책인가! 라고 생각하는 독자가 계시다면 안타깝게도 그렇지 않습니다. 하지만 코드를 짜며 클래스 간의 의존관계는 어느정도로 허용해야 하고, 패키지 레벨은 어떻게 나눠야 하는지 등을 끊임없이 고민하는 분들이라면 이 책에서 조금의 힌트는 얻을 수 있으리라 생각합니다. - 역자 서문  역자 서문의 첫 구절이 이 책의 완벽한 요약이다. 애초에 책 한권이 복잡한 프로젝트의 아키텍처 문제를 해결해 주길 바란다면 그것만한 도둑놈 심보가 없다... 나는 2년 전 쯤, 이 책을 한번 구입했다가 환불했었다. 당시에는 헥사고날 아키텍처에 대해 전혀 알지 못했기 때문에..

2~3가지 서비스를 거치면서 개발했던 방식은 Layered 아키텍처를 벗어난 적이 없다. 6년짜리 레거시 코드를 Layered 아키텍처로 운영/개발할 때도 큰 불편함을 느끼지 못 했었다. 당시를 떠올려보면 그렇게 생각했던 이유가 몇 가지 있는데.. 1. 테스트를 구현하지 않았음2. 불행인지 다행인지 레거시 코드를 수정할 일이 거의 없었음3. 서비스의 규모와 팀의 규모가 크지 않았음4. R&R을 나누는 직급이 아니었음 이 정도가 아닐까 싶다. 그러나 이직 후 업무 분담도 하는 직급이 됐고, 서비스 규모가 점점 커지면서 운영 개발 건이 늘어나다보니 Layered 아키텍처의 문제를 느끼게 됐다. (내가 느꼈던) Layered 아키텍처의 문제  1. Service가 너무 커져서 파생되는 문제들- 어떤 기능을 추..