카테고리가 잘 구분되어있는 만큼, 항목별로 간단한 소감을 남겨본다. 목차만 나열했는데도, 다시 생각나는 챕터들이 있다. 여기 나열된 항목들을 하나하나 따져가며 설계와 개발을 해보는 건 어떨까?

1장. 실용주의 철학

고양이가 내 소스코드를 삼켰어요.

자신의 코드에 대해 책임감을 가지라는 이야기. 그리고 잘못을 인정할 줄 아는 자세가 필요하다. 스스로를 되돌아 봤을때, 적어도 우리 고양이가 코드를 건드렸다고 했던 적은 없었던 것 같다. “어? 언제 이런걸 해놨었지?” 라고 말한 적은 많았던 것 같다. 그게 그건가(…) 책임감에 대해서는 크게 문제될 부분은 없을 것 같다.

소프트웨어 엔트로피

깨진창문 이론을 여기서 보게 되는구나. 관리하지 않으면 엉망진창이 된다는 건 알고있었다. 신기했던 것은, 소프트웨어가 생명체도 아니고 실체가 보이지 않는 관념적임에도 불구하고, 살아있다고 표현하면서 꾸준히 관리하지 않으면 안된다는 것이었다. 신기했지만 이미 체감하고 있었고, 비단 소프트웨어 뿐만 아니라 모든 사물에도 적용할 수 있다는 생각이 들었다. 예시에 나온 정원사는 물론, 건물관리인부터 시작해서 현실세계의 각종 인프라들도 ‘관리인’이 필요하다. 따라서, “만들어놓으면 알아서 잘 돌아가야 되는거 아니야?” 라는건 어불성설이다. 그 어불성설을 주장하는 답답한 사람들이 결정권자일 경우의 스트레스는 생각하지 말자. 여기서는 소프트웨어도 꾸준히 변화가 필요하다는 점을 시사했다. 소프트웨어는 분명히 잘 돌아갈 것이지만, 시간이 흐름에 따라 요구조건들이 미세하게 달라질 것을 민감하게 파악하지 못했기 때문에 ‘가만히 냅둬도 돌아가는’ 소프트웨어 라는 잘못된 생각을 갖게 되는 것 같다.

돌멩이 수프와 삶은 개구리

변화에 민감해야 한다. 또한, 모두에게 흥미를 끌 수 있는 돌멩이를 던질 줄 알아야 한다. 이건 개발만큼 중요한 스킬이다.

적당히 괜찮은 소프트웨어

완벽한 소프트웨어를 만들기 위해 시간을 ‘너무’ 공들이지 말자. 어느정도 돌아간다면, 거기까지 하고 멈출 줄 알아야 한다.

지식 포트폴리오

투자하자.

  • 매년 새로운 언어를 최소 하나는 배워라.
  • 기술 서적을 분기마다 한권 씩 읽어라.
  • 비 기술 서적도 읽어라
  • 수업을 들어라
  • 지역 사용자 모임에 참여하라
  • 다른환경에서 실험해보라.
  • 트렌드를 놓치지 마라.
  • 인터넷을 이용하라.

나열해보니 굉장히 많은 항목들이다. 매년 표를 만들어서, 얼마나 진행했는지 살펴보는 것은 어떨까? 이젠 나의 과거행적을 구글캘린더로부터 벗어나게 해줄 수도 있지 않을까? 또한, 비판적 사고를 가져야 한다. 이 부분은 작년부터 생각하던 것과 일치하는데, 어떤 발표자의 자신감이 그 사람의 실력을 그대로 대변하지 않는다는 것과 궤를 같이 한다. 발표자의 말을 들어보면, 모든게 그 사람의 해법으로 다 풀릴 것이라 하는데, 그럴리는 없고요. 여기서는 dogma라는 단어를 써서 그 사람의 dogma에 갇히지 말라 한다. 맞는 말이라고 생각한다. 비판할 줄 알려면, 삶은 개구리처럼 되어서는 안되겠다.

소통하라!

한 때는 그저 혼자 일하는 것이 제일 좋은 것이라 생각했지만, 지식노동자에게는 소통이 갈수록 중요하다는 것을 점차 느끼고 있다. 차라리 오버 커뮤니케이션이 낫다는데, 이제는 동의한다.

2장. 실용주의 접근법

