드디어 또 하나의 작품이 출간되었습니다.

아키텍트가 가 알아야 할 97가지에 이어 프로그래머가 알아야 할 97가지가 드디어 출간되었습니다.

여러 지인들이 의기투합해서 만든 작품으로, 오랜 시간이 걸려 드디어 빛을 보게 되었습니다. 정말 많은 분들이 고생을 해주셨구요.  10명이 넘게 번역 작업을 하느라 정말 고생이 많았습니다. :

특히 일정한 퀄리티가 나오도록 어려번 검수를 해주시느라 고생해 주신, 김수현 , 최현미 두 역자님에게 정말 감사드립니다.

저보다 더 많은 노력을 해주셔서, 최종 검수때  많이 편했습니다. 정말 두 분에게 고개 숙여 감사드립니다. 어떻게 보면 두 분의 이름이 1,2 역자로 먼저 나와야 하는데, 겸손하게 저에게 1역자를 주셔셔, 책임감이 크게 느껴집니다.

또한 베타리더 분들에게도 정말 감사드립니다.  오역을 많이 다듬어 주시고, 좀더 쉬운 용어로 바꾸는 작업을 해주셔서 이 분들이 아니였으면 정말 더 오래 걸렸을거 같습니다.

이전 소프트웨어 아키텍트가 알아야 할 97가지 보다 좀더 개발자에게 와 닿고 가슴을 적실 선배들의 조언들이 듬뿍 담겨 있습니다.  업계 최고의 아키텍트, 프로그래머, Agile 전문가들이 경험에 기반한 조언들입니다.

또한 특별 부록으로, 원서에는 없는 한국의 유명한 프로그래머들의 추가 에피소드가 실려 있습니다.

계속 읽기

여러분이 프로그래머라면, 여러분의 관리자나 동료 또는 사용자에게 지금 하고 있는 업무의 예측 결과를 알려 주어야 합니다. 그렇게 해야 그들이 목적을 달성하는 데 필요한 시간, 비용, 기술 등을 정확하게 이해할 것입니다.
정확히 예측하려면 예측에 대한 기술을 배우는 것이 가장 중요합니다. 첫째로, 예측이란 무엇이고, 그것이 어떻게 사용되는지 배워야 합니다. 이상하게 들릴 수 있겠지만,  많은 프로그래머와 프로젝트 관리자들이 예측이 무엇인지 정확히 알고 있지 못합니다.

다음에 나오는 프로그래머와 프로젝트 관리자의 대화는 전혀 이상한 것이 아닙니다.

  • 프로젝트 관리자: 이 기능을 개발하는 데 얼마나 걸릴까요?
  • 프로그래머: 한 달이면 됩니다.
  • 프로젝트 관리자: 너무 길어요. 일주일 안에 완료해야 합니다.
  • 프로그래머: 적어도 3주는 필요할 것 같은데요.
  • 프로젝트 관리자: 2주까지는 시간을 드릴 수 있을 것 같습니다.
  • 프로그래머: 네, 좋습니다. 2주로 하죠.

프로그래머는 결국 프로젝트 관리자가 만족하는 선에 맞춰 예측하고 있습니다. 하지만 이것은 프로그래머가 예측치를 제공한 것이기 때문에 프로젝트 관리자는 프로그래머
에게 책임을 전가할 것입니다. 이 대화에서 무엇이 잘못되었는지 파악하려면 예측, 목표, 커밋먼트라는 세 단어를 정의해야 합니다.

계속 읽기

저는 원하는 것을 말하지 않아도 될만큼 만족하고 있는 고객을 만나본 적이 없습니다.   대부분 그들은 엄청나게 세세한 부분까지 이야기 합니다.  문제는 고객들이 항상 모든 진실을 이야기하지 않는다는 것입니다. 그들은 보통 거짓말을 하지 않습니다만,  고객의 관점에서 말할 뿐 개발자의 관점으로는 이야기 하지 않습니다.  그들은 그들만의 용어를 사용합니다. 그들은 중요한 세부사항들은 생략합니다.  그들은 마치 여러분도 그들처럼 그 회사에서 20년동안 근무했다고 생각하는 것 같습니다.

