첫번째.
정말 많은 객체들의 동작들이 서로 연결되어 있다. 지금 하는 개발이 다른 객체들에게 어떤 영향을 주는지를 정확하게 알아야 하고, 역할을 분리해야 하고 등등.. 처음에 각 도메인들 CRUD 식으로 도메인 개발할 때야 쉬웠지만, 심화되다보면 빼먹은 비즈니스 로직, 변하는 비즈니스 로직에 따라서 이 어찌어찌 얽혀있는 것들을 계속 풀어내야 한다. 그쯤되면 앱이 더러워 보이고, 키기 무서워지고, 다시 하고 싶거나, 그만하고 싶어진다. 이럴 때 믿을건 Test 코드들 뿐인 건 공감한다. 하지만 Test 들도 언제나 프로젝트 처음 시작할 때 만든 나의 Test 는 개판이고 쓰레기라, 유지보수 덩어리로만 보인다.
이 임계지점을 넘어야 하는 것 같다. 그래야 SW 가 나오는 것 같다. 토이성 프로젝트로 만드는 웹사이트 따위가 아닌, 실제 운영 기반을 위한 서비스는, 반드시 이 임계지점이 등장하게 된다. 이 때 계속 Test 를 통해 보수해가며, 튼튼한 앱을 만들 수 있을 때 진짜 성장할 수 있을 것 같다. 나는 아직 이 임계 포인트를 못넘은 것 같다.
두번째.
빈에 목숨을 걸 필요가 없다. 나는 스프링으로 개발을 하는거지 스프링을 위한 개발을 하는게 아니다. IoC 는 스프링이 프레임워크니까 그냥 그런거고, 개발의 주체는 내가 되어야 한다. 빈으로 주입하는건 결국 Dependecy 방식이다. 클래스 간 관계를 잘 생각하면서 어떤게 좋을지 판단을 계속 잘 해나가야 한다. 특정 도메인에서 한두번만 쓰일건 굳이 싱글톤으로 힙메모리를 차지하고 있을 필요가 없다는 것이다. 그 때 그 때 일시적으로 사용하고 버릴 줄 아는 util 성 객체들까지 다 빈빈 거리면서 빈화할 필요가 없다. 내가 아는 객체지향이 우선이다. (https://mooncake1.tistory.com/118)
세번째
테스트는 중요하다. 하지만, 너무 많은 테스트는 오히려 유지보수에 부담을 준다. 앱이 전체적으로 한바퀴 돌면서 비즈니스 로직이 어느정도 안정화 되고, 시스템 로직이 가춰진다면 (처음에 말한 임계지점을 넘어선다면), 그 때까지는 성공 Case, 그리고 대표적 실패 Case 정도만 검증해 나가는 것도 좋아보인다. 너무 많은 Test 가 앱을 만들면서 바뀌기 때문이다.
물론 설계 오래 안해서 그럴 수도 있다. UP 돌리기 이런거 안하고, 필요한 부분만 그리면서 하니까. 그것들이 인 앱에서 어떻게 소통하는지 정확하게 모른채로 개발 시작하니까. 근데 요구사항 하나하나 이런거 정확하게 뽑아내는거 솔직히 난 좀 아직 공감이 안간다. 그래서 어느정도는 개발하면서 진행이 필수적이라고 본다. 따라서, SW 개발 처음과, 중간, 마지막 시점에서 Each 비즈니스 로직 코드들이 같은 경우는 0%라고 생각한다. 따라서, 추후 유지 보수성을 어느정도 대비하면서 프로젝트를 진행하는건 어떨까?
