«Clean coder» Robert C. Martin

В 2024 году на наших фронтэндерских митосиках я открыла книжный клуб. Мы начали с обсуждения самой полезной разработчикам книги «Clean coder». И хотя наши митинги проходят каждую неделю, чтение книги — раз в две недели. Читаем по одной главе и обсуждаем: согласны с автором или нет, делимся своим опытом и болью, находим, что можно было бы поменять в себе, рефлексируем.

К каждой главе я составляю краткий конспект — вопросы, которые можно было бы обсудить и над которыми можно самому подумать. Ниже представлен мой конспект по главам.

 

 

xiii. FOREWORD

• о чем история? кто из нас в трудностях закаляется (превращается в бриллиант)?
• почему эта история тут? чему она должна была нас научить или показать?

xix. PREFACE

• о чем история о взорвавшемся Шаттле?
• кто виноват?

xxiii. ACKNOWLEDGMENTS
xxix. ABOUT THE AUTHOR
xxxi. ON THE COVER

• почему автор на обложку поместил крабовидную туманность?

PRE-REQUISITE INTRODUCTION

• почему автор так много описывает свою биографию и в особенности свои ошибки?
• почему эта глава так важна и ее нельзя скипнуть?
  

Chapter 1. PROFESSIONALISM

8. BE CAREFUL WHAT YOU ASK FOR

• Согласны ли, что если заказчик из-за бага программиста потерял 10тыщ баксов, разработчик должен их вернуть?

8. TAKING RESPONSIBILITY

• что такое ответственность? как её брать?

11. FIRST, DO NO HARM. DO NO HARM TO FUNCTION

• Что значит не навреди функции?
• почему программист ответственнен за свой код и баги в нем?
• зачем тогда QA?

12. QA Should Find Nothing

• почему QA не должны ничего находить? За что им тогда платят?

13. You Must Know It Works

• каково должно быть покрытие приложения тестами? как вы думаете?
• сколько процентов времени разработчик должен тратить на написание тестов?

14. DO NO HARM TO STRUCTURE

• You must be able to make changes without exorbitant costs. А что ведет к плохой структуре? Почему со временем проект становится плохо поддерживаемым?
• Что мы можем сделать, чтобы его поддерживать?
• Что значит правило БойСкаута? Оставить проект после себя чище, чем до.
• Why do most developers fear to make continuous changes to their code? They are afraid they’ll break it! Why are they afraid they’ll break it? Because they don’t have tests.

16. WORK ETHIC

• Если мы работаем 40 часов на дядю, почему мы должны должны работать ещё 20 часов в нерабочее время?
• Кто из нас «работает» помимо 40 часов в неделю? Что вы делаете?
• Как нам развиваться как специалисту?
• Кто делает домашние проекты?

17. KNOW YOUR FIELD

• Какие принципы проектирования и разработки вы знаете и используете?
• Какие нужны для разработки фронтэнда?

19. CONTINUOUS LEARNING

• Какие профессиональные ресурсы вы читаете регулярно? На какие каналы подписаны, на каких людей?
• Откуда узнаете новости в разработке? Какие конференции посещаете?

19. PRACTICE

• в чем разница между performance (Doing your daily job) и practice?
• Что такое ката?

20. COLLABORATION

• Сколько времени вы проводите в парном программировании?

20. MENTORING

• У кого есть ментор? Кто сам менторит кого-то?

21. KNOW YOUR DOMAIN

• Тратите ли время на изучение доменной области проекта?

22. IDENTIFY WITH YOUR EMPLOYER/CUSTOMER

• насколько вы вовлечены в дело заказчика? насколько вы на его стороне?

22. HUMILITY (смирение, покорность)

• And so, programming is an act of supreme arrogance. (Итак, программирование - это акт величайшего высокомерия.)
• Согласны/нет?
  

 

Chapter 2. SAYING NO

