소프트웨어 개발의 3개의 KEY 원칙 : KISS,YAGNI,DRY

|



+소프트웨어 책을 몇권 읽다보니 자주 언급되고 중복적으로 언급되는 원칙들과 법칙들이 있었습니다. 원칙과 법칙을 간단히 정리해서 2개의 포스트로 나누어서 글을 올립니다. 여기에서는 우선 소프트웨어를 개발시에 필수로 알아야할 3가지의 원칙에 대해서 소개합니다. 



1. DRY - Don't Repeat Yourself 

 

 : 똑같은 일을 두번하지 않는다. 중복되는 함수나 코드는 하나의 공통의 콤포넌트에 넣고 사용한다. 큰 시스템을 여러 조각으로 나누고 서로 참조한다.


 같은 코드를 중복해서 작성하지 않는다. 시스템이 소규모일때는 복잡도가 크기 않기 때문에 프로그램을 이해하기가 수월한 반면 시스템이 커지고 개념도 많아지면 복잡도가 기하급수적으로 높아지게 된다. 이런 시스템에서는 복잡도를 최대한 줄여야 개발 및 나중에 유지보수비용이 절감이 된다. 


-복잡도를 관리하는 소프트웨어 아키텍처


 프로젝트내에서의 팀별간, 팀내에서 팀원간, 개인내에서도 이런 중복현상은 존재하게 된다. 큰 프로젝트는 여러팀이 개발을 나눠서 작업이 진행이 되고 나중에 통합을 하게 되는데 각각의 팀에서 유일하게 구현되는 코드도 있지만 공통적으로 사용되는 함수나 코드가 존재하게 된다. 각 팀에서 이것들을 따로 구현을 하게 되면 코드중복 뿐만 아니라 나중에 버그가 생겼을 때도 유지보수가 힘들게 된다. 이런 상황은 팀내에서도 존재하게 된다. 팀내에서도 여러 팀원들이 각자의 함수를 만들고 사용을 하게 되는데 여기에서도 공통적으로 사용되는 함수나 코드는 하나의 콤포넌트로 분리해서 공유해야한다. 또한 개인적으로 구현하는 내용중에서도 비슷한 기능을 그냥 Copy & Paste로 함수를 복사하거나 특정 코드를 복사하는 경우가 많이 있다. 이런 경우도 반드시 코드를 함치고 하나의 함수만 참조해야 한다. 코드의 한곳에서 버그가 발생했다면 모든 복사해서 붙이기 한 모든 곳을 수정해야하는 문제가 발생한다. DRY를 위반한 것을 WET이라고 부르는데 이것은 We Enjoy Typing 또는 Write Everything Twice를 의미한다. 




2. KISS - Keep it simple, stupid.


 : 단순하게 하라.


 KISS는 “Keep it small and simple.”, “Keep it short and simple.”, 또는 “Keep it simple, stupid.”를 나타내는데, 소프트웨어 디자인을 간단하고 단순하게 하는 것이다. 알버트 아인슈타인은 "할머니에게 설명할 수 없다면 당신은 제대로 이해한 게 아닙니다"라는 말을 했다. 즉, 큰 프로젝트를 단순하게 디자인 하지 못하고 복잡하게만 구현을 한다는 것은 프로젝트를 제대로 이해하지 못했다는 증거이다. 프로젝트가 진행되기 전에 최대한 기반 배경과 추진되는 목적자체를 이해하고 어떻게 구현을 단순화하고 알기쉽게 설계할 수 있을지 회의를 해서 개선해야한다. ERP를 예를 들으면, 기존의 업무를 분석하고 나서 그대로 구현하는 것이 아니라 조직내의 업무를 다 펼쳐 놓고 중복되는 일이나 잘 못 분배된 업무를 조정하는 것과 불필요한 일들을 제거하는 등의 업무내용을 개선을 먼저 진행을 하고 설계가 진행이 된다.




3. YAGNI - You Ain't Gonna Need it


  : 정말 필요할 때까지 그 기능을 만들지 말라.


 제가 일전의 포스트에서도 농담으로 말한적 있는 (YAGNI 지키지 않으면 야근한다...) 원칙입니다. 현재 필요하지 않지만 향후에 필요가능성을 대비해서 미리 함수나 코드를 작성하지말고 지금 필요한 기능만 추가해야합니다. 미리 필요없는 기능을 추가해두면 코드 자체가 길어지기 때문에 분석자체가 더 어려워지며 또한 버그가 발생 할 가능성이 커집니다. 예를 들어서, DB를 사용해서 조회 및 저장하는 프로그램이 있다고 가정해봅시다. DB종류에는 MSSQL, MYSQL, ORACLE, MariaDB, MongoDB등 다양해서 처음에는 MSSQL만 하다가 나중에 MYSQL이나 다른 DB 타입을 연동이 필요하다고 예상이 되서 DB를 조회하는 비지니스단을 추상화해서 쉽게 전환이 되게 작업을 할 수 있습니다. 물론 나중에 연동을 대비해서 미리 구현하는것도 좋지만 그만큼 시간이 소요되므로 프로젝트으 기간이 늘어나므로 비용적인 부담도 발생이 됩니다. 이럴때 현재 연동할 DB만 연동하는것이 좋습니다. 나중에 다른 DB가 추가되면 그때 작업을 진행하는것이 좋습니다.




<DRY와 YAGNI , KISS 차이점 및 유사점 > 


 -DRY는 시스템을 관리가 가능한 콤포넌트로 나눠서 복잡도를 줄이는 전략이고 YAGNI는 콤포넌트의 갯수를 줄여서 폭잡도를 줄이는 전략이다. 

 -YAGNI는 단순한 프로젝트를 추구 한다는 면에서 KISS와 유사하다. 차이점은 KISS는 가능한한 쉬운방법으로 구현을 통해서 단순한 솔루션을 추구하지만 YAGNI는 구현자체를 하지 않음으로써 단순함을 추구한다.



 추가적으로 : 최소 놀람의 원칙 (the Principle of Least Surprise (POLA)) : 함수나 클래스는 다른 프로그래머가 당연하게 여길 만한 동작과 기능을 제공해야 한다. -클린코드



<참고사이트>

https://code.tutsplus.com/tutorials/3-key-software-principles-you-must-understand--net-25161

And