В этой статье я поделюсь десятью уроками, которые я извлек из своего первого проекта в качестве разработчика программного обеспечения-самоучки. В то время я работал в консалтинговой компании, и мое официальное звание было инженером-программистом. Проект, над которым я работал, представлял собой веб-приложение для государственного сектора.
Урок no1: изучите архитектуру как можно скорее
Вначале самой сложной задачей было привыкнуть к тому количеству написанного кода. К тому времени, когда я начал, должно было быть не менее миллиона строк кода! Это стало намного проще после изучения архитектуры, которую мы использовали. Я помню, что в то время меня это смущало.
Только когда я прошел ускоренный курс по многоуровневой архитектуре, предложенный компанией, я действительно понял, как ориентироваться в кодовой базе. Когда я начал, у меня был очень краткий обзор, но я хотел бы получить лучшее понимание раньше, чем я.
Урок №2: не сокращайте путь к архитектуре
На полпути к проекту мы добавили много новых функций. Кое-что из этого мы смогли сделать с помощью новейших технологий. Поскольку я все еще не понимал ценности архитектуры, которую мы использовали, я решил сократить путь. Это привело к потере времени и ресурсов, когда нам пришлось вернуться и исправить это.
Урок # 3: не стоит недооценивать ценность бизнес-контекста
Важной частью проекта является изучение бизнес-требований. Я полностью недооценил важность этого на протяжении всего проекта. Это была дорогостоящая ошибка. Если вы не понимаете бизнес-контекст своей работы, очень легко пойти по неверному пути.
Урок 4: не стоит недооценивать ценность самоучки
Этот проект позволил мне обрести уверенность в своих способностях как разработчика. Я твердо верю, что если у вас есть подходящие инструменты, вы можете стать экспертом во всем.
Хотя я и не претендую на звание эксперта, моего материала для самообучения было более чем достаточно, чтобы подготовить меня к этому проекту. Имейте в виду - список был намного короче, когда я начинал! Это открытие вдохновило меня написать Стоило ли учиться того?
Урок 5: пишите быстрые тесты и удаляйте устаревшие
Наш проект состоял из множества тестов. У нас был автономный набор тестов, в котором выполнялись модульные тесты, тесты устойчивости и интеграционные тесты. Модульные тесты выполнялись за несколько минут, но все вместе заняли целый час! Я понял, что быстрые тесты лучше всего, и нет смысла держаться за устаревшие тесты.
Урок # 6: опасайтесь последствий, если совершаете реже
Мы использовали Subversion для контроля версий. К сожалению, код, который мы фиксировали, был автоматически зарегистрирован в репозитории. Мы очень редко работали с филиалами, поскольку альтернативные издержки казались слишком высокими. Это привело к тому, что код коммитился реже. Я все еще пытался часто коммитить, но иногда ломал сборку - я не думал, что мне нужно тратить час на выполнение тестов локально.
Урок №7: напишите надежные тесты - и не забывайте поддерживать их
Вдобавок некоторые тесты не всегда были зелеными. Иногда они работали, но так же часто терпели неудачу. Это приведет к тому, что сборка станет красной. В результате я не особо оценил ценность красного телосложения. Иногда сборка оставалась красной в течение нескольких дней, потому что кто-то не замечал, что другой тест был нарушен.
Урок # 8: проверьте код как можно скорее
Как правило, один разработчик пишет код, а другой проверяет код. У меня была возможность сделать и то, и другое. Часто мне доводилось разрабатывать функцию. Перед тем как закончить, мне дали бы что-нибудь на обзор. Может пройти несколько дней, прежде чем я займусь рецензированием.
Это часто вызывало головную боль, потому что код, который я просматривал, не совпадал с кодом, который был разработан. Парное программирование позволило бы избежать этой проблемы, но мы работали по-другому.
Урок # 9: рефакторинг должен сопровождаться тестами
Тесты были введены всего за пять лет существования проекта. До этого все испытания проводились вручную. Это означало, что большая часть кодовой базы не тестировалась, что опасно.
Лично мне очень нравится идея применения правила бойскаута в коде. Естественно, я был склонен к рефакторингу. Но поскольку у нас не было тестового покрытия для всего, что я реорганизовал, я иногда вносил дефекты в наше программное обеспечение.
Урок # 10: разработка программного обеспечения - это компромисс между ценностью для бизнеса и совершенством программного обеспечения
Мы использовали V-модель для процесса разработки программного обеспечения. Это включало крайние сроки разработки, ручного тестирования и выпуска программного обеспечения. У нас не было неограниченного времени на разработку или пересмотр кода, который мы писали. В некоторых случаях я тратил слишком много времени на совершенствование кода, что не всегда приносило пользу для бизнеса.
Последние мысли
Этот проект стал для меня очень ценным опытом обучения. Надеюсь, вы тоже кое-чему научились. Дайте мне знать в комментариях ниже, если у вас был аналогичный или противоположный опыт!
Перед тем, как уйти… Спасибо, что прочитали статью! Если вам понравилось, не забудьте выразить свою признательность, нажав 👏 ниже!
Я пишу о своем профессиональном и образовательном опыте в качестве разработчика программного обеспечения-самоучки, поэтому нажмите кнопку следовать, если вас это интересует! Вы также можете проверить мой блог или подписаться на мой информационный бюллетень для получения дополнительной информации.