• у кого-то был такой начальник как Фрэнк, которого все боятся?
• Slaves are not allowed to say no. Laborers may be hesitant to say no. But professionals are expected to say no.

26. ADVERSARIAL ROLES

• «OK, I’ll try.» - как слышит эту фразу заказчик?
• кого на пресейле просили занизить оценку?)

29. WHAT ABOUT THE WHY?

• почему зачастую не нужно объяснять ПОЧЕМУ задача займет 2 недели?
• что такое микро-менеджмент? кто-то с ним сталкивался? к чему он ведет?

29. HIGH STAKES

• почему важно озвучивать свое НЕТ как можно раньше?

30. BEING A “TEAM PLAYER”

• что такое быть командным игроком?
• кто-то сталкивался с уговариваниями на работе? считаете ли это такой же страшной вещью, как и запугивание (см. случай с Фрэнком)?

32. TRYING

• что такое Попытаться? «Я попытаюсь», «Я попробую»? Не звучит ли как обещание?

34. PASSIVE AGGRESSION

• что такое пассивная агрессия на работе? сталкивались ли вы с таким?

36. THE COST OF SAYING YES
36. IS GOOD CODE IMPOSSIBLE?
37. The Typical Project Proposal
38. Two Weeks to Completion
39. The Clients Never Care as Much as You Do
40. Result? Rush to Complete, Slow to Market

• понравилась ли история?
• узнаете ли в ней своих заказчиков?

41. CODE IMPOSSIBLE

• можно ли всё-таки писать красивый код?
  

Chapter 3. SAYING YES

47. A LANGUAGE OF COMMITMENT

• из каких составных состоит принятие обязательств? Say. Mean. Do.
• а у вас были случаи, когда ваши коллеги не делали то, о чем говорили?
• как вы относитесь к фразе: «Я подумаю?»

48. RECOGNIZING LACK OF COMMITMENT

• используете ли вы размытые слова Need\should, Hope\wish, Let’s, чтобы избежать ответственности?
• есть ли среди вашего окружения необязательные люди? которые много говорят, но мало делают? доверяете ли вы им?

49. WHAT DOES COMMITMENT SOUND LIKE?

• страшно ли пообщать и не сделать? если есть только две опции: сделано и не сделано

50. It wouldn’t work because I rely on person X to get this done.

• можно ли быть ответственным если результат зависит не только от тебя? что в этом случае нужно делать?
• пример: кто ответственен за код-ревью твоей задачи? и за то, чтобы она поскорее попала в DONE?

51. It wouldn’t work because I don’t really know if it can be done.
51. It wouldn’t work because sometimes I just won’t make it.

• что делать, если невозможно выполнить данное обещание?

52. SUMMARY

• страшно ли вам просить помощи у других?

52. LEARNING HOW TO SAY “YES”
52. THE OTHER SIDE OF “TRY”
53. COMMITTING WITH DISCIPLINE

• как вам история неуверенного Питера и уверенного?
• понравилось ли насколько по-разному можно решить ситуацию в зависимости от исходных данных (срочности, возможности переноса релиза и проч.)?

56. CONCLUSION

• вам нравятся уверенные люди? люди, готовые отвечать за свои слова? хотели бы вы быть такими?
  

Chapter 4. CODING

• а вы умеете печатать слепым набором?

58. PREPAREDNESS

• 4 базовых принципа:
  1. код должен работать,
  2. код должен решать проблему заказчика
  3. код должен вписываться в существующую систему
  4. код д.б. читаемым другими программистами

• а вы программируете когда устали или отвлечены?

59. 3 AM CODE

• программируете ли вы ночью? когда (в какие часы) вам лучше всего писать код?

60. WORRY CODE

• писали ли вы код в стрессе? (когда дома что-то не ладилось, волновались из-за ссоры или болезни близких) (или из-за сроков?)
• был у вас заказчик, который «создавал» стрессовую ситуацию на работе?
• как автор предлагает решать отвлекающие задачи, которые занимают наш мозг в рабочее время?

