[3부 코드의 모습] Chapter15 소프트웨어의 진화 또는 혁명?

소프트웨어의 부패

언제든지 소프트웨어 개발 기간 중에서 유지보수 국면이 가장 오래 걸린다

프로젝트가 완료되었다고 간주된 다음에 더 많은 코드가 작성된다

유지보수 프로그래머는 원작성자의 머리 속에 있는 코드 모델을 알지 못할 수 도 있다; 그것이 적절하지 못한 수정의 원인이 된다

코드를 수정하다가 품질이 떨어지기는 아주 쉽다는 사실을 알아두자. 시스템을 더 나쁘게 만드는 변경을 하고서 만족스러워하지 말자

 

경고 신호

• 규모가 큰 클래스와 복잡하고 이해하기 어려운 함수들이 코드 여기저기에 많이 흩어져 있다
• 함수 이름이 암호 같거나 오해를 하게 만든다
• 구조가 없다: 어떤 기능을 어디에서 찾을지가 명료하지 않다
• 중복이 있다: 똑같은 일을 하는 코드 조각이 여러 번 나타난다
• 커플링이 높다: 의존성이 높다
• 데이터가 여러 가지 표현으로 자꾸 변환된다
• API가 불명료해지고 있다
• 코드 리비전마다 API가 급격히 달라진다
• 다른 부분을 급하게 해킹하기 위해 퍼블릭 API를 통해 프라이빗 코드를 밖으로 유출한다
• 코드 여기저기에 대충 처리한 부분이 있다
• 엄청난 파라미터 리스트를 갖는 함수가 있다. 하지만 많은 함수들이 그 파라미터를 사용하지 않고 하위 함수를 호출 할 때 넘겨주기만 한다 - > 그럼 어떻게 해야할까?
• 개선할 엄두도 낼 수 없을 만한 코드를 보게 된다
• 문서나 기록이 전혀 없이 새로운 기능이 추가 된다 ->문서를 꼭 작성하자
• 코드를 컴파일 할 때 많은 경고가 생성된다
• "여기에 손대지 마시오…" 코멘트가 보인다…

 

우리는 왜 이런 커다란 코드 난장판을 만드는 것일까? 복잡성 때문!!!

 

코드는 어떻게 성장하나?

계속 움직이는 골대를 목표로 삼는 점증적인 개발의 사이클이다

운에따라서

코드가 원래 아주 신중하게 설계되었더라도 유지보수를 하면서 수정을 할 때 운에 내맡기는 식의 이런 접근방법을 따를 수 있다

퇴적 작용에 의해

기존 모듈에 새로운 코드를 매달 것이고, 그 코드는 자기의 특별한 백도어 인터페이스를 통해서 기존 모듈과 의사소통을 할 것이다.

재작성에 의해

경험에 따르면 원래 있던 난장판의 코드를 해킹하는 것보다는 대개 재작성을 하는 것이 더 빠르고 안전하다

한꺼번에 많은 코드를 공략할 경우에 더욱 위험하다

리팩토링에 의해

리팩토링은 코드의 외부 동작을 바꾸지 않으면서 내부 구조를 개선하기 위해 코드 본체에 작은 변경을 가하는 공정이다

성장을 고려한 설계

시스템이 어떻게 확장될지에 대한 실마리가 없더라도 미래에 대한 예측을 하자. 확장 가능성은 복잡성을 대가로 치르고 얻을 수 있다

 

불가능한 것 믿기

해킹하듯이 정정을 하면 결함 리포트 하나는 빠르게 종결 지을 수 있을지 모르지만, 그것은 좋은 솔루션이 아니다. 진정한 장인은 자기가 한 일에 대해서 책임을 진다

 

우리가 할 수 있는 일은?

가장 중요한 단계 문제점을 인식하자

훌륭한 프로그래머는 지금의 코드 작성에 얼마나 많은 노력이 드는지 보다, 몇 년 후에 자기 코드가 어떻게 보일지에 더 많은 주의를 기울인다.

새로운 코드 작성하기

• 모듈 간의 상호 연결에 대해 깊이 생각하고 가능한 한 의존성을 줄이자
• 모듈화와 정보 은닉은 현대 소프트웨어 엔지니어링의 초석이다
• 설계에 확장성과 유연성을 포함시켜야 할 필요가 있다
• 훌륭한 문서화와 명료한 이름이 붙은 잘 정의된 API를 가지고, 이해하기 쉽고 작성하기 쉬운 깔끔하고 명료한 코드를 작성하자
• 지나치게 복잡하기 만들지 말고 지나치게 교묘하게 만들지도 말자

새로운 코드를 작성할 때는 수정 가능성을 바라보면서 하자. 읽기 쉽고, 확장이 가능하고, 간단한 코드가 되도록 만들자

기존 코드의 유지보수

• 필요한 모든 변경의 우선순위를 매기자
• 필요한 것만 변경하자
• 한 번에 얼마나 많은 수정을 하고 있는지 모니터링하자. 한번에 하나만 하고 조심스럽게 하자

주의를 요하는 미묘한 변경을 리뷰하라

• "경고 신호"에 있는 신호들을 계속 의식하라
• 코드를 유지보수할 때는 소스 파일의 프로그래밍 스타일을 유지하라

정정할 계획도 세우지 않고 실용성에 기초한 (하지만 끔찍한) 수정에 착수하지는 말라. 코드 정리 작업도 개발 스케줄에 올려놓아라

 

간추림

좋은 프로그래머는…

• 깨끗한 구조와 논리적인 레이아웃을 갖는 유지보수가 쉬운 소프트웨어를 작성한다
• 나쁜 코드를 알아차리고, 그런 코드를 다룰 각오가 되어 있다
• 코드의 변경을 시작하기 전에 코드와 원작성자의 머리 속 모델에 대해서 가능한 한 많은 것을 알려고 한다
• 자가기 작업하고 있는 코드의 품질을 돌본다; 코드를 서투르게 땜질하기를 거부한다

나쁜 프로그래머는…

• 유지보수 프로그래머가 필요로 하는 것을 생각하지도 않고 복잡한 코드를 생성한다
• 예전 코드를 관리하지 않으려 하고, 문제를 고치기보다 무시하는 것을 더 좋아한다
• 좋은 솔루션을 생각하는 것보다 손쉬운 땜질을 더 좋아한다
• 재빠르고 지저분한 해킹으로 코드의 주변을 어지럽힌다; 할 수 있는 모든 꼼수를 다 사용한다
• 엉뚱한 곳에 주의를 집중하고, 실제로 고칠 필요가 없는 부분을 땜질한다