97 этюдов для программистов. Опыт ведущих экспертов

Оценки, цели и обязательства не зависят друг от друга, но цели и обязательства должны основываться на надежных оценках. Как отмечает Стив Макконнелл,[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 int main() {

printf("Hello, World\n");

return 0;

}

Пусть ваш проект говорит сам за себя Дэниэл Линднер

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

Можно подключить средства статического анализа кода к серверу непрерывной интеграции и получать метрики кода. Эти метрики сообщают специфические характеристики вашего кода и их изменения во времени. Когда введены метрики кода, всегда имеется красная черта, которую нельзя пересекать. Допустим, что вначале у вас покрыто тестами 20 % кода, и вы не хотите, чтобы эта величина опускалась ниже 15 %. Непрерывная интеграция позволяет следить за всеми этими числами, но все равно вам придется регулярно проверять их значения. Было бы хорошо, если бы проект самостоятельно выполнял эту работу и извещал вас в случае ухудшения ситуации.