중복의 해악

Dont Repeat Yourself! 중복은 곧 기술부채와 연결된다.Y2K가 그 예. 재사용하기 쉽게 만들자. 그리고 너무 많은 코멘트는 나쁜코드라는 증거다. 간결함을 유지하자.

직교성

새로운 표현인데, 서로 영향받지 않는 성질을 이야기 한다. 벡터로 설명을 한다. 이상적인 컴포넌트들이라면 충분히 만족시켜야 할 조건임.

생산성과 리스크감소, 유지보수를 위한 설계 등 많은 부분을 고려해야 한다. 여기엔 DRY도 반드시 포함되어야 하며, 문서화마저도 이 부분을 만족해야 한다.

가역성

유연한 솔루션을 만들어야 한다. 완벽한 한가지 답은 없기 때문이다. 소프트웨어는 계속 변경될 것이고, 요구사항이 그 원인이다.

예광탄

프로토타입은 나중에 버릴 수 있는 코드인 반면, 예광탄은 주요 기능을 포함한 완결된 코드이다. 최종 시스템의 골격이 된다. 상황에 따라 다르게 언급하지만, 정찰과 정보수집이라는 것에는 공통점이 있다.

그냥 버리고 버리지 않고의 차이일 뿐인 것 같다. 결과론적인 단어 아닌가? 작업전에 “우리는 예광탄을 할꺼야” 라고 하고 시작하진 않는다. “일단 대충 구현해보자” 하고 시작해서, 어느정도의 시점에서 결정을 내린다. “이걸 그대로 가져갈까? 아니면 적절한 프레임워크로 새로 만들까?” 여기서 예광탄과 프로토타입이 결정되는 것이므로, 처음부터 결정하고 진행하는 점이 아닌 것을 잊지 말자.

프로토타입과 포스트잇

프로토타이핑은 코드로만 하지 않아도 된다. 포스트잇으로도 충분히 가능하다.

도메인 언어

“언어의한계가 곧 자기 세계의 한계이다.”

목적을 위한 소형 언어를 만들어 사용해도 유용하다. 목적에 따라 간결한 언어를 사용하면, 적절한 이득을 취할 수 있을 것이다.

추정

추정을 통해 놀람을 피하라.

필요한 만큼만 추정하자.

무엇을 묻는지 이해하고, 시스템 모델을 만들어본다. 모델을 컴포넌트로 나누고, 각각에 매개변수를 삽입하여 답을 계산해보자. 그리고 이 추정치를 기록한다. 끝!

이전의 경험이 없다면, 개발일정은 추정이 아닌 추측일 뿐이다. 이 경우에는 작업과 일정을 반복하여 조정해야 한다.

3장. 기본적인 도구

일반 텍스트의 힘

지식을 기록하라. 단점(용량 등)이 있지만, 장점이 충분하다.

조개놀이

유닉스 쉘 명령어들을 조합해보자. 보다 강력한 일들을 손쉽게 할 수 있다.

파워에디팅

하나의 에디터를 잘 사용할 수 있도록 노력하자. 많은 기능들을 사용해보자! GUI뿐만 아니라, 스크립트 등 기본적인 유틸을 다룰수 있어야 한다. 다른 에디터를 써보자! GUI를 잘 안쓴다면 이번 기회에 GUI도 써보자.

소스코드 관리

말이 필요 없습니다. 쓰세요.

디버깅

비난 대신 문제를 해결하라. 일단, 문제가 발생하면 당황하지 말자. 데이터를 가시화 하고, 차근차근 추적해간다. 원인을 발견했다면, 가정하지 말고 증명하자.

텍스트처리

텍스트 처리 언어를 하나 익히라는데, 파이썬이면 충분한가?

코드생성기

아직까지도 코드생성기에 대한 충분한 니즈를 느껴본 적이 없다. 심지어 코드생성기를 만들었었음에도 불구하고! 정말 대량의 방대한 코드가 필요하다면, 그때서야 해볼 생각을 가질 것 같다.

4장. 실용주의 편집증

계약에 의한 설계

DBC(Design by Contract). 선행/후행조건, 클래스 불변식을 정의하면 DBC가 명확해진다라. 요구사항이 명확하다면 문제가 없겠지만, 요즘처럼 급격하게 변하는 세상이라면 말이 다르지. API처럼, 내부사정 상관없이 일관적인 입출력만 제공하는 것을 보장한다는 점에서는 일맥상통하다. 하지만, 최근에 계속 쓰이는 개념은 아닌 것 같다.

