저는 사수나 팀원들의 도움을 받을 수 없는 환경에서 닷넷을 시작했는데, 구글링으로 그 때 그 때 필요한 코드만을 찾다가 MVVM 패턴에 대해 다루는 블로그 아티클을 통해 MVVM 패턴을 알게 되면서 이후로는 좀 더 거시적인 프로그래밍 방법론으로 분야를 넓혀 공부하고 있습니다.
1의 경우 각자 처한 환경이 다르고, 회사의 개발 문화가 다르며, 프로그램의 구조가 다르기 때문에 정답이 없는 문제라고 봅니다. 가령 다형성을 염두에 두고 설계를 한다면 코드 결합성을 낮추고 유연한 개발을 돕는다고 하지만, 그 다형성을 구현하는 방법만 놓고 보더라도 개발자별로, 프로그램의 목적별로 다를 수밖에 없습니다. 사실 괄호를 어떻게 열고 닫느냐만 가지고도 사람마다 취향이 갈리니 당연한 문제라고 봐야겠죠.
따라서 기본적인 프로그래밍 방법론을 토대로 많은 코드나 아티클을 찾아보면서 본인이 스스로 잡아나가는 게 좋다고 생각합니다.
MVVM 패턴을 예시로 들면 뷰와 뷰모델, 모델을 분리한다는 원칙은 동일하지만 어떤 방식으로 놓고 분리할 것인지만 해도 사람들마다 차이가 있습니다. 또, 결합성을 낮추기 위해 프로젝트 구성 요소를 별도의 어셈블리로 철저히 분리하는 사람이 있는 반면, 동일한 어셈블리 내에서 분리하거나 경우에 따라서는 효율적인 프로그래밍을 위해 오히려 결합성을 본인만의 적정선까지 올리는 경우도 있습니다.
아티클도 코드만 복붙해 단순히 어느 기능을 하는 코드만 알려주는 아티클이 있는 반면, 코드 자체보다는 좀 더 방법론적인 목적으로 접근하거나 코드에 작성자 본인의 코멘트를 정성스럽게 곁들인 아티클도 있습니다. 이런 아티클에는 그 사람의 생각이 담겨 있습니다. MVVM 패턴에 관한 아티클이 있다고 치면, 기본적인 샘플 코드와 MVVM 패턴에 대한 본인의 생각이 첨부된 아티클은 이 사람은 MVVM 패턴을 어떤 식으로 접근하고 있는지에 대해 많은 영감을 줍니다. 커뮤니티에서 질문을 작성하거나 토론에 참여해 보는 것도 다른 사람들이 어떻게 생각하고 있는지 알아보는 것에 도움이 됩니다.
최대한 많은 코드를 보고, 많은 아티클을 보고, 커뮤니티 활동도 많이 하면서 이 사람은 왜 이렇게 설계했는지, 어떤 방식으로 접근하고 있는지에 대해 고민하다 보면 결국 본인에게 알맞는 정답을 찾을 수 있을 거라고 믿습니다.