Этот риторический вопрос возникает у многих программистов. Многие приходят к выводу, что программный код – это «только инструмент» для решения поставленной задачи. Главное результат, а как он, достигнут не столь важно.
Однако такой подход на самом деле поверхностный и во многом обусловлен не совсем правильным пониманием процесса разработки и роли кода в нём.
Более подробное изложение этого подхода можно прочесть в одной из статей на Хабрахабре.
Следует отметить, что отнюдь не всё в нём является результатом заблуждения.
Безусловно, рассказывать заказчику или менеджеру проекта о том, что написано столько-то строк кода, использованы такие-то паттерны и т.д. само по себе ничем не оправдано. Особенно, если заказчик далёк от программирования (в большинстве случаев так оно и есть). Взаимодействие в подобных ситуациях действительно лучше строить, как сказано в приведённой статье, «на уровне состояний готовности».
В тоже время необходимо чётко понимать, что программы пишутся для того чтобы решать проблемы пользователей, а не создавать им новые.
Для представителей инженерных отраслей уже давно не секрет, что наиболее критические и трудно исправимые ошибки ставшие причиной аварий те, что были допущены на стадиях проектирования и изготовления (строительства, монтажа и т.д.). Только эта, казалось бы, азбучная истина почему-то до сих пор не прижилась в сфере разработки программного обеспечения. А, ведь именно от того насколько совершенны применяемые архитектурные решения и методы реализации напрямую зависит качество конечного результата и зачастую сама скорость его достижения (частичная взаимосвязь описана в [2]).
Проблемы, которые провоцирует подход к процессу разработки по принципу «лишь бы работало» или «лишь бы работу приняли» не всегда проявляются сразу (как, например, превышение сроков выполнения проекта).
В процессе использования программы может возникнуть масса неприятных сюрпризов, причина которых некачественный код. Начиная с банальных «тормозов» и «зависаний» (речь идёт о проблемах вызванных именно программной частью) и заканчивая ошибками в работе программы вплоть до фатальных.
Сопровождение подобных проектов тоже не простая задача. В самом лучшем случае значительно возрастает сложность и трудоёмкость выполнения каких-либо доработок по проекту. В худшем случае проект придётся полностью переписывать заново.
Писать программы по принципу «лишь бы работало» в определённом смысле проще. Не требуется высокая квалификация, как программиста, так и менеджера проекта. Меньше затраты времени на проектирование и тестирование. Но, проще это ещё значит эффективнее.
Именно по этой причине эксперты (например [3]), а также большинство (если не все) производителей программного обеспечения мирового уровня и квалифицированных частных специалистов уделяют большое внимание качеству архитектуры и реализации.
Таким образом, даже если на сегодняшний день Ваш код действительно никому не интересен, то далеко не факт, что так будет продолжаться бесконечно долго.
Источники:
- Твой код никого не интересует. Dreyk. Хабрахабр.
- Управление программными проектами. Архипенков С.А., – М.:2009.
- Совершенный код. Мастер класс. Макконнелл С. – СПб.: Питер, 2005.
Добавить комментарий