Много в этом мире сказано, что код надо писать так, чтобы его было легко поддерживать любому другому разработчику, и чтобы проект мог быть передан на поддержку другим людям в любой момент. Но каково это – передавать проект, с которым прожил несколько лет, в совсем другие руки? Кем окажется для проекта его новый руководитель – вторым отцом или злым отчимом (уважаемые читательницы, я помню о вашем существовании, но вы в меньшинстве)? Будет наше детище развиваться и набирать сил, или умрёт, уступив место чему-нибудь куда менее красивому, явно не столь качественному (мы-то понимаем, кто здесь самый крутой профессионал) и совсем чужому? Для тех, кого действительно волнует его будущее, и написана данная статья. Замечу, что в ABBYY я проработал в нескольких проектах, оставлял их по разным причинам, большинство из проектов – задачи без чёткого решения (распознавание, поиск разных неформально описанных объектов и т.п.).
Итак, что нужно делать, чтобы можно было оставить проект в любой момент, не опасаясь за его будущее. Помимо высококачественного кода, понятных интерфейсов и исчерпывающей документации (хотя бы в виде комментариев к коду) совершенно необходима система тестирования. Причём такая, которая может сама измерять качество и быстродействие вашего проекта, выдавая недвусмысленный ответ, какая из двух версий лучше. Если такая система возможна – очень хорошо, создайте её. Если нет, подумайте, как можно приблизиться к данному решению. Какая-то система тестирования вам будет совершенно необходима для разработки, но если вы заставите её давать однозначные ответы, типа стало лучше или стало хуже, вы сможете избежать порчи вашего проекта, с такими фразами как «по моим ощущениям стало лучше», показав истинную цену этим «ощущениям».
Система тестирования должна быть понятна и расширяема. Если возможно, пишите юнит-тесты, если затруднительно – делайте общие тесты проекта на конкретных примерах. Если есть простые тесты на исполнение, которые можно либо пройти, либо не пройти, это хорошо. В случаях, когда можно померить, насколько хороша ваша программа, обязательно надо делать сравнительное тестирование двух версий. Причём хорошо бы, чтобы эти тесты были устроены так – мы запускаем программу, она оставляет лог своей работы, а сравнивая два лога легко понять, какая из двух версий программы лучше на каждом из тестовых примеров. Если оценки получились аддитивными – отлично, у вас ещё есть и результат на группе примеров. Если не получились, подумайте, как сделать эти оценки аддитивными.
Скажем, если вы ищете штрихкоды на изображении, вам нужна куча изображений, на которых штрихкоды есть, и ещё одна куча, на которых штрихкодов нет. Тестик должен показывать, сколько штрихкодов (ну, точнее, объектов, проинтерпретированных как штрихкод) в каждой из куч найдено и сколько времени на это было потрачено. Это простейший минимальный тест, если проектом заниматься всерьёз, то надо ещё и пометить все изображения, указав какой штрихкод и где именно вы ожидаете найти. Ещё раз повторю: сама система тестов нужна вам на время разработки, а вот понятность и недвусмысленность её ответа потребуется, в первую очередь, вашему преемнику.
Ещё важный момент – мелкие недостатки. Когда вам кажется, что вы будете заниматься проектом достаточно долго, есть соблазн не писать баг-репорты по поводу разной мелочи, а поправить, как только руки дойдут… Даже если у вас феноменальная память и руки всегда доходят до нужных вещей, всё равно надо писать баг-репорты. Потому что как раз знания о мелких недостатках теряются при передаче дел и появляются в форумах фразы пользователей, что «эти бездельники уже несколько версий не могут поправить такую простую ошибку».
Всегда оставляйте в коде комментарии о неудачных попытках сделать что либо. Смело пишите: здесь я тогда-то попытался применить алгоритм Данцига, но данный способ обхода в среднем оказался более эффективным, особенно на примере таком-то. Пока мы занимаемся проектом сами, мы помним о наших неудачах их причинах, но откуда о них узнают новые хозяева проекта? То же касается структур данных. Если есть несколько вариантов представления ваших данных, смело опишите, по какой причине вы выбрали именно этот – возможно, ваш преемник задумается, следует ли здесь что-то менять.
Никогда, я подчёркиваю, никогда не пишите в вашем коде тех слов, которые произносит маркетинг, убеждая клиентов купить новую версию. Не «более удобный интерфейс», а «интерфейс в виде таблиц», не «улучшенный внешний вид», а «цвета, более близкие к оригиналу». Тем более, ни в коем случае не объединяйте в единый интерфейс функции, которые связаны между собой только тем, что так было удобно их продавать. Помните, что когда клиент, которому это продали, уйдёт довольным, ваше преемник смело выкинет весь этот интерфейс и всё с ним связанное из кода, не подумав, насколько ценно то, что он выкидывает.
Итак, вы покидаете проект…
Кто ваш преемник? Если лучший программист из вашей команды, ничего уже не бойтесь. Это – наилучший возможный сценарий развития событий. Лучший не только для проекта, но и для вас. Вы сделали всё, что могли, преемник точно справится, кто, если не он, может доделать то, что вы не успели. От вас требуется только написать документ со своими идеями, которые вы собирались воплотить в ближайшие год-два и передать новому лидеру. Скорее всего, ваши мысли совпадут – не зря вы столько лет проработали бок о бок. Написав документ, передавайте преемнику и уходите. Не забывайте только потом радоваться успеху проекта без вас: помните, что это именно вы дали ему толчок к развитию в нужном направлении.
Если вышло, что ваш преемник вовсе не тот, с которым вы научились понимать друг друга с полуслова, а человек «извне», со своими (ясное дело неправильными) представлениями о мире, дело несколько хуже. Несомненно, документ с описанием идей и направлений развития нужен, но для начала нужно подвести вашего преемника к этим идеям. Итак, что действительно нужно:
- Документировать всю функциональность. Всю, до мелочей. Не ограничиваясь общими словами, написать список того, что умеет ваша программа. И сделать это так, чтобы ни у кого не возникало сомнений по поводу того, что ваше изделие действительно умеет то, что оно умеет. И написать его несколько раз: в папочке с документацией, в письме о передаче дел, в комментариях к главному хедеру.
- Честно написать, что ваше изделие умеет хорошо, а что не очень. На каких примерах работает безупречно, на каких требуется доводка. Что из этого является проблемой (с вашей точки зрения).
- Объяснить все архитектурные решения. Почему вы разработали архитектуру так, а не иначе, какое развитие проекта вы предполагали.
- Сохранить в общедоступном месте все ваши тестовые базы. Продемонстрировать преемнику, как работает ваша система тестов и как она оценивает результаты работы.
- Написать документацию к самому коду… Но если вы это без меня не знаете (что маловероятно), вас всё равно заставят сделать.
После того как вы сделаете всё это, а также те вещи, что попросит преемник, можно говорить проекту «до свидания». Придётся смириться с мыслью, что не вы теперь его хозяин. Но если вы хорошо позаботитесь о передаче дел, вам, вероятно, не придётся наблюдать бессмысленное разрушение с лозунгами о новом порядке.
Дмитрий Дерягин,
Департамент разработки технологий
Автор: 57DeD
