В сентябре 1995 года я был новоиспеченным разработчиком. У меня было некоторое формальное образование в области компьютерных наук и степень магистра инженерии, но не было степени CS. К счастью, меня окружали очень опытные коллеги. Это была позитивная и воодушевляющая среда, и, поскольку я быстро смог сделать себя полезным, я получил много наставничества. В течение следующих 12 месяцев мой опыт вырос до такой степени, что я чувствовал себя комфортно и уверенно профессионально программируя на C++.

По мере того, как я приобретал опыт работы с методами и инструментами программирования, мое внимание начало меняться. Работа стала меньше о том, КАК заставить машину делать то, что мне нужно, и больше о том, ЧТО попросить ее сделать. Я начал брать на себя более крупные задачи и предлагать новые проекты по собственной инициативе. Я начал выходить за рамки своей начального уровня «кодирования», научившись разрабатывать программное обеспечение. Это был мой первый шаг к работе над программным обеспечением на более высоком уровне; процесс, который продолжается и по сей день!

В этом посте я попытаюсь описать, как я развил навыки проектирования программного обеспечения, которые позволили мне перейти от младшего разработчика к старшему разработчику, техническому руководителю и, в конечном счете, к предпринимателю программного обеспечения и техническому директору @ AppLand. Надеюсь, вы найдете в этом посте несколько советов, которые помогут вам сделать это, потому что проектирование программного обеспечения — сложная задача. Это сложнее, чем кодирование, потому что ошибки в дизайне исправить гораздо сложнее, чем проблемы с низкоуровневым кодированием. Помочь всем улучшить дизайн программного обеспечения стало моей миссией. (Внизу этой статьи вы можете немного прочитать об AppMaps, инструменте, который я разработал, чтобы помочь разработчикам создавать отличные проекты программного обеспечения).

Вот краткий обзор остальной части этой статьи:

  1. Овладейте основами — только после того, как тактические аспекты кодирования станут автоматическими, вы сможете начать мыслить стратегически.
  2. Понять, почему дизайн имеет значение — получить интуитивное представление о положительном и отрицательном влиянии дизайна.
  3. Разработайте и усовершенствуйте свой личный процесс — научитесь бессознательно и оптимально распределять свое время между проектированием, реализацией и тестированием.
  4. Всегда быть в доставке — данный дизайн оптимален только для одного набора обстоятельств; и обстоятельства всегда меняются. Так что отправляйте код и всегда двигайтесь вперед.

Теперь давайте начнем.

Овладейте основами

Подобно художнику, разработчик программного обеспечения должен начать с овладения набором фундаментальных навыков. Основы имеют решающее значение, потому что мы не можем эффективно сосредоточиться на дизайне, пока механика кодирования не станет автоматической. Как и художнику, вам нужно, чтобы механика вашего ремесла была второй натурой, чтобы ваш разум был свободен для творчества более высокого уровня.

У меня была ключевая стратегия для овладения основами: никогда не позволяйте ничему оставаться загадкой. Вы когда-нибудь слышали, как кто-то говорит, что ошибка возникает «случайно»? Или начать менять код наугад в надежде решить проблему? Нет. Компьютер — это детерминированная машина. Код более высокого уровня компилируется в байтовый код. Байт-код выполняется как машинный код. Сообщения отправляются по сети и могут быть проверены. Ошибка, которую вы исследуете, находится где-то в вашем коде (или зависимости), и вы можете ее найти. Покопайтесь, разберите проблему, подходите к ней с разных сторон, спрашивайте совета у более опытных людей, пока компьютер не выдаст секреты.

Поймите, почему дизайн важен

Почему важен хороший дизайн? Создание дизайна стоит денег, поэтому хороший дизайн должен быть оправдан. Важно развить четкое понимание этого вопроса, который является личным и основанным на опыте.

Сейчас в AppLand мы проводим опрос качества архитектуры программного обеспечения. В ходе опроса мы спрашиваем старших разработчиков: С каким компромиссом сегодня сталкивается ваша организация? (по сравнению с доставлять быстрее). Вот ответы, а также доля экспертов, выбравших каждый ответ:

  • Общее качество [42%]
  • Ремонтопригодность [33%]
  • Производительность [13%]
  • Безопасность [8%]
  • Надежность (ошибки) [4%]

Эти старшие специалисты знают, что когда кодовая база теряет присущее ей качество и ремонтопригодность, все другие соображения (возможности, удобство использования, стабильность, производительность, безопасность и т. д.) становятся спорными. Если кодовая база не поддается сопровождению и имеет принципиально низкое качество, то становится невозможным какое-либо продвижение кодовой базы вперед. И когда базу кода нельзя улучшить или усовершенствовать, это очень плохие новости для команды разработчиков и для всех остальных. Качество и ремонтопригодность определяются хорошим дизайном программного обеспечения. Дизайн имеет значение; спросите Ситибанк.

