Роберт Мартин - Идеальный программист. Как стать профессионалом разработки ПО

Да, вы правильно поняли: микросхемы превратились в аналоги объектов с v-таблицами, а функции вызывались полиморфно. Именно так я узнал некоторые принципы объектно-ориентированного программирования задолго до того, как познакомился с понятием «объект».

Выгода от такого решения была огромной. Мы получили возможность не только ограничиться установкой отдельных микросхем, но и вносить исправления «на месте», перенаправляя векторы в оперативной памяти. Это значительно упростило отладку и «горячие» исправления.

Но я отклоняюсь от темы. Когда Кен пришел ко мне с предложением решить проблему, он предложил подумать об указателях на функции. Я потратил день-два на формальное изложение идеи, а затем представил подробный план. Он спросил, сколько времени займет работа; я сказал, что около месяца.

Мне понадобилось три месяца.

Я напивался только дважды в жизни и только один раз напился основательно. Это произошло на праздновании Рождества в Teradyne в 1978 году. Мне тогда было 26 лет.

Праздник проводился в офисе Teradyne, который в основном состоял из открытого лабораторного пространства. Все пришли рано, а сильная снежная буря не позволила оркестру и фирме выездного обслуживания добраться до нас. К счастью, выпивки было достаточно. Я не очень хорошо помню этот вечер, а то, что помню , предпочел бы забыть. И все же я не могу не поделиться одним важным моментом.

Я сидел по-турецки на полу с Кеном (мой начальник – ему тогда было 29 лет, и он был трезв), сетуя на то, сколько времени у меня заняла векторизация. Алкоголь освободил мои скрытые страхи и неуверенность по поводу исходной оценки. Надеюсь, я не клал голову ему на плечо – впрочем, такие подробности не очень четко отложились у меня в памяти.

Помню, я спросил, не сердится ли он на меня и не считает ли, что работа заняла слишком много времени. И как бы смутно я ни помнил тот вечер, его ответ четко отложился у меня в памяти на последующие десятилетия. Он сказал: «Да, я думаю, что прошло много времени, но я вижу, что ты прилежно трудишься, а работа не стоит на месте. И нам это действительно нужно. Так что я не сержусь».

Проблема в том, что оценки можно рассматривать по-разному. Бизнес любит рассматривать их как обязательства. Разработчики предпочитают рассматривать оценки как предположения. Между этими точками зрения существуют принципиальные различия.

Обязательство – нечто такое, что вы обязаны сделать. Если вы обязуетесь сделать что-то к определенной дате, то к этой дате «что-то» должно быть готово. Если для этого вам придется работать по 12 часов в сутки и по выходным, пропускать семейные праздники – так тому и быть. Вы приняли обязательство и его необходимо соблюдать.

Профессионалы не принимают на себя обязательств, если только они не уверены в возможности их выполнения. Да, все просто. Если вам предлагают принять на себя обязательство, а вы не уверены, что сможете справиться с задачей, – ваша честь требует отказаться. Если вам предлагают принять обязательство, которое, на ваш взгляд, выполнимо, но потребует сверхурочных, работы по выходным и пропущенного семейного отдыха – решайте сами; но если уж пообещали – выполняйте.

Обязательствам присуща определенность . Другие люди принимают ваши обязательства и используют их как базу для построения собственных планов. Нарушение обязательств обернется огромным ущербом для вашей репутации; это проявление непорядочности, лишь немногим лучшее открытой лжи.

Оценка, прежде всего, является предположением. Она не подразумевает никаких обязательств. Вы ничего не обещаете. Нарушение оценки ни в коей мере не повредит вашей репутации. Мы выдаем оценки, прежде всего, потому, что мы не знаем , сколько времени займет работа.

К сожалению, многие разработчики очень слабы в оценках. Дело не в том, что оценка требует какого-то тайного мастерства – вовсе нет. Дело в том, что мы часто не понимаем истинной природы оценки.

Оценка – это не число, а распределение. Возьмем следующий диалог:

Майк: «Сколько, по твоим оценкам, понадобится для завершения работы?»

Питер: «Три дня».

Питер действительно управится с работой за три дня? Возможно, но насколько вероятно? Правильный ответ: понятия не имеем. Что имел в виду Питер и что узнал Майк? Если Майк вернется через три дня и работа не будет выполнена, должен ли он удивляться? А почему, собственно? Питер не давал никаких обязательств. Питер не сказал ему, насколько три дня вероятнее четырех или пяти.