심플소프트웨어
미래 예측의 정확성은 시스템이 복잡해질수록, 예측하고자 하는 시점이 멀어질수록 낮아진다.
목표를 ‘유연하게’ 혹은 ‘포괄적으로’처럼 추상적으로 잡지 말고 ‘쉽게 이해하고 수정할 수 있게’처럼 구체적으로 잡아야 한다.
예측한 모든 일은 확률일 뿐 모든 예측에는 틀릴 가능성이 내포되어 있기 때문이다.
엄격한 애플리케이션일수록 더 단순하게 작성할 수 있다.
-> 프로그래머를 위한 프레임워크나 언어를 만드는 중이라면 ‘덜 엄격한’ 인터페이스는 최대한 간소하게 만드는 게 좋다. 그러면 사용성을 위해 단순성을 희생하지 않아도 되므로 사용성과 단순성, 두 마리 토끼를 모두 잡을 수 있다.
‘둘은 너무 많다’
-> 원칙적으로는 개발자가 코드 일부를 수정한 후에 코드의 다른 부분까지 그와 비슷하거나 똑같은 방식으로 작동하도록 수정할 필요가 없어야 한다.
고전적으로는 ‘반복하지 마라’ 라는 것이다.
리팩토링
개선할 지점을 찾을 때 그리고 그 문제를 어떻게 처리할지 알아내는 데 도움이 된다. 시스템에서 중복되는 로직이 눈에 띄면 둘을 하나로 합쳐야 한다. 또 다른 위치를 발견하면 그 또한 새로 만든 포괄적 체계에 통합하라.
하지만, 통합하면 안되는 것을 통합하지 않는 것도 중요하다. 때로는 두 개의 구현체를 하나로 통합했다가 시스템이 전체적으로 더 복잡해지기도 한다. 또한, 잘못 통합하다간 단일 책임 원칙을 어기기도 한다.
분별있는 소프트웨어 설계
우리는 미래에 대해 생각했다. 전체 공정 내내, 특히 미래에 어떤 일이 일어나든 버틸 수 있는 강력한 강철 로프를 설치할 때 말이다.
하지만 미래를 예측할 생각은 없었다는 점에 주목하라. 그저 원칙을 따른 덕에 무슨 일이 일어나든 잘 버틸 수 있는 구조물을 손쉽게 만들 수 있었다.
결합도를 높게하는 대신 변화가 생길 것을 고려하여 조합해서 사용하는 방식을 썻다. 그리고 당장 필요하지 않더라도 미래에 모듈을 추가할 것을 고려하여 모든 부분에 규격화된 메서드를 제공했다.
하나로 결합하는 과정도 자잘하게 단계를 나누었다.
가장 중요한 점은 모든 구성 요소를 일관되게 규격화하고 각 부분을 작고 간단하게 유지함으로써 작업을 단순화했다는 점이다.
http://www.yes24.com/Product/Goods/80749963
100년 뒤에도 유용할 소프트웨어 설계 원칙 & 프로그래머의 바른 길!Google의 코드 건강(Code Health), 즉 코드의 가독성, 안정성, 단순성, 유지보수성은 어떻게 개선되어 왔을까? 오픈소스 버그질라(Bugwilla)는 어떻게 침체기를 벗어나 다운로드 수를 10배 이상 늘렸을까? 그 중심에는 이 책의 저자 맥스-카넷 알렉산더…
(왜 눈에 잘 안들어오지 글이 -_-; 너무 오래 안봤었나?)