Разработайте и усовершенствуйте свой личный процесс

Как только вы усвоите важность хорошего дизайна программного обеспечения, важно выработать личные рабочие привычки, соответствующие вашим ценностям. Таким образом, вы с большей вероятностью добьетесь желаемых результатов. Вот как эти привычки развились у меня.

Когда мне было около двух лет в моей карьере, моя компания наняла эксперта по Персональному программному процессу (PSP). Этот эксперт (привет, Стив!) научил использовать оценивать нашу собственную эффективность, тщательно отслеживая время, которое мы тратили на три этапа: проектирование, внедрение и тестирование. В PSP эти этапы происходят последовательно, и как только вы перейдете к следующему этапу, вы не сможете вернуться назад. Таким образом, если во время тестирования вы обнаружите ошибку, которая была привнесена в дизайн (скажем, из-за неверного предположения о проблеме), то все время, необходимое для доработки этого дизайна и исправления ошибки, засчитывается как время тестирования. Уроки становятся понятными довольно быстро:

  1. Чем раньше в процессе появляется ошибка, тем больше времени уходит на ее исправление.
  2. Если вы тратите недостаточно времени на фазу, чтобы «поторопить» работу и выполнить ее быстрее, вы почти всегда потратите в два раза больше времени на поиск правильного решения, чем если бы вы были более обдуманными.

Изначально я тратил около 15% своего времени на дизайн. В результате мне пришлось потратить много дополнительного времени на реализацию и тестирование, чтобы исправить свои ошибки в дизайне. Поэтому я увеличил свою приверженность дизайну и увеличил выделение времени на «дизайн» до 30–40%. Результат? Я закончил проекты в два раза быстрее, И с лучшим дизайном (и меньше разочарований).

Отслеживая свое время и честно оценивая данные, я развил «шестое чувство», чтобы знать, когда мой дизайн будет готов для начала кодирования. Я считаю, что любой может развить эту интуицию, если он потратит время на изучение себя и того, как дизайн, реализация и тестирование взаимодействуют и влияют как на скорость, так и на качество. Пилоты говорят: «Медленно — значит плавно, плавно — значит быстро». Спешка приводит к ошибкам, а исправление ошибки занимает намного больше времени, чем правильное ее решение в первый раз (и это при условии, что вы не дымящаяся дыра в земле).

Всегда быть доставкой

Шокирующая правда о дизайне программного обеспечения может быть неочевидной поначалу: совершенство недостижимо! И это не потому, что мы недостаточно умны, чтобы создать идеальный дизайн, или что ваш босс никогда не уделяет вам достаточно времени. Я имею в виду, что дизайн никогда не может быть идеальным, потому что требования постоянно меняются. Вы кодируете продукт для рынка. Потребности клиентов меняются вместе с миром. Технические стеки меняются, облачные технологии развиваются, пишутся библиотеки с открытым исходным кодом, которые решают конкретную проблему лучше, чем ваш код. Как только вы создаете идеальное решение, оно становится несовершенным из-за изменяющихся условий.

Не пытайтесь решить эту проблему, сделав свой дизайн «заточенным на будущее» с помощью сложных удлинителей и настраиваемости. Примите это и поймите, что ни один дизайн не является окончательным. Сосредоточьтесь на том, чтобы ваш дизайн был простым для понимания и рефакторинга. Истинная отличительная черта отличного дизайна программного обеспечения — простота.

Помните, что неподдерживаемый код — это самый большой страх техлида. Жесткая, негибкая конструкция — враг ремонтопригодности, какой бы «идеальной» она ни была 1, 5, 10 лет назад.

Заворачивать

Это четыре метода, которые я использовал, чтобы улучшить свои навыки проектирования программного обеспечения. Я надеюсь, что вы найдете их полезными! Спасибо за уделенное время.

Об AppMaps — инструменте разработчика для создания отличных проектов программного обеспечения

Как вы можете видеть из этой статьи, я увлечен дизайном программного обеспечения. Чтобы помочь разработчикам создавать отличные проекты программного обеспечения, наша команда в AppLand создала AppMap для VSCode. AppMap — это инструмент, который создает точные диаграммы проектирования программного обеспечения, автоматически рисуемые в вашей среде IDE. Это бесплатное приложение с открытым исходным кодом для Ruby, Java и Python.

Опрос качества архитектуры

Чтобы принять участие в опросе, о котором я упоминал в этой статье, посетите Опрос качества архитектуры программного обеспечения.

Первоначально опубликовано на https://dev.to 22 февраля 2021 г.