[실용주의 프로그래머] 동그라미와 화살표

[실용주의 프로그래머] 동그라미와 화살표

-

개발 실천방법과 개발 능력의 맥락 안에 그것을 넣어보지도 않고 맹목적으로 받아들이는 것은 단지 실망을 맛보기 위한 비법이다.

형식적 방법의 노예가 되지 마라.

-

대부분의 형식적 방법은 다이어그램과 거기에 추가된 설명의 조합을 이용해서 요구사항을 포착한다.

이런 그림들이 요구사항에 대한 설계자의 이해를 표현한다.

하지만 대개의 최종 사용자는 이런 다이어그램들을 전혀 이해하지 못하므로, 설계자가 해석해 주어야 한다.

따라서 실제 시스템의 사용자들이 정말 형식적 확인을 통해 요구사항을 점검하는 일은 없는 셈이다.

-

형식적 방법들은 전문화를 권장하는 것처럼 보인다. 한 집단은 데이터 모델 작업을 하고, 다른 집단은 아키텍처를 보는 동안, 요구사항 수집자들은 유스 케이스를 모은다. 우리는 이런 방식이 결국 의사소통의 부족과 노력의 낭비로 이어지는 것을 보았다. 그리고 설계자들과 코딩하는 사람들 사이에서 “우리 대 저들” 식의 사고방식이 생기는 경향도 있다. 우리는 작업 중인 시스템을 전체적으로 이해하는 것을 선호한다.

-

우리는 런타임에도 앱의 성격을 변화시키는 일이 가능하도록 메타데이터를 이용해서 적응가능성이 높고 동적인 시스템을 작성하기 좋아한다. 현재 대부분의 형식적 방법은 정적 객체나 데이터 모델과 일종의 이벤트 또는 활동 차트를 그리는 메커니즘을 조합해서 사용한다.

-

새로운 도구와 방법론을 채택하는 데 들어가는 비용을 절대 과소평가하지 말라.

새로운 기법을 사용하는 최초의 프로젝트를 학습 경험으로 여길 마음의 준비를 하라.

-

그럼에도 형식적 방법을 사용해야 한다.

만약 주의 깊게 분석한 후에 어떤 형식적 방법을 사용할 필요가 있다고 생각한다면, 기꺼이 그렇게 하라.

하지만 누가 주인인지 분명히 기억하라.

절대로 방법론의 노예가 되지 말라.

-

실용주의 프로그래머들은 방법론을 비판적인 시각으로 바라본 다음, 각각의 방법론에서 가장 좋은 것만 뽑아 매달 점점 좋아지는 자신의 작업 실천방법의 집합 속에 녹여 넣는다. 이것이 핵심이다.

절대로 어떤 방법론의 완고한 경계를 여러분 세계의 한계로 받아들이면 안 된다.

-

어떤 방법의 거짓된 권위에도 넘어가지 말라.

-

비싼 도구가 더 좋은 설계를 낳지는 않는다.

[실용주의 프로그래머] 동그라미와 화살표, 다이어그램, 메타데이터, 방법론의 노예, 새로운 도구, 새로운 방법론, 설계자 해석, 형식적 방법론