죽은 프로그램은 거짓말을 하지 않는다.

문제가 생기면 일단 멈추게 하라. 그리고 로그를 확인해라. 일단 의심의 대상은 나다 ㅋㅋ 왜냐면, 내가 어딘가 빠뜨렸기 때문이다. 코드를 빠뜨렸겠지 아마…

단정적 프로그래밍

assert를 사용하라.

맞는 말이긴 한데, 남발하면 곤란하다. 사용하기 적절한 부분에서 사용해야 한다. 과한 연산이 필요한 곳에다 넣어놓으면 퍼포먼스가 문제될 것이 뻔하기 때문.

언제 예외를 사용할까

예외는 예외적인 부분에서만 사용하자. 예외적인 부분이라는게 대체 뭘까. 기준이 명확하지 않으면, 코딩할때마다 고민하게 될 것이 뻔한데, 설계나 개발 시 그 부분을 정의하고 시작하는게 좋겠다.

  • 일반적인 흐름을 어느정도까지 커버할 것인가?
  • 그 외에는 모두 예외처리로 넘겨서 로직을 중단한다.

리소스 사용의 균형

리소스 할당화 해제 커플링. 이건 이제 RAII개념으로 대부분 자동관리하는게 보편화 되었다.

5장. 구부러지거나 부러지거나

결합도 줄이기와 디미터법칙

디미터(demeter)가 대지의 여신 데메테르라는 것에 신기했다.

결합도 줄이기는 소프트웨어 공학에서 기본적인 개념으로 자리잡았다. 하지만, 극단적인 결합도 줄이기는 오히려 수행성능에 발목을 잡는 경우가 있는데, 이런 경우에는 적당한 선에서 타협하는 것이 바람직하다. 원칙을 지키자고 목적을 포기할 순 없기 때문. 우리는 “쓸 수 있는 프로그램”을 만드는 것이지, “규칙에 철저한 프로그램”을 만들자는 것이 아니다. 뭐, 둘다 만족하면 매우 바람직하겠지만.

메타 프로그래밍

“아무리 뛰어난 천재라도 세부사항에 집착하면 그 재능이 발휘되지 않는 법이다.” - Levy의 8번째 법칙

통합하지 말고 설정하라! 파라미터로 넘길 수 있는 것들은 미리 모조리 빼놓자. 신경쓰지 않아야 할 부분을 제거해 놓아야 집중하기 좋다. 이건 생각도 못했다. 당연히 로컬에 모든 설정을 하드코드로 박아놓은 다음에, 일련의 과정에서 Parameterizing하는게 좋을 것이라 생각해왔는데, 여기서는 오히려 처음부터 Parameterizing을 염두에 두고 작업하라는 것이잖아? 이 말은 애초에 설계가 어느정도 윤곽이 잡혀있다는 것을 전제로 하는 것 같다.

시간적 결합

작업 흐름을 분석해서, 동시성을 개선하라.

음, 좋은 말이야. 분석 뿐만 아니라, 사용을 통해서 개선을 하는 것도 좋은 방법이다. 언제나 동시성을 고려해서 설계하라!

단지 뷰일 뿐이야

Subscription과 MVC모델에 대한 이야기.

각자의 역할을 정해진대로 수행하는 것이 왜 중요할까? 이걸 통해서, 유지보수에 큰 이점을 얻을 수 있기 때문이다. 한 곳을 건드렸는데 다른곳에서 문제가 생긴다면? 코드를 건드리는게 무서워질꺼야. 근데 이 이야기, 초반에 직교성 이야기 하면서 나왔던 개념인데?

칠판

형사들의 칠판을 프로그래밍에 비유했다. 처음엔 전역변수를 상상하게 했지만, 설명을 보다보니 데이터센터를 이야기 하는 것으로 보인다. DB일 수도 있고, 정보를 담고있는 하나의 클래스일 수도 있다. 중요한 것은, 이렇게 정보를 모아놓고 체계적으로 분리하는 것을 까먹으면 안된다는 이야기. 이런 시스템이 좀 더 효율적인 관리를 가능하게 해줄 것이다.

