Учимся на ошибках других.
Провал программного проекта означает, что разработанный продукт значительно отличается от ожиданий заказчика. Могут быть разные причины неудач программных проектов: нечеткие требования, плохо налаженные процессы разработки программного обеспечения, неэффективный бюджет, который может привести к отсутствию контроля качества, DevOpses, бизнес-аналитики и т. Д.
Еще одна распространенная причина неудач программных проектов заключается в том, что группа разработчиков не может справиться с технической сложностью, которая возрастает с каждой новой функцией. Проекты с неограниченным бюджетом, гениальные владельцы продуктов и бизнес-аналитики по-прежнему терпят неудачу или близки к провалу, потому что команда разработчиков допустила следующие ошибки:
Игнорирование нефункциональных требований
Как известно, разработчики не должны приступать к реализации функциональности до тех пор, пока не будут ясны функциональные требования. Переход к программированию с частично определенными требованиями может вынудить разработчиков даже полностью переписать код после обнаружения недостающих требований.
Отсутствие нефункциональных требований перед разработкой и кодированием может привести к той же проблеме, что и отсутствие функциональных требований. Наиболее частым нефункциональным требованием является производительность. Различные цели производительности могут потребовать от разработчиков использования совершенно разных структур данных, шаблонов, схемы базы данных, алгоритмов или даже оборудования.
Полностью нормализованная схема базы данных - хороший выбор, когда разработчик не думает о производительности. Однако, чтобы ускорить приложение, которое считывает данные из нормализованной базы данных, разработчику может потребоваться найти баланс между нормализацией и денормализацией.
Если разработчик реализовал какой-то API без требований к производительности и его выполнение занимает 1 секунду, ему или ей может потребоваться полностью переписать логику после того, как заказчики скажут, что желаемая производительность должна составлять 300 миллисекунд в худшем случае.
Заказчики, не являющиеся техническими специалистами, обычно не думают о требованиях к производительности, пока не получат медленное приложение. Если в критериях приемки отсутствуют требования к производительности, вы можете сообщить об этом техническому руководителю, архитектору или заказчику. Это пример цели производительности:
API должен возвращать ответ в течение 500 миллисекунд при 1000 одновременных пользователях в 95% случаев.
Это требование позволит разработчикам выбирать подходы, которые обеспечивают достижение цели производительности с первой попытки, а не после того, как клиенты пожалуются на медленное приложение в производственной среде.
Разработка одноразовых компонентов
Скорость разработки программного обеспечения зависит от многих факторов: четко определенных требований, зрелости команды, отлаженного процесса разработки и других. Еще один важный аспект, который может существенно повлиять на скорость разработки, - это возможность повторно использовать существующий код.
Одна из ключевых обязанностей разработчиков - проектировать и реализовывать программные компоненты, которые являются методами, классами, библиотеками или микросервисами. Эти компоненты являются строительными блоками программного приложения. Необходимость повторно использовать существующие компоненты, как правило, возникает довольно часто при разработке новых функций, потому что это просто экономит время.
Программный компонент можно использовать повторно, если он соответствует принципам единоличной ответственности и слабой связи. Если программный компонент нарушает любой из этих принципов, его будет нелегко использовать повторно. Об этом я уже писал в другой статье:
Представьте, что метод сочетает в себе две обязанности, но вам нужно повторно использовать только одну из них. Какие у вас есть варианты?
Первый вариант - разделить метод на два метода и повторно использовать один из них. Второй вариант - скопировать и вставить ответственность в новый метод и использовать его. К сожалению, разработчики не всегда выбирают первый вариант, опасаясь сломать существующий код, поэтому они выбирают «более безопасный» подход - копирование и вставка. Однако в долгосрочной перспективе подход копирования и вставки - всегда плохой выбор, потому что он приводит к техническому долгу.
В следующем примереOrderServiceclass тесно связан с Databaseclass:
Когда класс тесно связан с другой зависимостью, невозможно повторно использовать этот компонент без повторного использования зависимости. Повторное использование логики создания отчета возможно только для клиентов, которым также необходимо сохранить отчет в базе данных. Но что, если отчет необходимо создать для отправки по электронной почте? Опять же, разработчику предоставляется два варианта: рефакторинг или копирование и вставка.
Помните об этих двух правилах при разработке собственных компонентов. Если вы сталкиваетесь с компонентами, которые нельзя использовать повторно, рефакторинг должен быть единственным доступным для вас вариантом.
Написание // Комментарии к TODO
Существуют различные причины технического долга: отсутствие модульных тестов, давление со стороны бизнеса, отсутствие взаимодействия между товарищами по команде, отсутствие документации, отсутствие контроля соответствия или даже некомпетентность разработчиков. Дело в том, что у каждого сложного программного проекта есть технический долг. Если заинтересованные стороны говорят, что у проекта нет технического долга, это редко бывает правдой. Скорее всего, в проекте есть неявный технический долг, потому что разработчики его не отслеживают.
Часто разработчики предпочитают размещать рабочие элементы вместе с плохо написанным кодом в надежде, что он не будет забыт.
Фактически, такие временные комментарии становятся постоянными, и никто не заботится о них, пока они не вызовут ошибку в приложении. Исходный код вообще не должен содержать таких рабочих элементов. Разработчик должен создать тикет технического долга в системе отслеживания ошибок вместо того, чтобы помещать комментарии // TODO в исходный код. Это позволит тикетам по техническому долгу пройти стандартный процесс оценки, определения приоритетов и планирования, как это делают разработчики для пользовательских историй.
Не отслеживая технический долг, разработчики рискуют потерять контроль над проектом и провалить его.
Последние мысли
Совершать ошибки - это нормально. Просто учитесь на собственных ошибках. Учитесь на ошибках других людей. Это сделает вас и ваши проекты успешными.
Спасибо за чтение!
