Сто тысяч за одну кнопку: почему небольшие доработки на сайтах могут стоить так дорого?
Представьте сценарий: веб-сайт вашей компании нуждается в небольшой коррекции. Вы обращаетесь к разработчику или IT-агенству, и встает вопрос: почему такое маленькое изменение обходится столь крупным ценником?
В мире разработки веб-сервисов эта ситуация не редкость. Компании часто сталкиваются с трудностями, когда хотят внести изменения в веб-сайт, разработанный другим исполнителем. В этой статье мы погрузимся в тонкости того, почем, казалось бы, небольшие изменения могут сопровождаться значительными затратами, и предоставим вам понимание для навигации по этой сложной области. Мы рассмотрим общие процессы, которые разворачиваются, когда на сцену выходит новый разработчик и трудности, которые могут возникнуть.
Начнем с азов, о которых немногие знают
Разработчики получают почасовую оплату. Оценивая задачи, они считают, сколько часов потратят на их выполнение, а не просто «на глаз» прикидывают, насколько им будет сложно. И как раз при расчете часов, начинают встречаться подводные камни. Далее – о них по очереди:
1. Знакомство с репозиторием
Вступление нового разработчика в проект начинается с важного этапа: знакомства с репозиторием. Декодирование логики, прослеживание зависимостей и раскрытие сложностей в кодовой базе – обязательный процесс перед началом работы, причем его временные затраты не зависят от масштаба запланированных изменений. Что бы вы не делали с проектом – изучить и разобрать придется весь код.
Удивительно, что иногда время, затраченное на понимание существующего кода, превышает время, отведенное на реальные изменения. А бывает даже так, что в процессе изучения кода разработчик обнаруживает необходимость поправить больше вещей, чем планировалось (что приводит к большим затратам).
Представьте, что вы купили новый навороченный smart TV. Он стоил дорого, потому что в нем много функций (и доступ в интернет, и стриминг-сервисы, и даже бабушке по скайпу можно позвонить). Но первые две недели вы, скорее всего, потратите, бессмысленно тыкая по всем кнопкам, пытаясь в нем разобраться. И если он совсем сложный, вы можете даже воскликнуть «за что я деньги плачу?», но как и со всем сложно-технологическим, сначала нужно немного навостриться, а потом с удовольствием пользоваться.
А если вы купили, скажем, новый навороченный и очень умный увлажнитель воздуха, то все может быть еще хуже. Первые полдня вы проведете в попытках понять, как он вообще включается.
И с программами все абсолютно также. «Включением» очень грубо можно назвать процесс инициализации.
Да, даже простой «запуск» программы (инициализация) локально добавляет сложности к ключевому этапу ознакомления. И его часто упускают из виду при оценке стоимости кажущихся незначительными изменений.
2. Взаимосвязь несвязанных элементов
За гранью первичного знакомства возникает сложная задача, вызванная взаимосвязью элементов в веб-сервисе. Сложность заключается в том, что изменение одного элемента может вызвать цепную реакцию по всей системе.
Почему? На сложных сайтах часто используют «шаблонные» компоненты. Это значит, что похожие элементы дизайна (одинаковые всплывающие окна, например) все контролируются единым файлом, чтобы сайт не перегружать.
Поэтому даже небольшое запланированное изменение (скажем, поменять на одном всплывающем окне кнопку «да» с красного на зелёный) может потребовать полного пересмотра всех окон, а значит всей логики кода сайта.
Это добавляет к сложности процесса и вносит ясность в то, почему видимо незначительные правки могут вызывать неожиданные трудности и увеличение времени и затрат.
Чистота и понятность кода
Даже самые опытные разработчики не всегда могут сразу понять код, написанный другими. И дело здесь не в навыках: программисты используют разные стили и подходы к написанию программ, как, своего рода, художники или писатели. Это разнообразие может непреднамеренно усложнить понимание кода для нового разработчика.
Однако не всегда дело в стиле: отсутствие рефакторинга и несоблюдение лучших практик написания кода предыдущим разработчиком может значительно снизить его читаемость.
Рефакторинг, по сути, предполагает реструктуризацию существующего кода для повышения удобочитаемости и эффективности без изменения его внешнего поведения. И раз поведение не меняется, в условиях сжатых сроков разработчик может им и не заняться. Заказчик-то не заметит:) Узнает об этом лишь новый разработчик, который и задерёт вам цену. Таким образом, отстаивание рефакторинга и соблюдение практик чистого кода становится не просто вопросом предпочтения, но и необходимостью. Это ускоряет и упрощает внесение дальнейших изменений в проект и, что немаловажно, облегчает процесс адаптации новых разработчиков в дальнейшем.
А если ваш сайт изначально был написан не очень «чисто», тут уже ничего не поделаешь. Новый разработчик будет очень стараться, и внесение изменений займет у него очень много часов.
3. Документация
Нехватка четкой документации – серьезное препятствие. Документация служит будущим разработчикам как навигационная карта, помогая им разобраться в тонкостях существующего кода. Однако, в большинстве случаев, проекты сдаются заказчику без подробной документации, что делает процесс ознакомления с кодом похожим на экспедицию в неизведанные территории без карты – сами попробуйте разобраться в заграничном городе, не зная, где там подземный переход, а где вход в метро:)
Отсутствие документации не только удлиняет процесс знакомства для новых разработчиков, но также повышает риск неправильного понимания. Без четкой документации разработчики вынуждены ориентироваться методом проб и ошибок, что приводит к потере эффективности в понимании функционала и назначения конкретных компонентов.
К счастью, не нужно быть разработчиком, чтобы проверить наличие документации: в любом веб-проекте она представлена файлом README.md. (это не какой-то сложный формат, просто все разработчики мира договорились, что будут именно так подписывать важные файлы) Важность подробной документации не переоценить, когда стремишься к беспрепятственному и гармоничному процессу разработки, и никогда не будет лишним добавить ее написание в список требований.
4. Плохие практики работы
Редко, но возникает уникальное препятствие: предыдущий разработчик (или компания) встраивает элементы, сопротивляющиеся поддержке другими разработчиками. Иногда – если хотят защитить интеллектуальную собственность (код), чаще - чтобы повысить лояльность клиента (чтобы кроме них никто не мог с работать с проектом, а вы платили только им еще много много раз). Это проявляется в двух случаях:
1. Использование внутренних закрытых библиотек и инструментов. Это сравнимо со строительством здания с нестандартными инструментами или применением секретных технологий — может быть удобно для первоначальных строителей, но сделает практически непосильной задачу для любого, кто попытается внести свои изменения.
2. Предоставление клиенту собранного кода. В веб-разработке, перед тем как написанный и понятный разработчикам код заработает, он проходит процесс сборки. Так, он становится понятным и выполняемым для компьютера, однако его результат разработчики прочесть уже не смогут. Отдельные разработчики могут грешить предоставлением клиенту исключительно собранного кода, оставляя читаемые исходники себе.
Что делать?
Чтобы не допустить такой ситуации:
- Требуйте документацию к проекту. Это включает подробную документацию по структуре кода, зависимостям и внешним интеграциям. Регулярные обновления гарантируют, что документация остается соответствующей эволюции кодовой базы.
- Закрепляйте в контракте условия доступа к коду. При взаимодействии с контрагентами важно установление условий, способствующих будущим модификациям и отказ от использования закрытых или собственных компонентов без тщательного обоснования.
…И если ситуация уже случилась:
В ситуациях, когда вызовы уже возникли из-за отсутствия превентивных мер, можно смягчить последствия и спасти ситуацию следующими способами:
- Аудит и Оценка Кода: Проведение независимых аудитов и оценок кода может раскрывать существующие трудности. Выявление областей, лишенных ясности, стандартизированных практик или полной документации, предоставляет информацию для дальнейшего исправления проекта.
- Постепенные Инициативы Рефакторинга: Вы можете систематически улучшать код, не нарушая работу всей системы. Работайте над выявленными сложностями кода, улучшайте документацию и внедряйте стандартизированные практики поэтапно для улучшения кодовой базы. Таким образом можно обеспечить гибкость и расширяемость проекта в будущем.
- Связь с предыдущими исполнителями: Если оказалось, что доступ к коду ограничен, отсутствует документация, или код в принципе нечитаемый, единственный выход – связь с предыдущими разработчиками. Часто потребуется обеспечить их коммуникацию напрямую с новыми исполнителями.
В постоянно изменяющемся мире разработки веб-сервисов путь от идеи к реализации усеян вызовами. Представленные в данной статье идеи проливают свет на сложности, которые могут возникнуть при попытке внести кажущиеся незначительные изменения в существующее программное обеспечение.
Приоритизация полной документации, стандартизированных практик кодирования и открытой коммуникации позволяет компаниям укрепить свои процессы разработки, создавая основу для более плавных сотрудничеств и будущих модификаций. Кроме того, при столкновении с текущими вызовами своевременные действия, такие как тщательные аудиты кода, постепенный рефакторинг и совместная передача знаний, могут подготовить почву для значимых улучшений.