6장. 코딩하는 동안 해야 할 일들

우연에 맡기는 프로그래밍

테스트도 없고, 제대로 파악하지 못한 코드라면 그건 우연적인 프로그래밍에 해당한다. 잘 이해하고, 의도적으로 프로그래밍 하는 습관을 기르자.

  • 내가 무엇을 하고 있는지
  • 잘 모르는 무언가를 넣고있지는 않는지(뜨끔)
  • 계획은 있는지
  • 신뢰할 수 있는 코드인지
  • 문서를 남기면서 작업하고 있는지 (히스토리)
  • 우선순위를 정했는지
  • 과거의 유산(?)들을 청산하고 있는지 등등

생각해보면, 테스트코드 없던 그 시절은 내가 뭘하고 있는지만 알고 있을 뿐, 우연에 맡겼다는 생각밖에 들지 않는다. 여기에 해당하는 내용들이 하나도 없었어!

알고리즘의 속도

알고리즘의 Big-O를 알아보자. 처음엔 차수만 대충 알아보고, 그 추정을 테스트해보자. 프로파일러를 돌려보고, 그래프를 그려보자. 그래프가 맘에 들지 않는다 해도, 성급한 최적화는 삼가는게 좋다. 실제 상황에서는 어떤 일이 벌어질 지 모르기 때문에, 좀 더 조사 후에 해도 늦지 않다.

리팩터링

코드는 정적인 존재가 아니다! 오히려 Gardening에 가깝다. 리팩터링이 필요한 때

  • 중복
  • 직교성이 문제될 때
  • 유효기간이 끝난 지식
  • 성능

리펙터링은 Pain Management이다. 되도록이면 일찍 하고, 자주 하도록 하자…는데 이거 굉장히 슬픈말같다. 마틴파울러님의 서적을 좀 봅시다.

테스트하기 쉬운 코드

항상 단위테스트를 염두에 두고 코딩합시다. (애초에 TDD를 하면 된다. 히죽히죽)

사악한 마법사

자신이 이해하지 못하는, 마법사가 만들어준 코드는 사용하지 말라.

이거 좀 말이 안되는게, 그러면 프레임워크는 내용을 모두 파악 후에 사용하라는건가?.. 하긴 파악하는게 작성하는것보단 덜 걸리니까 맞는말 같기도 하지만, 언제 그 프레임워크 다 공부하고 앉아있어… 라고 현실적으로 투덜거려 봅니다. 네, 맞아요. 모르면 쓰지 말아야죠… 놀고싶어서 그래요 놀고싶어서…

7장. 프로젝트 전에

요구사항의 구렁텅이

“완성이라는 것은 더 이상 더할 것이 없을 때가 아니라, 더 이상 빼낼 것이 없을 때 얻게 되는 것이다.” - 바람과 모래와 별들, 생텍쥐페리

논란의 여지가 있는 챕터인 것 같다. “요구사항을 채굴하라”, “요구사항 문서화”에는 동의하지만, 유즈케이스 다이어그램?.. 요새도 이런걸 하나? 지나치게 자세한 명세를 구분하는 것도 기준이 있어야 하는데, 자세함과 지나침의 차이가 미묘하다. Y2K를 예로 들었지만, 이건 요구사항에는 포함되지 않는다고 본다. 프로젝트 용어사전은 참 좋은 이야기이다. 같은단어를 다른 의미로 받아들이는 여러 집단을 처음 겪다보니, 이런 필요성을 느끼게 되었다.

불가능한 퍼즐 풀기

새로운 관점으로 바라보면, 어려운 문제들을 풀 수 있다. 다만, 그 큰 틀을 벗어나서는 안되며, 시간을 너무 많이 쏟아도 안된다. 우리에겐 해야할 일이 아직 많으니까(…)

어떤 문제를 풀기 전에, 제약사항을 고려하자. 그 안에서라면 마음껏 자유로워져도 좋을 것이다.

준비가 되어야만

준비가 되었을 때 시작하자. 아무 이유 없이 시작하는 건, 늑장부림과 다를 바 없는 결과를 가져올 수 있다(정말?). 일을 시작하기 전에 준비하는 습관을 들이자.