62. THE FLOW ZONE

• что такое быть в потоке?
• были ли вы в потоке? писали ли в это время код? был ли он хорош? когда чаще всего приходит состояние потока?
• почему стоит избегать состояния потока?

63. MUSIC

• слушаете ли вы музыку на работе?
• помогает ли она вам в написании кода или нет?
• почему автор считает, что лучше не слушать?

63. INTERRUPTIONS

• как вы реагируете на людей, которые отрывают вас от работы?
• когда вы просите у кого-то помощи и открываете других, как они себя ведут?
• был ли у вас опыт парного программирования?

64. WRITER’S BLOCK

• было ли у вас такое, что вы не могли написать ни строчки кода? например, из-за недостатка сна, беспокойства, страха или депрессии.

65. CREATIVE INPUT

• что вас вдохновляет на создание/творчество в программировании? книги, театры, музыка?

66. DEBUGGING

• а как вы относитесь к своему коду? можете ли доверить его разработку кому-то ещё?
• легко ли вам разбираться в чужом коде?
• а в своем годовой давности?

69. DEBUGGING TIME

• думаете ли вы о времени на дебаг как о времени на написание кода?
• что значит сократить время на отладку? и как это можно сделать? (TDD)

69. PACING YOURSELF

• «Software development is a marathon, not a sprint.» Тогда почему мы работаем спринтами?)

70. KNOW WHEN TO WALK AWAY

• было ли у вас, что «утро вечера мудренее»? Когда вчерашняя задача, над которой ломали голову, с утра легко решилась?
• что вы делаете, когда устаете, а задача остается нерешенной?

70. DRIVING HOME
71. THE SHOWER

• приходят ли вам в голову решения рабочих задач вне рабочее время?

71. BEING LATE

• какие три оценки нужно обновлять ежедневно? наилучшую, среднюю и наихудшую

71. HOPE

• что значит «Hope is the project killer»?

71. RUSHING

• повторю вопрос из предыдущей главы: а вас просили занизить оценки, сидя рядом и просматриваю ваши оценки?

72. OVERTIME

• ваш начальник просил когда-либо вас поовертаймить?
• какие три условия важно соблюдать при овертайме: 1) если вы можете себе это позволить 2) овертайм краткосрочный (до двух недель) 3) у начальства есть запасной план, если ничего не выгорит

73. FALSE DELIVERY

• сталкивались ли вы с таким? когда «done» не обозначает «done»

73. DEFINE “DONE”

• как сделать так, чтобы «done» означало «done»? (tests)

73. HELP
74. HELPING OTHERS

• почему важно помогать другим разработчикам?
• сколько времени вы остаётесь доступными для помощи в течении рабочего дня?

74. BEING HELPED

• как принимать помощь других?
• согласный ли с утверждением, что программисты в большинстве своем интроверты?

75. MENTORING

• есть ли у вас ментор?
• или вы сами менторите кого-то?

76. BIBLIOGRAPHY

Chapter 5. TEST DRIVEN DEVELOPMENT

• слышали ли вы про TDD? а про Test First Programming?
• а у вас был опыт разработки по TDD?

79. THE JURY IS IN

• I don’t think surgeons should have to defend hand-washing, and I don’t think programmers should have to defend TDD. Я не думаю, что хирурги должны защищать мытье рук, и я не думаю, что программисты должны защищать TDD.

79. THE THREE LAWS OF TDD

• Три закона TDD:

1. Нельзя начать писать код, пока не напишите первый падающий unit-тест
2. Нельзя писать больше unit-тестов, чем требуется для того, чтобы тест упал (?)
3. Нельзя писать больше кода, чем требуется для починки падающего теста

80. THE LITANY OF BENEFITS
80. Certainty (определенность)

• какое покрытие кода тестами предлагает Мартин?

81. Defect Injection Rate (частота появления багов)
81. Courage

