소프트웨어 개발 3개 KEY 원칙

✏️ 클린 코드를 만드는 법에 대해 공부해보자 🙂

사실 오늘 개발사 대표님이랑 이런저런 얘기를 나누다가, 모르는 내용이 나와서 후다닥 공부 & 정리해보았다. 1번 DRY, 2번 KISS는 용어는 몰랐어도 대충 알고있었지만, 3번은 조금 의외였다. 또 생각해보니 리즈너블하다. 야근은 하고싶지 않으니..

1. DRY – Don’t Repeat Yourself

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

Dry는 일반적으로 중복 코드를 나타낸다. 동일한 논리를 두번이상 작성하면 좋지않다.

Example ( with code repetition)

//flow A
let username = getUserName();
let email = getEmail();
let user = { username, email };
client.post(user).then(/*do stuff*/);

//flow B
let username = getUserName();
let email = getEmail();
let user = { username, email };
client.get(user).then(/*do stuff*/);

DRY example:

function getUser(){
	return {
		user:getUserName();
		password:getPassword();
	}
}
//flow A
client.post(getUser()).then(/*do stuff*/ );
//flow B
client.get(getUser()).then(/*do stuff*/);

프로젝트내에서의 팀별간, 팀내에서 팀원간, 개인내에서도 이런 중복현상은 존재하게 된다. 큰 프로젝트는 여러팀이 개발을 나눠서 작업이 진행이 되고 나중에 통합을 하게 되는데 각각의 팀에서 유일하게 구현되는 코드도 있지만 공통적으로 사용되는 함수나 코드가 존재하게 된다.

각 팀에서 이것들을 따로 구현을 하게 되면 코드중복 뿐만 아니라 나중에 버그가 생겼을 때도 유지보수가 힘들게 된다. 이런 상황은 팀내에서도 존재하게 된다. 팀내에서도 여러 팀원들이 각자의 함수를 만들고 사용을 하게 되는데 여기에서도 공통적으로 사용되는 함수나 코드는 하나의 콤포넌트로 분리해서 공유해야한다. 또한 개인적으로 구현하는 내용중에서도 비슷한 기능을 그냥 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 Aren’t Gonna Need it

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

현재 필요하지 않지만 향후에 필요가능성을 대비해서 미리 함수나 코드를 작성하지말고 지금 필요한 기능만 추가해야한다. 미리 필요없는 기능을 추가해두면 코드 자체가 길어지기 때문에 분석자체가 더 어려워지며 또한 버그가 발생 할 가능성이 커진다.

예를 들어서, DB를 사용해서 조회 및 저장하는 프로그램이 있다고 가정해보자. DB종류에는 MSSQL, MYSQL, ORACLE, MariaDB, MongoDB등 다양해서 처음에는 MSSQL만 하다가 나중에 MYSQL이나 다른 DB 타입을 연동이 필요하다고 예상이 되서 DB를 조회하는 비지니스단을 추상화해서 쉽게 전환이 되게 작업을 할 수 있다.

물론 나중에 연동을 대비해서 미리 구현하는것도 좋지만 그만큼 시간이 소요되므로 프로젝트의 기간이 늘어나므로 비용적인 부담도 발생한다. 이럴때 현재 연동할 DB만 연동하는것이 좋다. 나중에 다른 DB가 추가되면 그때 작업을 진행하는것이 좋다.

또 하나의 예로, 블로그 포스팅을 읽고 이번에 진행할 프로젝트를 React로 개발하기로 결정했고, flux / state 관리를 위해 Redux를 사용하기로 결정했다. 그런 다음 파일들을 처리하기위해 작은 nodejs 서버를 설정하기로 했다.
또 , 어떤 이유로든 실시간 알림이 필요한 경우를 대비해 Socket.io를 추가했다.

멋진 웹페이지 프로토 타입이 완성되었다. 근데 제품을 요청한 클라이언트는 해당 페이지를 스크린샷을 찍어서 ppt에 넣었다…..

스크린샷 하나를 위해 저 많은 기능을 넣은것이다. YAGNI…

야근하고싶다면 …. 그렇게하자

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

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

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