소프트웨어 개발시 설계부터 잘해야한다는 말을 나는 반대한다.
어설프게 설계부터 먼저하면 나중에 고통 받는 일이 더 많아진다. 처음부터 완성되어 있는 설계가 어딨나. 많은 메이저 소프트웨어들이 처음 설계 보면 겁나 구리고, 그래서 하위 호환을 무시하고 완전히 새로운 패러다임으로 넘어가는 것이 비일비재하다.
분야에 따라 다를 수 있지만, 보통 소프트웨어 설계는 구현에서 따라오는 것으로 단계적으로 진행되는 것이지, 설계부터 시작하는 건 패망의 지름길이다.
더군다나 코딩 속도가 빨라지고 자동화되는 AI 시대에 오히려 설계는 구현 다음이 될 수 밖에 없다. 왜냐하면 구현을 오늘 당장 해 볼 수 있기 때문에 구현을 먼저하고 이를 토대로 설계하는 것이 훨씬 나은 선택이다. 실험적 설계라고 한다.
설계가 가장 중요하고 설계부터 시작해야한다는 건 컨설팅 업체에게나 유리한 맥락이다.
더 많은 콘텐츠를 보고 싶다면?
이미 회원이신가요?
2024년 8월 4일 오후 1:01
댓글 7
설계보다 구현을 우선시하면, 클라이언트에게 맥락만 던져놓고 구현을 못하거나, 구현하고 있는데 클라이언트가 기능의 흐름을 변경했을 때 대처하기 어렵습니다. 이 글에서는 너무 과도한 설계가 유연성을 해치는 결과를 말하고 있는것 같은데 적당한 설계는 진행되어야 합니다. PoC 단계에서는 설계보단 구현이 먼저겠지만요. 소프트웨어 개발에서 설계는 중요한 단계라고 생각합니다. 팀원끼리의 컨텍스트를 맞출 수 있고, 다양한 기술도 접목할 수 있는 기회가 되니까요.
@Rhino 좋은 인사이트 b
@Rhino 전혀 공감가지 않는 글이네여
과도한 설계도 독이 되지만 그렇다고 설계가 아예 없으면 지도 없이 항해하는 것과 같습니다. 뭐든지 적당한게 좋은거죠 ㅎㅎ
저는 이러한 방식을 "의식의 흐름 코딩" 이라고 하는데 이러한 방식이 좋은 케이스들도 있고 아닌 경우도 있다고 생각합니다! 좋은 경우 1. 합의된 룰이 있는데 이를 지켜야할 때 2. 유지보수 및 안정성의 가치가 더 중요한 경우 3. 비즈니스적 명확한 '목표'가 있는 경우 나쁜 경우 1. 명확한 목표는 없고 일단 만들어 빠르게 검증되어야 하는 경우 2. 합의된 룰을 만들어 나가는 경우 무조건 반대, 무조건 좋아 이런 것보단 조금 더 유연함이 필요하지 않을까 합니다. 각자의 가치는 명확히 다르다 생각합니다. 나아가 처음에는 다들 구리고 빈약하다 했는데 어느 정도 안정기가 찾아온다면 "소프트웨어 설계"는 아주 중요하다 봅니다. 소프트웨어 공학이라는 개념으로 따로 나올 만큼요!
네, 동의하지 않습니다. 쓰신 내용의 예가 바로 좋지 않은 설계로부터 시작되었다는 근거네요. 좋은 설계의 기본 중 하나는 변화에 유연하다는 거구요, 그렇지 못하다면 정확한 핵심 요구 사항을 파악하지 못했다는 반증이죠.
다른분들이 잘 적어주셨지만 설계는 필요합니다. 그래야지만 개발의 방향성이 잡히니까요. 예를들어 레고를 만든다고 할때 설명서(설계문서) 없이 조립부터 시작하는거랑 같기에 이는 동의하지 않아요