• исправляете ли вы баги, которые видите, если они не в скоупе ваших задач?
• откуда берется эта боязнь исправить какой-то баг?
• где взять смелось что-то починить?

82. Documentation

• как мы читаем документацию сторонних библиотек и фреймворков? На что обращаем внимание в первую очередь? На текст или код?

82. Design

• как написание теста перед написанием кода помогает в проектировании good design?
• But the tests you write after the fact are defense. The tests you write first are offense. (Но тесты, которые вы пишете постфактум, - это защита. Тесты, которые вы пишете сначала, - это нападение).

83. THE PROFESSIONAL OPTION
83. WHAT TDD IS NOT

• чем не является TDD?

84. BIBLIOGRAPHY

Chapter 6. PRACTICING

86. SOME BACKGROUND ON PRACTICING

• почему раньше не нужно было практиковаться в программировании?
• или скорее, как вы думаете, почему сейчас нужно это делать?
  

87. TWENTY-TWO ZEROS

• что за цифра 6.4 * 10^22?

88. TURNAROUND TIME

• что такое HDD, or Hammock-Driven Development (Rich Hickey)?

89. THE CODING DOJO

• решали ли вы когда-нибудь каты?
• решали ли кату для задачи «Игра в боулинг»?

90. KATA

• что такое ката?

91. WASA

• что такое васа?
• как тренировать васа в паре в программировании?

92. RANDORI

• что такое рандори?
• хотелось бы вам поучаствовать в таком?

93. BROADENING YOUR EXPERIENCE

93. OPEN SOURCE

• почему можно-нужно писать опенсорс?

93. PRACTICE ETHICS

• почему практиковаться нужно в свое время, а не в оплачиваемое время заказчика?

94. CONCLUSION

95. BIBLIOGRAPHY  

Chapter 7. ACCEPTANCE TESTING

95. COMMUNICATING REQUIREMENTS

• чему учит история его работы с Томом, который хотел изучить редактор, но в итоге Боб написал вместо него приложение

97. PREMATURE PRECISION

• что значит преждевременная точность? (со стороны разработчика и со стороны заказчика)

97. The Uncertainty Principle

• что значит принцип неопределенности? или почему заказчики меняют свои требования по ходу дела?

98. Estimation Anxiety

• испытываете ли вы тревогу по поводу свои оценок? попадаете ли вы обычно в них? или склонны занижать?

98. LATE AMBIGUITY

• сталкивались ли вы с ситуацией, когда неразрешенные вопросы вели к неверному выполнению задачи? как в случае сохранения логов (пример Паулы и Сэма)

100. ACCEPTANCE TESTS

• что такое приёмочные тесты?

100. THE DEFINITION OF “DONE”

• что значит: таска готова/выполнена (done)?
• что бы вы улучшили в примере общения Сэма, Паулы и Тома (тестировщика) на создание таски для хранения логов? считаете ли что-то избыточным? 

103. COMMUNICATION

• почему мы говорим о прозрачности в коммуникациях?

103. AUTOMATION

• почему приемочные тесты дожны быть автоматическими? (не мануальными)

105. EXTRA WORK

105. WHO WRITES ACCEPTANCE TESTS, AND WHEN?

• кто в идеальном мире должен писать приемочные тесты? и кто пишет в действительности?
• почему их не должен писать тот же разработчик, который имплементирует код?
• когда должны быть написать приемочные тесты в идеале? и в реальном мире?

106. THE DEVELOPER’S ROLE

• какова роль разработчика в написании тестов? (если он их не пишет)

107. TEST NEGOTIATION AND PASSIVE AGGRESSION

• может ли тест быть неправильным?
• почему когда мы говорим о профессионализме, так часто всплывают личные качества человека: умение договариваться, нацеленность на результат, а не на собственное эго?

108. ACCEPTANCE TESTS AND UNIT TESTS

