Персональный рост

Данный пост уже публиковался на ITBlogs. С того момента прошло немного времени — информация подверглась небольшому переосмыслению, потому предлагаю версию 1.1 — улучшенную и дополненную.

Как известно, у множества явлений существует два субъективных аспекта — положительный и отрицательный. Технологии дают большую свободу, но и накладывают дополнительные ограничения, причем последние — суть не технического взаимодействия, а человеческих отношений. Порой область исследования вызывает страшный когнитивный диссонанс, являющийся причиной многих категорических высказываний.

Неоднократно при доработке существующих систем слышен глас вопиющего в пустыне : «Надо все переделать!». Причин тому быть может много — неосознаваемая и непостигаемая сложность системы, низкое качество, сложность с внесением изменений, неадекватность решения, моральное устаревание, неэстетичность и непродуманность интерфейса… да мало ли причин можно обнаружить в нашем узеньком, но таком разросшемся мирке программных разработок.

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

1. Единая база кода. Разумеется, рано или поздно в определенных направлениях деятельности требуемые задачи теряют элемент новизны. Чувство «де жа вю» нарастает от проекта к проекту, так же растет и объем наработок и полезного кода. Разумеется, в идеале это приводит к почти полному и абсолютно предсказуемому результату для следующего проекта — достижению некого уровне мастерства. Если хранить весь наработанный код проектов, заведенный под систему контроля версий — это значительно упрощает последующий процесс разработки. Разумеется, мобильности ради, лучше поместить репозитарий на сервере, доступном через интернет.

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

3. Использование шаблонов проектирования. Игнорирование опыта большого числа разработчиков было бы, несомненно, не оправдано. Равно как и нельзя злоупотреблять приемами во избежания усложнения кода — нет смысла использовать итератор там, где подойдет простой цикл.

4. Избежание излишней универсальности. Порой слишком большое желание сделать инструмент на все времена гробит проекты из-за непомерного объема требуемого кода.

5. Разумное применение мета-информации и развязывание интерфейса и логики. Не стоит забывать, что разрабатываемый код предполагается в дальнейшем использовать повторно и модифицировать. Чем проще эта процедура будет, тем легче.

6. Пометки в системе управления версий. При каждом внесении нового кода (особенно в случае единой базы кода) очень удобно делать пометки, а что именно во вносимой дельте поменялось. Если используется система учета ошибок и пожеланий — достаточно ссылки на соответствующее сообщение в данной системе, чтобы не плодить описания повторно. Разумеется, в этом случае более эффективно использовать специализированное ПО, например trac — это позволяет быстро и достаточно эффективно реализовавть проекты с более чем одним разработчиком.

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

8. Соблюдение целостности. Понятно, что заводить под систему контроля версий бинарные файлы неэффективно: они и редко изменяются в рамках проекта, и занимают пространство, и формирование дельты или заплатки для них бессмыслено. Тем не менее, чем больше служебной информации о проекту будет в репозитарии — тем лучше. Вы можете сменить рабочую станцию, работать в другом городе или на ноутбуке и будет очень неприятно, когда не обнаружится пары предварительных макетов интерфейса, без которых в данный момент — ну прямо никак. Разумеется, в утрирование этого тезиса можно и все сопроводительную документацию (вплоть до деловых бумаг) заводить под СКВ — плохого в этом точно не будет. Дисковое пространство достаточно дешево, а вот если клиент после трех изменений захочет вернутся к исходному техническому заданию (которое благополучно почило в бозебыло стерто под весом изменений) — трудновато придется.

9. Предварительное проектирование от модели и от интерфейса. Про шаблоны проектирования я уже упоминал, но, понятное дело, само по себе проектирование времязатратное, а выход его черезвычайно мал. Причина тому — слишком большая зависимость от непосредственной реализации, потому как в процессе написания кода могут родится более аккуратные решения, нежели те, что закладывались на стадии проекта. Можно, конечно, долго спорить, что при грамотном подходе все будет «тип-топ», но я не знаю людей, способных оперировать современными иерархиями классов из сотен и тысяч наименований.

Тем не менее, проектирование необходимо. Хотя бы потому, что оно проясняет задачу и позволяет сформировать какое-никакое, а представление «куды бечь и чего нести». Потому я стараюсь проектировать с головы и хвоста, т.е. формировать модель данных и списки входных-выходных документов, дизайн пользовательского интерфейса и прототип операторских действий, а затем «скрещивать ужа с ежом». Причем эти два потока (UI и модель) должны идти параллельно, но взаимосвязано. Когда будет найден баланс между «накидать компонентов на формочку и связать с традиционными табличками» и «сделать оператору большую зеленую кнопку работы» — именно на этом стыке рождается хороший, по внутренним ощущениям, продукт. Как только наблюдается перекос в какую-либо сторону — это гарантированная головная боль при дальнейшей эксплуатации системы.

10. Умеренный академизм. Высшая школа дала очень много, в том числе и представление «как должно быть правильно, по науке». Нет смысла изобретать сортировку пузырьком в сотый раз, нет смысла пренебрегать конечными автоматами, нет смысла городить поведение а-ля десктоп-приложение в системе, изначально ориентированной на «запрос-ответ». Хоть лучшее и враг хорошего, но порой стоит пересиливать себя и переписывать плохие участки кода (но, разумеется не за пять минут до дедлайна).

Да, и еще, напоследок, самый главный тезис: Законы Мерфи еще никто не отменял! : )