소프트웨어 개발의 3가지 원칙

이전에 블로그로 내가 믿지 않는 3가지를 정리했었다. 반대 개념으로, 내가 개발할 때 원칙으로 삼는 3가지도 있어서 정리해본다.

1. Don't Repeat Yourself
비슷한 우리말로는 "삽질금지"정도 될 것 같다. 같은 작업을 반복하지 말라는 뜻이다. 

리팩토링에서도 3번째 반복할때 리팩토링 하라고 나온다. 좀 더 엄격하게 적용한다면 소스코드를 복사/붙여넣기를 하려고 할때 그러지 말고 Extract스러운 리팩토링을 진행한다.

프로그래밍의 영역뿐만 아니라, 문서 작성을 할 때도 같은 파일을 조금씩 고치면서 "_최종", "_진짜최종", "_진짜진짜마지막" 파일들을 만들고 있다면, 그만두고 문서파일의 버전 관리를 해야한다.

반복된 작업은 내가 아니고 컴퓨터가 하게끔 해야한다. 프로그래밍을 할 때는 공통로직은 공통모듈을 만들어서 호출하게 한다. 타이핑을 할 때는 멀티블록이나 컬럼블록 기능이 있는 에디터를 사용해서 한번의 타이핑으로 끝낸다. 내가 사용하는 키보드에서는 하드웨어 매크로 키가 있어서 자주 쓰는 문구를 M1,M2,M3,M4로 지정해서 사용한다. 

2. Make it work, Make it right, Make it fast
켄트벡이 유닉스웨이라는 글에서 한 말이라고 한다. 직역하면 일단 돌아가게 만들고, 올바르게 만들고, 빠르게 동작하도록 만들라는 말이다. 받아들이는 사람에 따라서 "work", "right", "fast"에 대해서 해석의 차이가 있는 듯 하다. 그리고 3단계를 적용하는 시점도 단기적으로 볼 것인지, 장기적으로 볼 것인지에 따라서도 해석이 다르다.

나는 "work"를 "기능이 동작하는"으로 해석한다. 내부 구현 로직이나 소스코드의 아름다움따위는 생각하지 않고 사용자 관점에서 기능이 동작하게 만들면 "Make it work"한 것이다.

"right"는 유연한 아키텍쳐와 깨끗한 소스코드, 풍부한 테스트코드로 해석한다. 당장의 기능 동작을 물론이고, 앞으로의 기능동작을 위한 사전 작업이랄까. 앞으로 기능 변경시에 적은 수고로움으로 빠르게 고칠 수 있는 상태로 만든다면 "Make it right"한 것이다.

"fast"는 성능 튜닝으로 해석한다. 기능이 사용자가 원하는 수준의 성능으로 동작하지 못 할 때, 동작하도록 만드는 것이 "Make it fast"이다. 그래서 사용자가 원하는 수준이 낮다면 이 단계까지는 이르지 못 할 수도 있다.

이 3단계를 반복하면서 경험이 쌓이게 되면 "work"하게 만들면서 "right"을 생각하게 된다. "Make it work and right"이 되는 것이다. 예측 가능한 변경점을 고려하여 처음 부터 설계하는 것이다. "fast"를 미리 생각하면서 프로그래밍할 경우는 많지 않았지만, "not slow"하게 만드는 것은 미리 생각하는 정도이다.

3. Do not reinvent the wheel

바퀴는 이미 만들어져 있는 것이지 또 만들지 말라는 말이다. 수많은 라이브러리의 같은 기능을 스스로 다시 구현하지 말고 가져다 쓰자는 말이다. 나는 이를 조금은 철저히 지키는 편이다. 내가 구현한 소스보다 누군가가 구현하고 테스트한 소스가 더 견고하다는 믿음이 그 기반이다. 좋은 라이브러리는 좋은 구조로 설계되어 있고, 자연스럽게 SRP 원칙이 잘 지켜져 있는 편이므로 결과적으로 나의 소스코드도 좋은 설계로 이끄는 경향이 있다.

얼마전에 nodejs쪽에서 발생한 사태는 오히려 이 원칙의 부작용을 설명하는 듯 하지만, 사실 그 사건은 "바퀴"가 문제가 아니라 바퀴만드는 "사람"이 문제였던 사건이므로 부작용이라고 할 수는 없을 것 같다.

회사와 개인의 프로젝트를 진행하면서 프로그래밍과 관련된 판단을 내릴 때 위의 3가지 원칙을 기준으로 삼고 결정을 하도록 노력하는 편이다.