• чем отличаются приемочные тесты от юнит-тестов?

109. GUIS AND OTHER COMPLICATIONS

• почему сложно писать тесты на GUIs?
• какие сейчас у нас есть критерии для проверки? (accessibility, design pattern & guides)
• что означает принцип единой ответсвенности? Single Responsibility Principle (SRP)

110. Testing through the Right Interface

• почему мы должны отделять GUI от бизнес-логики?

110. CONTINUOUS INTEGRATION

• зачем нужны системы непрерывной интеграции? как часто запускать на них тесты?
• настроены ли у вас в проекте CI и запуск тестов? с оповещением об ошибках

111. Stop the Presses

• прерываете ли вы работу ,чтобы починить упавшие тесты? удаляете ли вы падающие тесты? о_О

111. CONCLUSION

• почему так важны коммуникации для разработчика? что мы постоянно об этом говорим
• почему важны приемочные тесты?

Chapter 8. TESTING STRATEGIES

114. QA SHOULD FIND NOTHING

• почему QA не должны ничего находить?
• должны ли нам платить больше, чем QA, если мы выполняем их работу? вы же выполняете их работу у себя на проекте?

114. QA Is PART OF THE TEAM

114. QA as Specifier

• какова роль QA как спецификаторов? что они должны делать? (обновлять документацию, писать приёмочные тесты, собирать требования бизнеса, описывать разработчикам, как система должна работать).
• чем отличается роль QA от бизнес-аналитиков в таком случае?

114. QA as Characterizers

• какова роль QA как характеризаторов? (определять реальное поведение системы и предоставлять по нему отчеты). Что это значит?

115. THE TEST AUTOMATION PYRAMID

• что показывает Пирамида автоматизации тестирования?
• 5% – Exploratory System tests (М)
• 10% – System tests (gui)
• 20% – Integration tests (api)
• 50% – Component tests (api)
• 100% – Unit tests (XUnit) 

116. UNIT TESTS

• для кого, кем и на чем пишутся юнит-тесты? (повторяем прошлую главу)

116. COMPONENT TESTS

• кем и на чем пишутся компонентные тесты? что они тестируют?

117. INTEGRATION TESTS

• кем и на чем пишутся интергационные тесты? что они тестируют?
• почему эти тесты считаются техническими и не проверяют бизнес-логику? зачем они тогда нужны?
• как часто они должны запускаться?

118. SYSTEM TESTS

• кем и на чем пишутся интергационные тесты? что они тестируют?
• чем они отличаются от интеграционных?
• видели ли вы такие тесты в реальном проекте?

118. MANUAL EXPLORATORY TESTS

• кто и зачем проводит ручное тестирование?
• должен ли быть структурированный план у таких тестов?

119. CONCLUSION

Небольшой тестик от меня на понимание Пирамиды автоматизации тестирования:

• к какому типу можно отнести нагрузочное тестирование? тестирование производительности?
• тестирование формы логина?
• тестирование доступности приложения для слабовидящих?
• тестирование приложения только с помощью клавиатурного ввода? (без использования мышки)
• тестирование нотификаций? (работа нотификаций, частота показа, звуковой сигнал)

Chapter 9. TIME MANAGEMENT

• сталкивались ли вы с подобным графиком работы, когда она наваливается и наваливается. Делали ли вы что-то с этим?

122. MEETINGS

• что означают два утверждения: 1) совещания необходимы 2) совещания - это огромная трата времени.

123. DECLINING

• нужно ли ходить на все собрания, на которые вас приглашают?
• кто решает какие собрания посещать, а какие — нет?

124. LEAVING

• как можно вежливо уйти с совещания?

124. HAVE AN AGENDA AND A GOAL

• почему у каждого совещания должен быть план и цель?

125. STAND-UP MEETINGS

• почему дейлики называются стэндап митингами?
• каковы три вопроса на дейликах: 1. Что я делал вчера? 2. Что я собираюсь сделать сегодня? 3. Что мне мешает?

