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

ДВЕ НЕДЕЛИ ДО СДАЧИ ПРОЕКТА

Уверяю вас, эти две недели были довольно паршивыми. Первые два дня пропали из-за многочасовых собраний по моему следующему проекту. (Это только подчеркивает, насколько мало времени осталось для работы.) В конечном итоге на работу у меня осталось 8 дней. В первую неделю я проработал 74 часа, а в следующую… Боже… Я даже не помню, это стерлось из моих синапсов. Наверное, к лучшему.

Я провел эти восемь дней за яростным программированием. Я пустил в ход все возможные средства, чтобы справиться со своей работой: копирование/вставку (AKA повторное использование кода), «волшебные числа» (чтобы избежать дублирующихся определений констант с их последующим – о ужас! – повторным вводом) – и НИКАКИХ модульных тестов! (Кому нужны проблемы в такое время, они только отобьют охоту работать!)

Код получился довольно скверным, и у меня не было времени на рефакторинг. Впрочем, при таких сроках он был весьма неплох – ведь код все равно писался «на выброс», верно? Что-то из этого кажется вам знакомым? Подождите, дальше будет еще интереснее.

Накладывая завершающие штрихи (прежде чем переходить к написанию серверного кода), я начал поглядывать на кодовую базу и думать, что все, возможно, не так уж плохо. Ведь приложение работает, в конце концов. Я выжил!

«Боб у нас работает совсем недавно, он был очень занят и не мог позвонить раньше. А теперь он говорит, что пользователи должны вводить адреса своей электронной почты для получения купонов. Он еще не видел приложения, но думает, что это отличная идея! Кроме того, нам понадобится система построения отчетов для получения введенных адресов с сервера. И если уж речь зашла о купонах, они должны иметь ограниченный срок действия, а срок действия мы должны задавать сами. Да, и еще…»

А теперь вернемся на шаг назад. Что мы знаем о хорошем коде? Хороший код должен быть расширяемым. Простым в сопровождении. Он должен легко модифицироваться. Он должен читаться, как проза. Так вот, мой код не был хорошим.

И еще одно. Если вы хотите повысить свою квалификацию как разработчика, всегда помните: заказчик постоянно увеличивает объем работы. Он всегда хочет добавить в приложение новые возможности. Он всегда хочет вносить изменения – НА ПОЗДНЕЙ СТАДИИ.

Вот простая формула успеха:

(количество руководителей)[10]

+ 2 * количество новых руководителей

+ количество детей у Боба

= ДНЕЙ, ДОБАВЛЯЕМЫХ В ПОСЛЕДНЮЮ МИНУТУ

Руководители – такие же люди, как мы. Они должны обеспечивать свои семьи (если Сатана разрешил им завести семью). Они хотят, чтобы приложение было успешным (время повышения!). Проблема в том, что все они хотят претендовать на свою долю успеха в проекте. После того как все будет сказано и сделано, они хотят указать на некоторую функцию или архитектурное решение, которое они бы могли назвать своей личной заслугой.

Но вернемся к нашему проекту. Мы добавили еще пару дней и реализовали ввод адресов электронной почты. А потом я упал в обморок от усталости.

Оглавление книги