직감을 믿고, 꺼림칙할 때는 미루라는데, 이게 무슨소리야? 물론 미루다 보면 영감이 떠오를 수도 있겠지. 하지만 그럴 여유가 있나요?? 막상 미루는 경우는, 한참 헤딩하다 답이 안나와서, 멘탈 부서진 후에 회복하려고 멍때리는 때 뿐이었던 것 같다. 그 시간동안 영감을 얻은 적도 있긴 했으니, 책의 말은 일부 맞는 것 같다는 생각이 들기도 하는데…

명세의 함정

명세에 너무 의존하지 말자. 때론 그림이 글보다 짧고 간결하게 이해를 도울 수 있다. 아직 이렇게 자세한 명세를 써본 적이 없습니다만 ㅎㅎ

동그라미와 화살표

방법론에 얽매이지 말자. 제 값을 하는지 알아보자. 비싼 도구가 더 좋은 설계를 낳지는 않는다. 책에서 언급한 이야기, “클래스 다이어그램이 바로 애플리케이션이다. 나머지는 기계적인 코딩일 뿐이다.” 아 보기만 해도 퇴사하고 싶어지는 말이다. 말하신분은 최소 글로만 코딩 배우셨을 듯

8장. 실용주의 프로젝트

실용주의 팀

실천해보자!

  • 깨진창문 없애기
  • 변화를 감지하기 : 무엇이 변경되고 있는지 추적 또는 감시하자.
  • 소통!
  • 반복하지 말것(DRY)
  • 직교성 : 프로그램 뿐만 아니라, 팀을 기능적으로 분류할 필요도 있다.
  • 자동화 : 나도 모르게 내가 제일 신경쓰고 있는 부분
  • 덧칠을 멈출 시점

유비쿼터스 자동화

실용주의 프로그래머를 위한 프로젝트 자동화 라는 책을 추천하고 있다. 말 그대로다. 빌드, 테스트, 배포, 관리까지 자동화 하라는 이야기이다. 지금은 빌드, 테스트까지 어느정도 경험이 쌓였는데, 배포와 관리까지는 덜하다. 고민을 더 해보자. 자기 일을 살펴보고, 반복되는 것이 있다면 자동화 할 수 있게 하자. 그런 의미에서, 대중교통을 이용하는 출퇴근은 자동화 아닌가? 자가차량으로 출퇴근 하는거는 본인이 직접 하는 것이고…(아무말 대잔치)

가차없는 테스트

  • 일찍 테스트하고, 자주 테스트하고, 자동으로 테스트하라.
  • 모든 테스트가 통과하기 전엔 코딩이 다 된게 아니다.

오오 다 주옥같은 말들이다. 무엇을 테스트 할 지도 구분해야 한다.

  • 단위 테스트
  • 통합 테스트
  • 유효성 평가와 검증 : 요구사항을 충족하는가?
  • 자원고갈, 에러, 복구
    • 메모리
    • 디스크공간
    • CPU 대역폭
    • 벽시계 시간 (이건 뭐지?)
    • 디스크 대역폭
    • 네트워크 대역폭
    • 칼라 팔레트(까지는 신경 안써도 될 것 같아요… 아니 못쓸 것 같아…)
    • 비디오 해상도(너도 마찬가지)
  • 성능 테스트
  • 사용편의성 테스트

버그는 한번만 잡아라. 즉, 버그를 잡고 테스트 케이스를 추가하라는 이야기. “이건 절대 다시 일어나지 않을 버그야!” 라고 선언하는 것임.

결국은 모두 글쓰기

문서가 애초부터 전체의 일부가 되게 하고, 나중에 집어넣으려고 하지 말라. 주석은 최대한 간단명료하게 작성하는 것을 원칙으로 삼고 있었는데, 여기서는 JavaDoc 같은 걸 권장한다. 잘 모르겠다 아직까지는. 가끔은 필요할 것 같기도 하다. 함수 자체를 Readable 하게 하는게 최선이긴 해도, 가끔은 설명이 더 필요할 수도 있으니까. 텍스트를 다루기 위해서는 마크업언어도 사용할 필요가 있다.

위대한 유산

사용자의 기대를 부드럽게 넘어서라.

  • 툴팁
  • 단축키
  • 빠른참조
  • 색깔(테마)
  • 로그분석
  • 자동설치 등등

오만과 편견

자신의 작품에 서명하라.