125. ITERATION PLANNING MEETINGS

• что должно быть готово к совещания по планированию скоупа работ на следующую итерацию (спринт)?
• сколько времени на него можно выделить? (5% от итерации, для недели это не более 2 часа)

126. ITERATION RESTROSPECTIVE AND DEMO

• сколько времени занимает ретроспектива? (45 минут: не более 20 мин. на ретроспективу и 25 мин. на демонстрацию)

126. ARGUMENTS /DISAGREEMENTS

• согласны ли вы с высказываением, что если спор нельзя уладить за 5 минут, то он не может быть разрешен путем спора. “Any argument that can’t be settled in five minutes can’t be settled by arguing.”
• спорили ли вы когда-либо на работе?
• сталкивались с пассивной агрессией других? или замечали в своем поведении?
• как разрешать споры? (подбросить монету, проверить каждую теорию экспериментом, высказать всем участникам за и против не более 5 минут и проголосовать)

127. FOCUS-MANNA

• что такое мана в понятиях программиста? (концентрация/сосредоточенность/фокус)
• как можно восстанавливать свою ману?

128. SLEEP
128. CAFFEINE
128. RECHARGING
129. MUSCLE FOCUS
129. INPUT VERSUS OUTPUT
130. TIME BOXING AND TOMATOES

• пользуетесь ли вы техникой помидорок? пробовали ли?
• в чем она заключается?

131. AVOIDANCE
131. PRIORITY INVERSION

• что такое инверсия приоритетов? (выполнение задач с низким приоритетом из-за боязни сложных задач с высоким приоритетом)
• замечали ли вы за собой такое?

131. BLIND ALLEYS

• что такое тупиковые пути?
• попадали ли в такие ситуации?

132. MARSHES, BOGS, SWAMPS, AND OTHER MESSES

• что значат эти болота, трясины, топлячки и прочий хлам?

133. CONCLUSION

Chapter 10. ESTIMATION

• чему учит история с 32 чипами, которые нужно обновлять одновременно при любом изменении кода?

138. WHAT IS AN ESTIMATE?
138. A COMMITMENT

• почему бизнес рассматривает оценки как обещание?

138. AN ESTIMATE

• почему для разработчика оценка — это предположение?
• что значит: Оценка - это не число. Оценка - это распределение.
• должны ли мы учитывать закон Мерфи при оценке: Murphy’s Law holds that if anything can go wrong, it will go wrong.

140. IMPLIED COMMITMENTS (предсказуемые обязательства)

• как придти с компромиссу в оценке с большим диапазоном оценки?

141. PERT (Program Evaluation and Review Technique)

• какую систему оценки использовали в PERT? (трехфакторный анализ: Optimistic Estimate, Nominal Estimate, Pessimistic Estimate).
• как вычислить ожидаемую продолжительность выполнения задачи, использую эти 3 оценки? и стандартное отклонение последовательности?

144. ESTIMATING TASKS
144. WIDEBAND DELPHI

• что такое метод оценки Wideband Delphi, основанный на консенсусе метод оценки усилий?

145. Flying Fingers

• в чем заключается метод летающих пальцев?)

145. Planning Poker

• в чем заключается метод планирования игры в покер?

146. Affinity Estimation

• в чем заключается метод оценки по подобию (схожести)?

147. Trivariate Estimates

• в чем заключается метод трехмерной оценки?

147. THE LAW OF LARGE NUMBERS

• в чем заключается закон больших чисел? Сумма оценок разбитых подзадач более точны, чем оценка неразбитой задачи.

147. CONCLUSION

• как вы даете оценки задачам?

149. BIBLIOGRAPHY

Chapter 11. PRESSURE

• как должен вести себя врач в операционной?
• как работал Мартин и его коллеги в «Clear Communications» в 1988? по 80 часов в неделю

151. AVOIDING PRESSURE
152. COMMITMENTS

