Программирование - простая часть
Недавно у меня был опыт, когда я потратил полдня на реализацию определенной функции и изменил кучу вещей в кодовой базе. У меня был один тестовый пример, с которым я боролся, и я попросил разъяснений у своих коллег.
В этот момент я обнаружил, что большая часть логики была совершенно ненужной, потому что я сделал неправильные предположения, основанные на моей интерпретации функции.
Подайте грустную музыку.
Если бы я потратил время только на то, чтобы проверить свое понимание, я мог бы сэкономить пару часов работы.
Это предположение разработчиков, которое переходит в производство
Я вспомнил об этом инциденте во время выступления Альберто Брандолини на конференции Domain-Driven Design Europe 2020, когда он сказал:
«Это предположение разработчиков, которое идет в производство».
Это меня действительно поразило.
Как разработчики программного обеспечения, мы должны не только уметь программировать, но и иметь достаточно знаний в предметной области, чтобы правильно программировать. В конечном счете, именно наше понимание отражается в написанном нами коде.
Я буду первым, кто признает, что в некоторых случаях я только читал название задачи, которую я касался агрегата, вносил изменения и делал запрос на вытягивание. Это срабатывает иногда для мелких функций и сообщений об ошибках, но когда дело доходит до реализации более крупных функций, это вообще не работает.
Если вам повезет, во время запроса на вытягивание будут обнаружены неверные предположения. Если вам не повезет, он будет обнаружен во время проверки качества или, что еще хуже, во время проверки заявки.
Теперь дело не только в том, чтобы вернуться и исправить свое предположение, но и в создании нового тикета и нового запроса на перенос. Зря тратят время и, возможно, придется переписывать всю функцию.
Все из-за предположения, основанного на названии заявки, и обсуждения, проведенного месяц назад во время уточнения.
Хотя на самом деле чтение критериев приемлемости может во многом помочь избежать описанного выше сценария, владельцы продукта и заинтересованные стороны тоже люди. Все мы совершаем ошибки или думаем, что некоторые вещи очевидны. Критерии приемки могут быть неполными.
Поэтому, как разработчики программного обеспечения, мы должны помнить об этом и спрашивать всякий раз, когда мы рискуем выйти на неизведанную территорию, даже если она не кажется неизведанной.
Избегайте перепрыгивания через самый низкий забор
Очень легко сосредоточиться на техническом решении, потому что это то, что мы, как разработчики, знаем и понимаем.
Настроить архитектуру микросервисов со всеми прибамбасами - это круто. Вызывать все микросервисы, чтобы что-то сделать - не так уж и круто.
Таким образом, даже если решение представляет собой технический подвиг, произведение искусства последних и величайших технологий, оно может полностью не достичь цели.
Однажды я помогал проводить экзамен по курсу Python. Это был первый раз, когда экзамен был цифровым, и приложение к нему было действительно крутым. Это приложение имело встроенную оболочку, автоматическую оценку и было развернуто в кластере Kubernetes.
Это было красиво. До 400 студентов должны были войти в систему и использовать ее сразу.
Прошло 30 минут, прежде чем все студенты вошли в систему. Ответы не сохранялись, и были проблемы с сессиями. Это был кошмар. Система, которая должна была сэкономить нам время при выставлении оценок, в конечном итоге привела к тому, что оценки откладывались на несколько недель.
Сложность приложения делала его совершенно непредсказуемым при большой нагрузке и в конечном итоге приводила к тому, что оно не соответствовало главному требованию - сохранению экзамена и его выставлению оценок.
Если вы потратите время на то, чтобы убедиться, что вы действительно удовлетворяете потребности своего пользователя, это может означать разницу между успешным приложением и неудачным.
Заключение
Знание домена может звучать как работа владельца продукта или того, кто предъявляет требования.
Однако вы не кодовая обезьяна. Вы не используете требования и код возврата. Вы несете ответственность за то, чтобы код, который вы пишете, был настолько правильным, насколько это возможно.
Хотя у вас может никогда не быть такого уровня знаний, который будет у эксперта в предметной области, вы можете знать достаточно, чтобы выявлять неправильные предположения в запросах на вытягивание или иметь возможность принимать устойчивые инфраструктурные решения.
Итак, поговорите с экспертами в своей области, когда наткнетесь на что-то, что не имеет для вас смысла. Спросите, почему критерии приемки должны выполняться именно так. Кто знает, что вы найдете.
Помните, что разработка программного обеспечения - это гораздо больше, чем просто написание кода.
Спасибо за чтение!
