지저분한 코드의 악순환 / 깨끗한 코드의 선순환 / 죽은 문서는 만들지 마라.

지저분한 코드의 악순환

1. 지저분한 소스를 탄생시키는 대표적인 경우

2. 무책임한 개발자

3. Case By Case로 땜빵하는 코드

4. 소스의 이해 부족으로 인한 잘못된 수정

5. 높은 결합도로 인한 부작용

6. 문서와 다른 소스

7. "역사적인 이유로~" 라며 시작되는 변명

8. 커뮤니케이션 부족

 코드의 통일성이나 코드의 가독성은 생각하지 않고, 당장 자신의 요구사항만 해결하고 떠나버리는 개발자가 이런 경우에 해당한다. 이런 식으로 누군가 한번 만들면 다른 사람들도 쉽게 무책임해지기 쉽다.

이런 개발자들이 만든 소스는 대게 결합도가 높고 들어낼 수 없어서 울며 겨자 먹기로 계속 가지고 갈 수 밖에 없다. 만약 이런 무책임한 개발자가 자신보다 직급이 더 높다면 해당 프로젝트는 산으로 갈 것이다.

깨끗한 코드의 선순환

1. 다른 개발자들에게 API를 제공한다는 마음으로 개발하라.

2. 남이 봐도 쉬운 코드를 만들어라.

3. '역사적'인 이유를 만들지 말아라.

4. 자신의 코드만 보지 말아라.

5. 기존의 코드와 통일성 있는 코드를 작성하라.

6. 커뮤니케이션 하라.

7. 항상 '1년 뒤에 이 소스를 본다면?' 이라고 생각하라.

8. 리팩토링 하라.

필자가 자주 사용하는 방법 중 하나는 다른 사람의 소스에 대해 거침없이 말하는 것이다.

물론 굉장히 직접적이고 기분이 나쁠 수 있는 방법이다. 

하지만 필자가 다른 개발자의 소스에 대해 이야기할 때 반드시 같이 이야기하는 것은 다른 개발자도 내 소스에 대해 언급할 수 있다는 것이다.

이 모듈은 내꺼니까 나만 잘 볼 수 있으면 된다라는 마음 가진을 위험하다.

항상 열린 마음으로 서로의 소스를 살펴보고 고칠 수 있을 때

그 개발팀은 훨씬 좋은 소스를 얻을 수 있다.

죽은 문서는 만들지 마라.

- 필자가 가장 중요하게 생각하는 부분이다. API 를 개발을 하며 요구사항이 변경되며 그에 따른 API 및 코드의 수정사항은 수정한 담당자만 알고 있다. 해당 API 를 사용하는 사람들에게는 모두 공유해야하며 수정한 이유에 대해서 히스토리를 관리 해야한다.

-패턴 그리고 객체지향적 코딩의 법칙 / 문우식-

기타

- 클린코드 및 지저분한 코드에 관해서 메타포를 깔끔하게 정리한 슬라이드

https://www.slideshare.net/charsyam2/clean-code-pm

- 개발자를 위한 서적을 요약을 매우 잘되어 있는 블로그

http://devsong.tistory.com