• почему профессионалы должны помогать бизнесу, но не должны подписываться под обещаниями бизнеса?

152. STAYING CLEAN

• почему “быстро и грязно” - это оксюморон?

153. CRISIS DISCIPLINE

• что означает ваше поведение в кризисной ситуации?
• следуете ли вы своим принципам в кризисной ситуации?
• как вы ведете себя в кризисной ситуации? были ли у вас такие?

153. HANDLING PRESSURE

• что значит управление давлением?

153. DON’T PANIC
154. COMMUNICATE

• почему нужно сообщать команде и менеджерам о критических ситуациях?

154. RELY ON YOUR DISCIPLINES

• каким принципам вы следуете? то есть что будете делать в критической ситуации?

154. GET HELP

• как парное программирование помогает в критич. ситуациях?

155. CONCLUSION

Chapter 12. COLLABORATION

• есть ли у вас такой друг, с кем вы работали или работаете, как Тим Конрад у Мартина?

159. PROGRAMMERS VERSUS PEOPLE

• почему в большинстве своем программисты любят работать в одиночку?

159. PROGRAMMERS VERSUS EMPLOYERS

• какая история научила Мартина, что нужно не только хорошо делать свою работу, но и понимать цели и задачи бизнеса?
• «In short, they pay attention to the ship they are sailing on.» Как мы это дожны делать?
• почему Мартину не нравилось на работе, где его заставляли носить галстук?
• если бы на текущей работе было принято носить галстук, вы бы делали это?
• почему Мартина уволили с той работы?

163. PROGRAMMERS VERSUS PROGRAMMERS
163. Owned Code

• кто владеет кодом? программист, тестировщик, команда, техлид или вся компания?

163. Collective Ownership

• что означает коллективное владение кодом?

164. Pairing

• в чем смысл парного программирования?
• был ли у вас опыт парного программирования? с кем бы вы хотели попрограммировать в паре?

164. CEREBELLUMS (мезжечки)

• почему заголовок называется «Мозжечки» и что представил Мартин в объявлении «Come rub cerebellums with the best.»

166. CONCLUSION

Chapter 13. TEAMS AND PROJECTS

168. DOES IT BLEND?

• как распределяется работа между разработчиками в банках и страховых компаниях, где много маленьких проектов?

168. THE GELLED TEAM

• как строится идеальная сплоченная команда по Мартину? сколько в ней должно быть человек и какие у каждого роли и задачи?

169. Fermentation

• что означает «магия» в сплоченной команде?
• как строится сплоченная команда? как бы вы ее могли построить?
• можно ли построить сплоченную команду с непрофессионалами? с не командными игроками?

169. Which Came First, the Team or the Project?

• так что первично: команда или проект?

170. BUT HOW DO YOU MANAGE THAT?

• почему Мартин предпочитает, чтобы часы делились на команду, а не на разработчика? Если в команде так же разработчик может делить свои часы

170. THE PROJECT OWNER DILEMMA

• в чем заключается дилемма «владельца проекта»?
• как вы видите организацию в вашем текущем проекте? как можно было бы ее поменять на сплоченную команду?

171. CONCLUSION

Chapter 14. MENTORING, APPRENTICESHIP, AND CRAFTSMANSHIP

174. DEGREES OF FAILURE

• может ли студент со степенью в компьютерных науках не уметь программировать?
• почему в университетах не готовят тому, что требуется в работе?

174. MENTORING
175. DIGI-COMP I, MY FIRST COMPUTER

• чему учит история Мартина с его первой работающей программой на булевой алгебре?
• помните ли вы свою первую программу, которая заработала и вдохновила вас?

176. THE ECP-18 IN HIGH SCHOOL

• какой урок вынес Мартин из истории в старшей школе, когда принесли в класс новый комп?

179. UNCONVENTIONAL MENTORING

• как много наставников было у Мартина?
• а сколько у вас было наставников и учителей?
• как можно обучать и учиться? (способы)

