우선 소스코드가 필요이상으로 분리되어 있지 않아서 전체적인 작동 구조를 한 눈에 파악하기가 쉽습니다.

그리고 적절한 네이밍 컨벤션 등 규칙을 따를 경우에는 순차적으로 읽어 내려가며 원리를 정확히 파악하기에는 좋더군요.

아직까지는 소스 코드 자체가 길어서 읽기 어려웠던 경우는 잘 없습니다.
그보단 잘못된 추상화 등으로 코드 한 줄 수정했다가 디버깅으로 곤욕을 치른 경험이 많네요.

이런식으로 할거면 api에 대해 객체 서로간 간섭이 없도록 잘 설계해야겠죠..
근데 일정이 치이는게 원인이든 미숙함이 원인이든 누군가는 어설픈 추상화로 실수를 하는 것 같습니다.

레이어드 아키텍처든 디자인 패턴이든
더 큰 복잡도를 줄이기 위해 덜 복잡한 방법을 사용하는 것이 기본적인 골자입니다.

경험상 작은 프로젝트에서는 실수가 잘 안생기기는 합니다만, 이런 경우에는 굳이 패턴 적용이 실효성이 있는가 의문이 들었고
프로젝트가 크고 복잡한 경우에는 당연히 분리가 필요해 집니다만,
코드 좀 길어지는게 싫다고 필요 이상으로 추상화하는걸 반대하는 편입니다.


패턴에 대해 구성원간 합의가 된 상황에 서로서로 프로페셔널 하다면 참 좋겠으나.. 현실이 그렇게 녹록치가 않거든요.