[도서] 유지보수하기 어렵게 코딩하는 방법을 읽고

저자는 왜 이 책을 썼을까요..?

책 제목을 보며 처음 들었던 생각입니다.

개발자들 사이에서 농담처럼 언급되는 이 책이, 알라딘에서 무료 E-Book링크 으로 제공되고 있다는 것을 보고 흥미를 느꼈습니다.

제목이 자극적이라 금서처럼 느껴졌지만, 내용을 읽어보니 개발자들이 피해야 할 사항들을 역설적으로 풀어쓴 책이었습니다.

책 내용은 유지보수를 어렵게 만드는 방법들로 가득 차 있지만, 요즘의 개발 도구들은 워낙 잘 되어 있어 저자의 지침을 따르기도 어렵다는 생각이 들었습니다.

저자는 마지막에 농담이라는 것을 강조하며, 이 책의 내용을 진지하게 받아들인 독자가 있다면 정중히 사과한다는 말을 남겼습니다.

그래도 그 중에 인상 깊었던 내용을 몇가지 정리했습니다.

• 표준을 무시하라

문법적으로 어쩔 수 없는 경우가 아니라면 절대로 if/else 블록을 감싸는 괄호 {}를 사용하지 말자. 들여쓰기 없이 if/else와 블록을 여러 단계로 중첩한다면 전문 유지보수 프로그래머라도 가볍게 해치울 수 있다.

펄Perl을 사용하면 이 기법의 효과가 극대화된다. 일반 코드 뒤에 if문을 양념으로 추가하는 것도 좋은 방법이다.

• 지옥에서 온 탭

탭을 과소평가하지 마라. 탭이 얼마나 공감을 나타내야 하는지에 대한 표준이 없는 회사에서는 공백 대신에 탭을 사용하므로 큰 혼란을 야기할 수 있다. 스트링 문자열에 탭을 추가하거나 공백을 탭으로 변환해주는 툴을 돌리는 것도 좋은 방법이다.

• 삼천포로 인도하는 이름

메소드의 이름이 의미하는 것보다 더 많은(혹은 더 적은) 동작을 수행하도록 프로그래밍하자. 예로 isValid(x)라는 메소드에 기능을 추가해 x값을 이진수로 변환하고 결과를 데이터베이스에 저장하도록 구현한다면 모두가 깜짝 놀랄 것이다.

• 아름다움을 멀리하라

절대 자동 코드 정렬 기능으로 코드를 정렬하지 말자. PVCS/CVS(버전 관리를 이력으로 추적하는)에서 가짜 정보를 만드는 이와 같은 도구를 사용하지 않도록 회사 현장에서 로비를 하자.

또는 모든 프로그래머는 자신이 만드는 모듈에 영원히 신성 불가침한 자신만의 들여쓰기 방식을 가져야 한다고 주장하자.

이 밖에도 그럴 듯 한 내용들이 조금 있었지만.. 음 그렇습니다.

유머와 역설로 풀어 쓴 내용이지만, 한 번쯤 읽어보면 유지보수와 관련된 교훈을 얻을 수 있는 책이라고 생각합니다.. :D