179. HARD KNOCKS

• что лучше учит: большой жизненный пинок или ментор, который направляет?

180. APPRENTICESHIP

• хотели бы вы, чтобы у разработчиков была интернатура, как у врачей? а ординатура?

182. SOFTWARE APPRENTICESHIP
182. Masters

• кто такие мастера, их роли и задачи

182. Journeymen (подмастерья)

• кто такие подмастерья? Как они работают? Какие у них навыки?

183. Apprentices/Interns

• кто такие ученики? чем занимаются, что изучают? как переходят в подмастерья?

183. THE REALITY

• чем отличается описанный Мартином метод от реальности? Чего хочет Мартин от наставников?

184. CRAFTSMANSHIP (мастерство)

• так что такое мастерство?

184. CONVINCING PEOPLE

• почему убеждение людей не работает? (убеждать быть мастерами)
• как нужно передавать дух мастерства? (своим примером)

185. CONCLUSION

• почему школы не могут научить всему?
• кто должен внедрять программы обучения, стажировки и долгосрочного руководства?

Appendix A. TOOLING

• о чем история Мартина? какие раньше были тулзы для обновления кода?

189. TOOLS
189. SOURCE CODE CONTROL

• почему open-source проекты лучше? (пишутся разработчиками для разаботчиков)

189. AN “ENTERPRISE” SOURCE CONTROL SYSTEM

• как Мартин предлагает найти компромисс, если компания закупила корпоративное ПО и вынуждает им пользоваться?

190. PESSIMISTIC VERSUS OPTIMISTIC LOCKING

• что такое пессимистическая блокировка (запрет файла на редактирование одним из разработчиков для предотвращения конфликта в нем)
• что сейчас используется?

191. CVS/SVN

• каковы преимущества и недостатки CVS/SVN?

191. Branching
191. git

• в чем основная идея git’а?

194. IDE/EDITOR
194. VI

• работали ли вы в vi? используете ли до сих пор?

195. EMACS

• что насчет EMACS?

195. ECLIPSE /INTELLIJ

• как меняется разработка с развитием IDE? (разработка больше не о строчках и символах, а о комплексных действиях и трансформациях).

196. TEXTMATE

• почему такие простые программы для редактирования всё еще популярны?

196. ISSUE TRACKING

• какие сейчас используются инструменты для задач?

197. BUG COUNTS

• как много должно быть «багов»? и где они должны быть записаны?

197. CONTINUOUS BUILD

• каким должен быть процесс сборки?

198. UNIT TESTING TOOLS

• какими свойствами должны обладать юнит-тесты? 1) их легко и быстро запускать, 2) понятное представление pass/fail, 3) понятное понимание прогресса, 4) отдельные тесты не должны взаимодействовать между собой, 5) должно быть легко писать тесты

199. COMPONENT TESTING TOOLS

• кто должен пистаь и понимать эти тесты? БА или QA

199. THE DEFINITION OF DONE

• что означает done в рамках этих тестов? (все тесты пройдены)

199. FITNESSE

• как думаете, почему Мартин написал свой фрэймворк для написания тестов?

200. OTHER TOOLS

• какие сейчас инструменты вы используете для написания тестов?

200. INTEGRATION TESTING TOOLS

• почему интеграционных тестов должно быть мало и что они проверяют?

201. UML/MDA

• почему не сбылась мечта Мартина, чтобы программисты высокоуровнево описывали программы, не вникая в реализацию? Model Driven Architecture (MDA)

201. THE DETAILS

• описание завершения конца строки и перевод каретки ‘\r\n’, похожа ли эта ситуация на спор space vs tabs?

203. NO HOPE, NO CHANGE

• есть ли надежда с ИИ у MDA?

204. CONCLUSION

• инструменты всё время меняются, легко ли вам дается переход на новый инструмент? открыты ли вы к этим изменениям?