거기에다가 많은 고객들이 처음에는 정말로 원하는 것이 무엇인지 모른다는 사실까지 더해집니다!   고객들중 일부는 ” 큰 그림”을 파악하고 있을 수도 있겠지만, 그들이 보고 있는 “큰 그림”에 대한 세부사항을 효과적으로 전달할 수 있는 경우는 흔치 않습니다. 다른 사람들은 전체그림에 대해서는 얕은 지식을 가졌을 수도 있지만, 그들이 원하지 않는 것이 무엇인지를 알고 있습니다.

그러므로, 무엇을 원하는지에 대한 전체의 진실을 여러분에게 말해주지 않는 누군가에게 어떻게 소프트웨어 프로젝트를 제공할 수 있겠습니까?  그것은 매우 간단합니다. 그들과 더 많이 접촉해야 합니다.

계속 읽기

특히 많은 사용자들을 위한 경우, API 설계는 어렵습니다. 만약 여러분이 수 백에서 수 천의 사용자들이 사용할  API 를 설계한다면, 미래에 이것이 얼마나 바뀔 것인지, 그리고 변경 사항이 클라이언트 코드를 손상시킬 수 있는지 여부를 고려해야 합니다. 그 이상으로, 여러분은 API 사용자가 여러분에게 어떻게 영향을 미칠지 생각해야 합니다.

만약에 여러분의 API 클래스 중 하나가 내부적으로 자신의 함수들 중에 하나를 사용한다면, 사용자가 여러분의 클래스의 서브클래스를 만들고 오버라이드override 할 수 있으며, 그리고 그것은 재앙이 될 수 있다는 것을 꼭 명심해야 합니다. 몇몇 사용자들이 그 메소드를 서로 다른 의미로 받아들였기 때문에 여러분은 그것을 바꿀 수 없을지도 모릅니다. 메소드 내부 구현에 대한 여러분의 향후 선택은 사용자들이 이를 얼마나 받아들여 줄 수 있느냐에 달려 있습니다.

API 개발자들은 다양한 방법으로 이러한 문제들을 해결하지만, 가장 쉬운 방법은 API 를 봉쇄하는 것입니다. 만약 여러분이 자바 환경에서 작업한다면, 대부분의 클래스와 메소드를 final 로 선언하는 유혹에 빠질 수도 있습니다. C# 환경에서는, 여러분의 클래스와 메소드들을 sealed 로 선언해 버릴 수도 있습니다. 여러분이 어떤 개발 언어를 사용하든 간에, 행위를 오버라이드하거나 이후에 여러분의 선택을 제약하도록 코딩하는 것을 막기 위해 싱글턴 패턴이나 정적 팩토리 메소드를 이용해 API를 제공하고자 할 것입니다. 이 모든 것들이 합리적으로 보입니다만, 진짜로 그렇습니까?

지난 십년 동안, 우리는 점차 단위 테스트가 실전에 매우 중요한 부분이라는 사실을 깨달았지만, 이런 교훈이 업계에 완벽하게 확산되지는 못했습니다. 그 증거는 우리 주위에 널려 있습니다. 타사의 API 를 사용하는 임의의 테스트 안된 클래스에 대한 단위 테스트를 하려고 하면, 여러분은 곤경에 빠질 것입니다. 여러분은 그 코드가 마치 접착체로 붙인 듯이 API 를 사용하고 있다는 것을 알게 될 것입니다. 그것이 API 클래스이고 그래서 여러분의 다른 코드와 API 가 상호작용 한다는 것을 알아챌 수 있도록 하는 방법도 없고, 그래서 테스트를 위한 반환값을 제공할 수 있는 방법도 없습니다.

계속 읽기