97 этюдов для программистов. Опыт ведущих экспертов - Пит Гудлиф
Для проведения надежной оценки необходимо владеть некоторыми приемами. Однако сначала следует разобраться, что собой представляют оценки и для чего они могут быть использованы — как ни странно, многие разработчики и менеджеры плохо в этом разбираются.
Вот типичный диалог между менеджером проекта и программистом:
Менеджер: Можешь оценить, сколько тебе нужно времени, чтобы разработать функцию X?
Программист: Месяц.
Менеджер: Это слишком долго! У нас есть всего неделя.
Программист: Мне нужно хотя бы три.
Менеджер: Больше двух я тебе дать не могу.
Программист: По рукам!
В итоге программист предлагает «оценку», приемлемую для менеджера. Но поскольку она как бы сделана программистом, менеджер будет считать, что программист несет за нее ответственность. Для понимания того, что неправильно в этом диалоге, нам нужны три определения: оценки, цели и обязательства:
• Оценка — это приблизительный подсчет или суждение относительно значения, числа, количества или протяженности чего-либо. Это определение предполагает, что оценка является фактической мерой, основанной на надежных данных и прежнем опыте; мечты и пожелания должны быть исключены при ее расчете. Это определение предполагает также, что оценка приблизительна и не может быть дана точно, например, оценка продолжительности разработки не может составить 234,14 дня.
• Цель — это описание бизнес-задачи, которую требуется решить, например «система должна поддерживать одновременную работу не менее 400 пользователей».
• Обязательство — это обещание обеспечить указанную функциональность с определенным уровнем качества к определенному сроку или событию. Например, «функция поиска будет доступна в следующей версии продукта».
Оценки, цели и обязательства не зависят друг от друга, но цели и обязательства должны основываться на надежных оценках. Как отмечает Стив Макконнелл,[18] «главная задача оценок в программировании — не предсказание результата проекта, а определение реалистичности целей проекта и возможности их достижения при правильном управлении». Таким образом, полученные оценки должны обеспечить возможность надлежащего планирования и управления проектом, что позволит заинтересованным участникам проекта брать обязательства исходя из реалистичных целей.
В приведенном выше диалоге менеджер в действительности требовал от программиста не оценки, а принятия обязательства в отношении невысказанной цели, которая была в голове этого менеджера. Когда вам в следующий раз предложат сделать оценку, убедитесь, что все стороны хорошо представляют, о чем идет речь, и тогда шансы на успех ваших проектов вырастут. А вот теперь пора освоить несколько приемов…
Научитесь говорить «Hello, World»
Томас Гест
Пол Ли, под ником leep, более известный под прозвищем Хоппи, слыл местным экспертом по вопросам программирования. Мне потребовалась помощь. Я подошел к его рабочему столу и спросил, не посмотрит ли он вместе со мной кое-какой код.
«Конечно, — сказал Хоппи, — бери стул». Я осторожно придвинулся, стараясь не опрокинуть пирамиду пустых банок из-под колы, громоздившуюся рядом с ним.
«Что за код?»
«В функции в файле», — сказал я.
«Ладно, посмотрим на эту функцию». Хоппи отодвинул в сторону экземпляр «K&R»[19] и придвинул ко мне клавиатуру.
«А где IDE?» Выяснилось, что у Хоппи не было IDE, лишь некий редактор, в котором я не умел работать. Он забрал клавиатуру обратно. Несколько нажатий на клавиши, и перед нами предстал файл — довольно большой файл, а затем и функция — довольно большая функция. Он листал ее, пока не добрался до условно выполняемого блока, о котором я хотел спросить.
«Что здесь произойдет при отрицательном x? — спросил я. — Здесь явно ошибка».
Все то утро я пытался заставить x принять отрицательное значение, но большая функция в большом файле была частью большого проекта, и меня совершенно измотала необходимость повторно компилировать и повторно запускать свои эксперименты. Может быть, такой эксперт, как Хоппи, просто сообщит мне верный ответ?
Хоппи признался, что он не вполне уверен в результатах. К моему удивлению, он не потянулся за «K&R». Вместо этого он скопировал блок кода в новый буфер редактора, заново расставил отступы и обернул его в функцию. После этого он написал функцию main, выполнявшую бесконечный цикл, в котором она предлагала пользователю ввести значение, передавала его функции и выводила результат. Он сохранил буфер в виде нового файла tryit.c.
Все это я мог бы сделать и сам, разве что не так быстро. Но следующий его шаг был очень прост, и в то время такой способ работы был мне совершенно незнаком:
$ cc tryit.c &&./a.out
Надо же! Его программа, придуманная всего за несколько минут до того, работала полным ходом. Мы опробовали несколько значений, и мои подозрения подтвердились (хоть в чем-то я оказался прав!), и лишь затем он дополнительно сверился с соответствующим разделом «K&R». Я поблагодарил Хоппи и ушел, снова стараясь не обрушить его пирамиду банок из-под колы.
Вернувшись на рабочее место, я закрыл свою IDE. Я так привык работать над большими проектами в рамках больших продуктов, что стал думать, будто именно так и должен работать. А ведь компьютер, предназначенный для решения самых глобальных проблем, может решать и мелкие задачи. Я открыл текстовый редактор и набрал:
#include <stdio.h> int main() {
printf("Hello, Worldn");
return 0;
}
Пусть ваш проект говорит сам за себя
Дэниэл Линднер
Скорее всего, в вашем проекте имеется система управления версиями. Весьма вероятно также, что она подключена к серверу непрерывной интеграции, который проверяет корректность проекта с помощью автоматизированных тестов. Это замечательно.
Можно подключить средства статического анализа кода к серверу непрерывной интеграции и получать метрики кода. Эти метрики сообщают специфические характеристики вашего кода и их изменения во времени. Когда введены метрики кода, всегда имеется красная черта, которую нельзя пересекать. Допустим, что вначале у вас покрыто тестами 20 % кода, и вы не хотите, чтобы эта величина опускалась ниже 15 %. Непрерывная интеграция позволяет следить за всеми этими числами, но все равно вам придется регулярно проверять их значения. Было бы хорошо, если бы проект самостоятельно выполнял эту работу и извещал вас в случае ухудшения ситуации.
Вам нужно дать своему проекту возможность заговорить. Например, с помощью электронной почты или мгновенного обмена сообщениями. Так вы сможете информировать разработчиков о последних ухудшениях или улучшениях показателей. Но еще более эффективно — материализовать проект в офисе посредством оконечного устройства обратной связи (extreme feedback device, XFD).
Идея XFD состоит в управлении физическим устройством — например лампой,
