1

‘Refactoring’을 쓴 ‘마틴 파울러’가 파운드로 있는 ‘ThoughtWorks’에서 출판한 책 입니다. 한 마디로 ‘좋은 책’ 입니다.

2

말로만 드던 ‘CI(Continuous Integration,지속적인 통합)’를 회사에서 사용한 경험, 해보려고 노력했으나 알바에 의해서 완성된 ‘자동화’를 ‘코드’로 구현한 것의 이점, 국내에선 폭포수의 다른 말로 치환된 ‘애자일’이 아닌 진실된 ‘애자일’ 개발 방법론을 사용한 경험등을 읽어낼 수 있다.

3

다 외국 이야기란 것도 기억해두자. 그리고 CEO가 ‘마틴 파울러’라 가능한 이야기 일 수 있음도 기억해 두자. 무턱대고 따라할 일은 아니지만, 꼭 새겨들어야 할 이야기다.

---

‘의사소통’, 애자일의 또 다른 의미 ‘의사소통’

애자일 소프트웨어 운동이 가장 크게 기여한 바는 소프트웨어 개발이 근본적으로 사회적 행위라는 인식을 알린 것이다.

이런 상황이니 거의 모든 개발자가 ‘달리는 자동차의 바퀴를 교체’하는게 아닐까?

물론 개발 중인 시스템이 가상의 테스트 환경과 실제 업무 환경에서 다르게 작동한다면 이 접근법은 큰 결함을 갖게 될 것이다. 자동화된 테스트의 결과를 신뢰하기도 힘들 것이고, 결과적으로 개발 및 테스트의 효율 향상에 미치는 영향도 미미할 것이다.

메서드에 대한 다른 관점

객체지향 언어에서 메서드의 범위를 제어하는 가장 명확한 방법은 클래스 메서드이다.

하나를 잘하고, 여러개를 배워야 하는 이유.

여러 언어의 특징들에 대한 이해는 컴퓨터 언어 세상에 새로 유입되는 언어들을 이해하기 위한 강력한 기반이 된다.

그래서 함수형 언어가 쉽지 않다.

[…] 순수한 함수는 처음 호출과 다음 호출 사이에 유지되는 메모리 혹은 상태를 갖지 않는다.

‘객체’에 대한 좋은 ‘정의’

[…] 자바는 객체지향 프로그래밍 언어로 분류되는데 그 이유는 이 언어의 주요 구조화 단위가 객체이기 때문이다. 개념적으로, 객체란 상태 변수와 메서드의 모음이다. 객체는 특정 클래스에 속하는데, 클래스는 자신에게 속한 객체가 가져아 할 상태와 메서드를 명시하고 있다. 같은 클래스에 속한 객체들은 서로 관련되어 있기는 하지만 서로 독립적인 단위이다. 어떠한 언어가 객체지향언어로서 갖춰야 할 필요충분조건이 무엇인지에 대해서는 몇 가지 경쟁 중인 정의들이 있지만 거의 모든 정의가 상속과 캡슐화를 포함하고 있다.

‘튜링 컴플리트’ 덕분에 우리가 ‘고수준’언어를 사용할 수 있다. 언제나 고마운 튜링형!

지금까지 여러 언어들을 살펴보았는데, 이를 통해 언어의 구조화 방식, 타입 시스템, 실행 방식, 구현 방식 등에 따른 분류 기준을 찾아낼 수 있었다. 이 기준은 언어의 범용성과 관련이 있다. 조건문과 무한히 수행될 수 있는 반복문을 지원하는 모든 언어는 튜링 컴플리트 언어이다. 이 범주에 속하는 모든 언어는 유한한 입력을 받아서 유한한 시간 내에 유한한 출력을 내며 종료하는 어떠한 프로그램도 표현할 수 있다. […] 이 튜링 컴플리트에 대한 기준도 살펴봐야 하지 않을까? 자신이 선택한 언어를 옹호하고자 하는 사람들의 열정에도 불구하고, 리스프이건 루비이건 자바이건 C# 이건 C이건 혹은 그 오래된 어셈블리 언어이건 간에 해당 언어로 수행할 수 있는 계산의 범위는 모두 동일한다. 그렇다. 모두 같다.

강타입 언어가 좋다가도 좋지 않다고 느낀다면 파이썬을 배워보자.

또 다른 중요한 용어는 강한 타입인데, 이 용어는 오용되는 경우가 많다. 실행 중 타입 오류가 발생할 가능성이 있는 소스코드는 컴파일이 되지 않도록 한다는 것이 강한 타입 언어에 대한 일반적인 정의이다.

인터페이스는 소중하다. 그리고 비용도 엄청나다.

[…] 이런 독립성을 확보하는 방법으로 흔히 받아들여지는 것은 양식이 아닌 계약을 공유하는 서비스의 구축이다. 제공자는 계약을 공시하여 서비스, 주고 받는 메시지, 엔드포인트, 그리고 허용되는 통신 방식을 기술한다.

언제나 ‘도메인’에 대한 이해가 중요하다.

지난 십 년간 소프트웨어 개발 프로젝트에 투입되었던 많은 사람들은 대부분의 애플리케이션에서 소프트웨어가 다루어야 할 가장 복잡한 부분은 소프트웨어가 다루는 문제 도메인이라는 사실을 이해하게 되었다. 이런 이유에 근거해, 도메인 주도 설계라고 알려진 방법론은 다음 두 가지 가정에서 출발한다. * 대부분의 소프트웨어 프로젝트는 주로 도메인과 도메인 로직에 초점을 맞추어야 한다. * 복잡한 도메인 설계는 반드시 모델에 존재해야 한다.

그래서 ‘GoF’는 굉장한 일을 한거다.

어떤 영리한 사람이 ‘짜잔’ 하면서 디자인패턴을 발명하는 것이 아니다. 디자인 패턴은 기존의 코드로부터 발견되는 것이다.

이런게(C.I.) 있기는 한거냐?!

애자일 개발 프로젝트의 핵심 실천방법은 지속적인 통합을 활용하는 것이다. 지속적인 통합이란 소프트웨어가 버전 관리 시스템에 커밋되는 시점에 빌드와 다량의 자동화된 테스트 케이스 수트를 돌리는 프로세스를 말한다. […] 하지만 지속적인 통합 파이프라인도 다른 애자일 실천방법과 마찬가지로 개별 프로젝트의 요구에 맞춰 손보고 조정하는 게 보통이다.

난 요구사항이 가장 중요하다고 생각한다.

성능 테스팅은 출시된 제품이 충분한 성능을 갖췄음을 보장하는 데 필요한 활동을 모두 포괄해야 한다. 여기에는 요구사항, 제품 성능 측정자료, 의사소통, 프로세스라는 4가지 핵심요소가 있다.