소프트웨어 '설계'는 왜 해야하는가

 

 

 

좋은 코드란?

변경 용이성, 유지 보수성을 갖춘 코드다.

읽기 좋은 코드가 성능 개선된 코드보다 낫다.

 

Legacy 코드는 곧 변경이 어려운, 유지 보수하기 어려운 코드다.

 

응집도

클래스의 응집도가 낮으면 API 변경 시 수정 누락으로 버그가 발생할 수 있다.

(거대한 클래스를 만들고 그 클래스의 메소드 변경시 해당 클래스에 의존하는 다른 모듈에서 에러가 발생할 수 있다.)

 

가독성

개발자는 코드를 짜는 시간보다 읽는 시간이 길다.

가독성이 떨어진단 얘기는 많은 시간을 이해하는데 소모하게 한다는 것이다.

즉, 생산성 저하가 발생한다.

 

나무꾼의 딜레마

한 나무꾼이 나무를 베느라 낑낑대고 있었다.

지나가는 행인이 말했다.

"도끼를 좀 갈고 베야하지 않을까요?"

나무꾼은 대답했다.

"급해서 도끼를 갈 시간이 없습니다"

 

나무를 베는 시간 == 로직 구현 시간
도끼를 가는 시간 == 설계 시간

시간이 흐를 수록 도끼를 미리 간 쪽이 생산성이 좋을 수 밖에 없다.

우리는 이미 안다.

이제 실천할 일만 남았다.

 

제대로 설계하지 않으면 로직 변경과 디버깅에 많은 시간을 쏟아야 할 것이다.

 

기술력과 연봉

좋은 설계는 소프트웨어 성장 가능성을 높인다.

구린 설계는 레거시 코드를 만들고, 인수인계 후에 후임자나 신규 입사자로 하여금 추가 레거시 코드를 생산하게 만든다.

=> 기술력 상승 지연 => 연봉 상승 지연.