참 다양한 이야기들을 들려준다. 이야기가 97개나 있으니 좋은 이야기도 있고 공감이 잘 안되는 이야기도 있다. 그런데 신기하게도 97 가지의 이야기를 찬찬히 듣다보면 그들이 하는 얘기중에 무언가 공통된 점을 발견하게 된다.
바로 개발자가 가져야하는 마음가짐이다.
지속적인 학습
완벽한 코드를 작성하겠다는 장인정신
모두를 위한 배려
훌륭한 프로그래머가 되겠다는 마음
집필에 참여한 많은 사람들이 이렇게 쓰자고 미리 정한 것도 아닐텐데 말이다. 결국 Expert로서 후배들에게 이야기해주고 싶은 내용을 꼽으라면 비슷한 내용이 나온다는 얘기다. 이것이 이 책에서 내가 생각하는 가장 중요한 포인트다.
“소프트웨어 회사에서의 다년간의 경험으로, 저는 적당한 프로그래머와 훌륭한 프로그래머 사이의 진짜 차이의 대한 결론을 내렸습니다. 바로 마음가짐입니다”
차이를 만드는 것은 마음가짐이다. 능력이 아니다.
초보 프로그래머라면 좋고 나쁘고를 판단하기 전에 먼저 이러한 마음가짐을 한번 가져보자. 한창 배우는 중인 견습 프로그래머라면 바쁜 일정과 여러가지 변명들로 마음 한구석에 쟁여놓았던 마음가짐을 다시 한번 꺼내보자. 전문가라면 이 마음가짐을 주변사람들에게 스물스물 전파해보자.
미약하나마 이 책을 통해 이러한 일들이 벌어진다면 참 좋겠다.
한줄 요약과 함께 마음에 드는 글은 추천(★)표시를 해두었으니 시간이 없으신 분들은 추천글만이라도 꼭 읽어보시길!
참고로 원문은 모두 공개 되어있다.
1. Act with Prudence by Seb Rose
- 기술적 부채를 가능한한 빨리 갚을것. 안그러면 이자가 엄청날 것임.
2. Apply Functional Programming Principles by Edward Garson
- 함수형 프로그래밍의 맥락을 깊이 이해하라.
3. Ask “What Would the User Do?” (You Are not the User) by Giles Colborne
- 사용자를 관찰해보자. 그들이 어떻게 생각하는지 알게 될 것이다.
4. Automate Your Coding Standard by Filip van Laenen
- 코드는 혼자만의 것이 아니다. 우리 모두의 코드이기 때문에 코딩표준이 필요하다. 자동화하지 않으면 녹아들기 힘듬.
5. Beauty Is in Simplicity by Jørn Ølmheim
- 단순한 코드가 아름답다. 간단한 코드가 우아하다.
6. ★ Before You Refactor by Rajith Attapattu
- 리팩토링은 좋은 것이지만 하기전에 한번 생각해보자.
- “코드의 스타일과 구조가 여러분의 개인적 선호도를 충족시키지 못한다는 것은 리팩토링의 정당한 사유가 될 수 없습니다”
7. Beware the Share by Udi Dahan
- 코드를 공용화할때 맥락을 고려해야 한다. 즉 의존성이 높아진다면 안하느니만 못하다.
- “제가 만든 공용 라이브러리들은 한 발의 신발끈을 다른 발에 묶어 놓은 것과 같이 서로에 대한 의존도가 높았습니다”
8. ★ The Boy Scout Rule by Uncle Bob
- 체크아웃할 때 보다 더 개선해서 체크인! Clean Code!
9. Check Your Code First before Looking to Blame Others by Allan Kelly
- 아니 이게 무슨소리오. 당신 코드는 완벽하고 컴파일러가 문제라니.
10. Choose Your Tools with Care by Giovanni Asproni
- 툴을 사용하자. 좋은거 많다. 선택은 주의해서.
11. ★ Code in the Language of the Domain by Dan North
- 암묵적 규칙을 남발하지 말고 도메인 용어. 즉 알아들을 수 있는 용어로 코딩하라.
12. Code Is Design by Ryan Brush
- 설계가 중요하다.
13. Code Layout Matters by Steve Freeman
- 코드 레이아웃은 생각보다 훨씬 중요하다.
- “우선 팀원들로 하여금 기본적인 자동 포맷터를 사용하지 않도록 해야합니다. 그리고 여러분 또한 도구의 도움을 받지 않고 스스로 레이아웃을 구성할 수 있어야 합니다”
14. ★ Code Reviews by Mattias Karlsson
- 코드리뷰는 반드시 해야한다. 지식공유를 위해. 어떻게? 상냥하게. 거부감 없이 편하고 재미있게. 비판적이기보다는 건설적으로.
15. Coding with Reason by Yechiel Kimchi
- 코딩할때 주의해야할 것들.
16. A Comment on Comments by Cal Evans
- 주석도 쓸모있을 때가 있다. 그치만 주석이 없을정도로 읽기쉽게 코딩하는게 낫다.
17. ★ Comment Only What the Code Cannot Say by Kevlin Henney
- 주석을 코드처럼 다뤄야 한다. 따라서 당연히 코드와 중복되면 안된다. 즉 코드가 말하지 않는 것을 주석으로 설명해야 한다.
18. ★ ★ Continuous Learning by Clint Shank
- 지속적인 배움은 스스로에게 달려있다. 강추.
19. Convenience Is not an -ility by Gregor Hohpe
- API를 구현할때의 편의성보다는 API를 사용할때의 편의성이 더 중요하다.
20. Deploy Early and Often by Steve Berczuk
- 릴리즈와 설치 프로세스도 미리미리 신경쓰자.
21. Distinguish Business Exceptions from Technical by Dan Bergh Johnsson
- 기술적인 예외와 비지니스 로직에 의한 예외를 따로 처리하자.
22. ★ Do Lots of Deliberate Practice by Jon Jagger
- 수련은 의도적인 반복이다. 수련의 목적은 능력 향상이다.
- “전문성을 개발하기 위한 핵심은 단순히 무엇인가를 반복하는 것이 아니라 여러분의 능력을 넘어서는 일에 도전하고, 그 일을 열심히 하고, 그 일을 계속하면서 성과를 계속 분석해 보고 실수를 고쳐 나가는 것”
23. Domain-Specific Languages by Michael Hunger
- DSL 이란게 있다.
24. ★ Don’t Be Afraid to Break Things by Mike Lewis
- 오믈렛을 만들때 달갈깨는 것을 두려워하지 마라. 리팩토링으로 인해 코드가 잠시 불안정해지는것을 두려워하지 마라.
- “숙련된 외과의사는 수술을 위해 절개가 필요하지만, 이것은 일시적이며 곧 봉합되어 회복될 것이라는 사실을 알고 있습니다. 여러분의 코드를 수술하는 것을 두려워하지 마십시오”
25. Don’t Be Cute with Your Test Data by Rod Begbie
- 장난삼아 넣어놓은 임시 데이터를 고객이 본다면?
26. Don’t Ignore that Error! by Pete Goodliffe
- 에러는 보일때 잡자. 안그러면 후회한다.
- “여러분이 에러를 무시했다면, 여러분은 장님이 되는 것입니다. 더 나쁜일이 일어나지 않을 것이라고 스스로를 속이는 것과 같은 것입니다”
27. Don’t Just Learn the Language, Understand its Culture by Anders Norås
- 새로운 언어의 사고방식을 배우자.
28. Don’t Nail Your Program into the Upright Position by Verity Stob
- 너무 많은 예외처리로 예외를 먹어버리지 말자.
29. Don’t Rely on “Magic Happens Here” by AlanGriffiths
- 프로젝트에는 다양한 역할이 필요하다. 역할 하나를 없애고 잘 돌아가길 기대하는건 기적을 바라는거다.
30. ★ Don’t Repeat Yourself by Steve Smith
- 프로세스도 중복을 피하자. DRY, OCP, SRP
31. Don’t Touch that Code! by Cal Evans
- 운영서버에 직접 코드를 고지치마라.
32. Encapsulate Behavior, not Just State by Einar Landre
- 객체지향 모델링의 장점을 활용해서 캡슐화를 제대로 하자.
33. Floating-point Numbers Aren’t Real by Chuck Allison
- 부동소수점은 정확하지 않다. 조심해서 사용하자.
34. Fulfill Your Ambitions with Open Source by Richard Monson-Haefel
- 회사에서 채워지지 않는 개발욕망이 있다면 오픈소스로 채워보자.
- “일로써 소프트웨어를 개발하는 것이 아니라 열망하기 때문에 소프트웨어를 개발할 수 있다면 참 좋을 것 같습니다”
35. The Golden Rule of API Design by Michael Feathers
- API를 설계할때 그 API를 사용하는 코드를 테스트할 방법도 고려해서 설계하자
36. The Guru Myth by Ryan Brush
- 구루도 사람이다. 다 알꺼라는 생각은 버리자.
37. ★ Hard Work Does not Pay Off by Olve Maudal
- 끝없는 잔업으로 일만한다고 해서 절대 성과가 나오지 않는다. 왜냐하면 프로그래밍과 소프트웨어 개발 작업에는 지속적인 학습이 수반되어야 하기 때문이다.
- “전문 프로그래밍은 길 끝에 도달해야만 목표 지점을 볼 수 있는 달리기와는 다릅니다. 대개의 소프트웨어 프로젝트는 어두운 곳에서 대략 그려진 지도만을 가지고 정해진 길을 찾아가야 하는 장거리 오리엔티어링 마라톤과 더 비슷합니다”
38. How to Use a Bug Tracker by Matt Doar
- 버그 리포트는 최대한 상세하게 적자. 버그는 작업의 표준 단위가 아니다.
39. Improve Code by Removing It by Pete Goodliffe
- 필요없는 부가적인 코드는 제거하자.
40. Install Me by Marcus Baker
- 쉬운 설치, 간결한 사용법은 생각보다 중요하다.
41. Inter-Process Communication Affects Application Response Time by Randy Stafford
- 느리다 싶으면 IPC부터 점검해보자
42. Keep the Build Clean by Johannes Brodwall
- Warning도 보일때마다 잡아야한다.
43. Know How to Use Command-line Tools by Carroll Robinson
- IDE말고도 커맨드라인 명령어로 다 할 수 있다. 특히 자동화에서는 필수.
44. ★ Know Well More than Two Programming Languages by Russel Winder
- 다양한 언어의 패러다임을 익히자. 상호 교류는 전문 지식의 핵심.
45. Know Your IDE by Heinz Kabutz
- IDE의 기능을 최대한 활용하자
46. Know Your Limits by Greg Colvin
- 소프트웨어가 뛰어넘기 힘든 현실의 한계가 있다.
47. Know Your Next Commit by Dan Bergh Johnsson
- 업무를 작은 보폭으로 짧게짧게 나누어라. divide and conquer.
48. Large Interconnected Data Belongs to a Database by Diomidis Spinellis
- RDBMS 사용을 두려워하지 말자. 많이 발전했고 장점도 많으며 계속 발전중이다.
49. ★ Learn Foreign Languages by Klaus Marquardt
- 도메인 언어든 제2외국어든 사람과 대화할 때 사용하는 진짜 언어를 하나 더 익히자.
- “제가 알고있는 최고의 프로그래머들은 모국어뿐 아니라 다른 언에도 능통합니다. 언어를 유창하게 하면 또한 문제점을 추상화하는 명확한 사고를 이끌어 낼 수 있습니다. 그리고 이런 것이 프로그래밍입니다” - “다른 언어를 안다는 것은 다른 영혼을 소유하게 되는 것”
50. ★ Learn to Estimate by Giovanni Asproni
- 추정하는 능력이 필요하다. 잘하기 위해서는 역시나 좋은 방법을 배운 후 꾸준한 연습뿐.
51. Learn to Say “Hello, World” by Thomas Guest
- 함수 하나도 충분히 독립적으로 실행할 수 있다는 사실. 단위 테스트를 작성하는 개발자라면 당연히 알테지만.
52. Let Your Project Speak for Itself by Daniel Lindner
- 지속적인 통합을 적용한 다음 문제가 생겼을때 이메일 노티 대신 싸이렌이 울리도록 해보자. 절대 무시할 수 없을 것이다. 재밌기도 하고. Extreme Feedback Device (XFD) 라 한다.
53. The Linker Is not a Magical Program by Walter Bright
- 링크하는 과정도 알아야한다.
54. The Longevity of Interim Solutions by Klaus Marquardt
- 임시 해결책을 적용해야하는 상황이 있다. 임시 해결책은 글자그대로 임시일 뿐이다.
- “여러분이 변화시킬 수 없는 것을 그대로 용납하는 평안을 누리고, 변화시킬 수 있는 것을 바꾸는 용기를 얻고, 그 차이를 아는 지혜를 얻기를 바랍니다”
55. Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly by Scott Meyers
- 인터페이스 설계를 잘못사용할수 없도록 잘 설계하자. GUI 포함해서.
56. Make the Invisible More Visible by Jon Jagger
- 눈에 보이지 않는 것은 해결하기도 어렵다. 장애요소는 무엇이든 빨리드러나도록 하자.
- “프로젝트가 정상적인 개발 일정에 맞춰 진행되고 있었는데, 1주일후에 6개월이 지연되야 한다고 알려진다면, 프로젝트에는 문제가 있는 것입니다. 가장 큰 문제는 6개월의 지연이 아니라 6개월 지연을 감출 정도로 강력한 비가시성입니다”
57. Message Passing Leads to Better Scalability in Parallel Systems by Russel Winder
- 복잡한 병렬 문제를 해결하는 방법은 서로 독립적인 환경이 되도록 공유 메모리를 사용하지 않는 것이다. 대신 메시지 전달방식을 써보자. like Erlang.
58. ★ A Message to the Future by Linda Rising
- 지금 내가 작성하는 코드는 미래의 누군가에게 보내는 메세지이다.
- 읽기 쉬운 코드 = 완벽하고 아름다운 코드 = 잊혀지지 않는 멜로디 같은 코드 = 아름다운 세상을 만드는 코드
59. Missing Opportunities for Polymorphism by Kirk Pepperdine
- if-then-else 대신 다형성을 활용하자.
- “물론 if-then-else 구문을 사용하는 것이 더 실용적인 경우도 있겠지만 대부분 다형성을 적용한 코드가 더 적은 양으로도 가독성 높으며 견고한 코드를 만들 수 있습니다”
60. News of the Weird: Testers Are Your Friends by Burk Hufnagel
- 테스트를 해주는 테스터를 미워하지 말고 고마워해야한다.
61. One Binary by Steve Freeman
- 커스텀 바이너리 여러개 생성하지말고 딱 하나만 생성하자.
62. ★ Only the Code Tells the Truth by Peter Sommerlad
- 각종 문서, 주석 등은 모두 거짓일 수 있다. 가장 정확한 것은 바로 코드이다. 따라서 진실을 명확하게 말해주는 코드를 작성할 수 있도록 신경을 써야한다.
- “프로그램이 무엇을 하는지 알고자 한다면 소스코드를 살펴보는 것이 가장 확실한 방법입니다”
63. Own (and Refactor) the Build by Steve Berczuk
- 빌드는 개발과정의 필수 부분이다. 따라서 빌드 스크립트도 코드만큼 중요한 것이다.
64. Pair Program and Feel the Flow by Gudny Hauknes, Ann Katrin Gagnat, and Kari Røssland
- 짝 프로그래밍 좋아요. 장점이 이렇게나 많다구요. 하지만 어렵자나!
- “작업을 다른 짝에게 넘기기 위해 도중에 인터럽트를 거는 것이 납득이 잘 안될 수도 있지만, 우리는 이것이 문제없다는 것을 발견했습니다”
65. Prefer Domain-Specific Types to Primitive Types by Einar Landre
- 기본 타입보다 지금의 맥락에 맞는 타입을 따로 정의해서 사용하는게 더 낫다.
66. Prevent Errors by Giles Colborne
- 에러가 발생할 여지를 막아버리면 당연히 에러가 발생하지 않는다.
67. ★ ★ The Professional Programmer by Uncle Bob
- 전문 프로그래머란?
- 지속적인 학습을 통해 자신의 경력을 책임진다 + 완벽한 코드를 작성하려는 자세 + 팀 플레이어 + 버그는 절대 용납하지 않는다 + 대충대충하면서 엉망으로 만들지 않는다
- “만약 여러분이 유체 이탈을 해 의사가 여러분의 심장 절개 수술을 진행하는 장면을 지켜보고 있다고 상상해 보십시오. 그 의사가 전형적인 소프트웨어 개발자처럼 서두르면서 엉망으로 진행하기를 원하나요? 의사가 수술을 마치고 나서 ‘다시 돌아와서 나중에 고쳐도 될까요?’ 라고 말하기를 원하십니까?”
68. Put Everything Under Version Control by Diomidis Spinellis
- 코드뿐만 아니라 프로젝트와 관련된 모든 것들을 Repository 에 밀어넣고 관리하자. 논리적인 변경을 각각 별도로 커밋하자. 한꺼번에 하면 구분하기가 어렵다.
69. Put the Mouse Down and Step Away from the Keyboard by Burk Hufnagel
- 전체 맥락을 다시 생각해보기 위해서는 잠시 두뇌를 환기시키는게 좋다. 뽀모도로에서 의도적으로 5분을 쉬는것도 역시나 같은 이유때문이다.
70. Read Code by Karianne Berg
- 책도 좋다. 코드를 설명해놓은 문서도 좋다. 하지만 더 좋은 건 코드를 직접 읽어보는 것이다.
71. Read the Humanities by Keith Braithwaite
- 소프트웨어가 동작하는 방식과 소프트웨어를 개발하는 방식은 사실 사람들이 서로 돕고 함께 살아가는 이 세상과 닮아있다. 따라서 먼저 이 세상을 이해해보는건 어떨까?
72. ★ Reinvent the Wheel Often by Jason P Sage
- 이미 잘 쓰고있는 바퀴를 의도적인 학습을 목표로 다시 만들어보자. 분명히 값진 경험이 될 것이다.
- “항해와 관련된 영화를 보는 것과 직접 항해를 하는 것은 다르다”
73. Resist the Temptation of the Singleton Pattern by Sam Saariste
- 싱글톤에는 단점이 많다. 사용전에 꼭 필요한지 다시한번 생각하자. 특히 단위테스트가 어렵다는 단점이 가장 맘에 안든다.
74. The Road to Performance Is Littered with Dirty Code Bombs by Kirk Pepperdine
- 코드의 복잡성과 의존성을 파악하는 도구를 활용해서 미리미리 코드의 폭탄을 제거해놓자. 안그러면 성능개선을 위해서든 뭐든 코드변경이 필요할때 폭탄이 터져버릴것이다.
75. Simplicity Comes from Reduction by Paul W. Homer
- 코드를 간단하게 유지하자. 그럴려면 잘 돌아가는 기존의 코드도 간결하게 리팩토링할 의지와 용기가 있어야한다.
76. ★ The Single Responsibility Principle by Uncle Bob
- SRP. 단일 책임의 원칙. 하나의 서브시스템, 모듈, 클래스, 함수에는 한 가지 이상의 변경 이유가 있어서는 안된다.
77. Start from Yes by Alex Miller
- 긍정적인 마인드로 접근하면 긍정적인 면이 보이고 부정적인 마인드로 접근하면 부정적인 면만 보인다.
78. ★ Step Back and Automate, Automate, Automate by Cay Horstmann
- 한번 이상 반복될거라 생각되면 자동화해버리자. 일단 자동화가 되면 생각보다 편하게 실행할 수 있고 평소보다 훨씬 더 많이 실행할것이며 그에 따라 얻는 이득이 분명 있을 것이다.
79. Take Advantage of Code Analysis Tools by Sarah Mount
- 정적 코드 분석 툴을 활용하자. 분명히 문제인데도 툴이 잡아내지 못한다면 자신만의 분석툴을 만들어보자.
80. Test for Required Behavior, not Incidental Behavior by Kevlin Henney
- 코드가 구현되어있는대로 테스트하기 보다는 기대하는 동작대로 테스트를 작성하자.
- “코드로부터 무엇을 하는지를 명백하게 알 수 있음에도 이를 그저 반복해 확인하는 것은 가치 있는 일이 아니며 잘못된 진척률과 안도감을 줄 수 있습니다. false sense of progress.
81. Test Precisely and Concretely by Kevlin Henney
- 테스트를 작성할때는 기대하는 값에 대해서 정확히 검증하도록 하자. 어설프게 검증하면 구멍이 생긴다.
- “소프트웨어를 설계하는 방법에는 두 가지가 있다 : 한 방법은 설계를 아주 단순하게 해서 명백하게 결함이 존재하지 않게 하는 것이고, 다른 방법은 설계를 아주 정교하게 해서 명백한 결함이 존재하지 않게 하는 것이다”
82. Test While You Sleep (and over Weekends) by Rajith Attapattu
- 내가 일하고 있지 않는 시간에도 테스트는 돌아가게 해놓자. 어차피 그시간에 컴터는 논다. 회사 전기세를 걱정하지 않아도 되잖냐. 특히 시간이 오래걸리는 테스트라면 딱이다.
83. Testing Is the Engineering Rigor of Software Development by Neal Ford
- 테스트는 이제 소프트웨어 개발에서 엄격히 지켜야하는 규칙이다.
- “교량 건설자는 결코 상사로부터 ‘건물의 구조를 분석하느라 애쓰지 마. 우리 마감일은 빠듯하니까’ 라는 말을 듣지는 않을 것입니다”
84. Thinking in States by Niclas Nilsson
- 상태를 명확히 구분해야하는 시나리오라면 State Machine 을 사용하자.
85. Two Heads Are Often Better than One by Adrian Wible
- 짝 프로그래밍으로 배울 수 있는게 많다.
86. Two Wrongs Can Make a Right (and Are Difficult to Fix) by Allan Kelly
- 버그 두개가 서로 영향을 주어서 둘다 드러나지 않는 경우가 있다. 버그를 알아차리기도 힘들지만 수정하기는 더 힘들다. 그래서 어떻게해야한다? 잘 찾아서 고치자.
87. Ubuntu Coding for Your Friends by Aslam Khan
- 깨진 창문을 내버려 두지 말자. 코드는 너 혼자만의 것이 아니다. 당신이 작성한 나쁜 코드로 스트레스받을 동료 개발자를 생각하자.
- “사람은 다른 사람이 있기에 사람이다. 개발자는 다른 개발자가 있기에 개발자다. 코드는 다른 코드가 있기에 코드다”
88. The Unix Tools Are Your Friends by Diomidis Spinellis
- 유닉스 툴은 참 유용하다.
89. Use the Right Algorithm and Data Structure by JC van Winkel
- 알고리즘과 자료구조에 대해서는 기본적으로 잘 알아야한다. 그래야 효율적인 코드를 작성할 수 있다. 아니 문제있는 코드 작성을 피할 수 있다.
90. Verbose Logging Will Disturb Your Sleep by Johannes Brodwall
- 필요없는 로그 말고 필요한 로그만 적어보자.
91. WET Dilutes Performance Bottlenecks by Kirk Pepperdine
- Write Every Time. 동일한 코드가 중복되는 현상은 좋지 않다. 성능 개선을 위해 분석할때도 당연히 안좋다. 중복이 좋은게 뭐가 있겠나. 무조건 DRY 다.
92. When Programmers and Testers Collaborate by Janet Gregory
- 개발자와 검증자는 적이 되기 쉽다. 하지만 서로에게 배울 점이 분명히 있으며 서로 도움이 되는 부분도 분명히 존재한다. 너무 미워하지 말자.
93. Write Code as If You Had to Support It for the Rest of Your Life by Yuriy Zubarev
- 코드를 대하는 자세는 어때야 할까? 결혼 상대자를 찾는 것처럼 진중한 마음이어야 한다. 잠깐의 Enjoy 마인드는 안된다.
94. Write Small Functions Using Examples by Keith Braithwaite
- 도메인을 생각하면 고려해야하는 세계가 작아지고 훨씬 문제가 쉬워진다.
95. ★ Write Tests for People by Gerard Meszaros
- 테스트는 코드를 어떻게 사용해야하는가와 이 코드가 무슨일을 하는지를 설명해준다. 결국 테스트를 작성하는 것은 나를 위해서가 아닌 것을. 테스트의 장점은 수도없이 많다. 작성하자. 테스트. 두번 작성하자.
96. ★ You Gotta Care about the Code by Pete Goodliffe
- 프로그래밍을 함에 있어서 가장 중요한 것은 마음가짐이다. 아니 무슨일이든 마찬가지 일 것이다.
- “소프트웨어 회사에서의 다년간의 경험으로, 저는 적당한 프로그래머와 훌륭한 프로그래머 사이의 진짜 차이의 대한 결론을 내렸습니다. 바로 마음가짐입니다. 좋은 프로그래밍은 소프트웨어 회사의 현실적인 제약과 압력 속에서도 전문적인 접근 방법을 사용하려 하고, 여러분이 할 수 있는 최상의 소프트웨어를 작성하기를 원할 때 만들어집니다”
97. Your Customers Do not Mean What They Say by Nate Jackson
- 고객은 그들이 무엇을 원하는지 잘 모른다. 개발자도 모른다. 그러면 코드도 뭘하는지 모르게 된다. 고객을 자주 만나서 소통하자.
