Откройте для себя передовые методы разработки программного обеспечения и изучите модель мышления, которая поможет раскрыть весь потенциал вашей команды разработчиков программного обеспечения.
Лучшие практики разработки программного обеспечения: модель мышления
Начнем с нескольких простых истин. Во-первых: разработка программного обеспечения — это сложно. Во-вторых: разработка программного обеспечения — это также форма искусства, которая часто заканчивается тем, что кажется, что миссия одного человека. И хотя самостоятельные действия часто кажутся «более простым» способом решения проблемы в кодировании, это не всегда «лучший» способ, особенно с течением времени.
Привет. Меня зовут Шань Хуанг, я основатель и генеральный директор Forma Cloud. На протяжении всей своей карьеры я был глубоко вовлечен в разработку программного обеспечения. С первых дней работы в качестве индивидуального участника до более поздних ролей менеджера и исполнительного директора, ответственного за руководство крупными командами и инициативами, я видел процесс разработки программного обеспечения со всех сторон. Я использовал этот опыт для создания Модели мышления инженера-программиста (или SEMM). SEMM превращает очень грязную операцию в нечто организованное, упорядоченное и эффективное. Модель мышления состоит из лучших практик разработки программного обеспечения, которые гарантируют, что наша кодовая база может быть наилучшей не только сейчас, но и в долгосрочной перспективе.
С момента создания Forma Cloud использует SEMM. Наше руководство и наши инженеры-программисты внедрили SEMM, и наши результаты говорят сами за себя. Может показаться, что жесткая модель разработки программного обеспечения означает более медленный процесс разработки, но на самом деле все наоборот. Использование SEMM в Forma Cloud привело к более понятной кодовой базе и, что самое главное, к гораздо меньшему количеству ошибок. В совокупности это привело к значительной экономии времени в наших проектах по разработке программного обеспечения.
В этой статье я хотел бы поделиться с вами своей моделью мышления в области разработки программного обеспечения. Однако прежде чем я углублюсь в детали SEMM, давайте обсудим некоторые проблемы, с которыми могут столкнуться группы программистов при работе в рамках «старой» модели разработки программного обеспечения.
Программная инженерия — это не только решение сегодняшних проблем
Одна вещь, которая обрекает многих программистов, — это необходимость двигаться быстро. Очень легко впасть в краткосрочное мышление. Предоставленный самому себе, процесс разработки программного обеспечения часто заканчивается чем-то вроде:
- Определите проблему.
- Решите эту проблему.
- Перейдите к следующей проблеме и повторите.
Это, несомненно, очень удобный способ сделать это — в конце концов, вы решаете проблемы и регистрируете строки кода. Проблема в том, что если эти проблемы решаются изолированно, они могут быть лишь частичным решением. Это особенно верно в отношении больших и/или запутанных кодовых баз — вы можете думать, что решаете проблему, но это не так. «проблема» могла существовать только потому, что логически она должна была существовать для решения какой-то другой проблемы.
Вот пример, иллюстрирующий это.
Поучительная история разработчиков программного обеспечения: когда случайный таймер сна на самом деле не случайный
ПРИМЕЧАНИЕ. Ниже приведена реальная история, основанная на моих собственных предыдущих наблюдениях в отрасли. Некоторые детали были опущены или упрощены в целях анонимности.
Несколько лет назад компания X запустила программу, которая управляла данными клиентов на основе числового идентификатора пользователя и личного PIN-кода. Однажды инженер-программист просматривал кодовую базу, пытаясь повысить эффективность продукта, и заметил, что там была строчка, которая просто заставляла программу засыпать на одну секунду. Каждый раз, когда обрабатывались идентификатор пользователя и PIN-код, вся серверная часть засыпала. Объясняющих это комментариев не было, да и инженеру это не представляло никакого рационального смысла. Инженер предположил, что это осталось от устранения неполадок при разработке и больше не нужно. Итак, следуя описанной выше трехэтапной модели (найти проблему, устранить проблему, повторить), инженер удалил строку, из-за которой программа засыпала. Никаких других проблем, казалось, не возникало, поэтому инженер пошел дальше.
Вот в чем проблема: у этой одной секунды сна действительно была цель. Когда была создана комбинация идентификатора и PIN-кода, в качестве переменной использовалось время эпохи, чтобы помочь в рандомизации. Спящий режим был установлен, чтобы гарантировать, что ни одна комбинация идентификатора пользователя и PIN-кода не будет создана в то же время эпохи, что и любая другая. Удалив строку, которая переводила серверную часть в спящий режим, инженер непреднамеренно создал ситуацию, когда PIN-коды можно было угадать для последовательных идентификаторов пользователей. И, к несчастью для компании X, эта проблема была настолько тонкой, что им потребовалось много времени, чтобы заметить, что это происходит. К сожалению, хакеры сообразили это гораздо быстрее. В конечном итоге это дорого обошлось компании X как в финансовом, так и в репутационном плане.
Эта проблема возникла из-за того, что в компании X не было программы разработки программного обеспечения, которая обеспечивала бы совместную работу всех сотрудников. И хотя эта ситуация может быть уникальной для компании X, отсутствие строгости в разработке программного обеспечения слишком распространено. Именно поэтому я разработал строгую модель мышления, которой следуют все наши инженеры — никто здесь не хочет, чтобы Forma Cloud быть как компания Х.
Раскрытие потенциала и ускорение роста команды с помощью модели мышления инженера-программиста
Что такое модель мышления в области разработки программного обеспечения и почему она важна
Вместо неформальной 3-шаговой модели, о которой мы говорили выше, Forma Cloud использует мою формализованную 10-шаговую модель мышления для разработки программного обеспечения. Вот шаги:
- Понять и подтвердить как проблему, так и решение
- Создайте проектный документ с требованиями и планом возврата
- Обсуждение и утверждение с командой
- На самом деле программировать (в среде разработки)
- Внутренняя демонстрация и утверждения
- Разработать функции обслуживания (конфигурации, оповещения, показатели)
- Создать или изменить документацию
- Подписание собрания и продвижение кода в рабочую среду
- Объявлять и запрашивать кредит
- Определите любые долгосрочные задачи или задачи следующего шага
Несмотря на то, что существует порядок SEMM, это не обязательно должен быть исключительно нисходящий подход, когда каждый шаг должен выполняться в каждой задаче программирования. Сотрудники Forma Cloud понимают, что все эти аспекты важны для рассмотрения, но в зависимости от решаемой проблемы они могут пропустить шаги (или вернуться к предыдущим шагам) по мере необходимости. Хотя все эти шаги важны, они не так трудоемки, как кажутся.
Что делает SEMM, так это настраивает разработчиков программного обеспечения преднамеренно продвигаться по проектам как команда, а не как отдельные лица, которые не знают, что делают другие участники. Инженеры и менеджеры свободно владеют SEMM, поэтому они могут говорить на одном языке в отношении работы, которую выполняют инженеры. Это позволяет инженерам иметь гибкость в том, над чем они работают, и дает менеджерам уверенность в том, что те же самые инженеры понимают, что, с точки зрения Forma Cloud, является кодом хорошего качества. Это позволяет команде гибко понимать, что является идеальным, и гибко подстраиваться под реальность.
Внедрение модели мышления в области разработки программного обеспечения
Давайте рассмотрим различные разделы SEMM более подробно.
Многие программисты рассматривают кодирование исключительно как работу четвертого шага — в конце концов, сесть и написать код — это самое интересное. Но подумайте о проблеме в компании X, когда мы будем выполнять эти шаги. Если бы компания X была так же осторожна, как Forma Cloud, у них никогда бы не возникло этой проблемы в продакшене.
Первые 3 шага (понимание, разработка и обсуждение решения) связаны с коммуникацией. Если программист идентифицирует проблему (или ему поручают ее решить), его первым шагом будет точное подтверждение того, что это за проблема, и описание того, как он собирается ее решить. Это очень соответствует старому менталитету деревообработки «сем раз отмерь, один раз отрежь» — мы говорим о проблеме и масштабах ее решения, прежде чем кто-либо возьмется за клавиатуру. Это имеет два преимущества. Во-первых, это гарантирует, что мы не исправим что-то непреднамеренно, чтобы не сломать что-то другое. Во-вторых, другие члены команды могли решить подобные проблемы раньше и иметь новый подход, который может решить проблему быстрее. Если бы компания X предприняла только эти три шага, у них никогда бы не возникло такой проблемы.
Шаги 4–8 (написание кода, тестирование/мониторинг, документирование и продвижение) — это более длительный способ выполнения нашего предыдущего трехэтапного процесса. Мы создаем код в изолированной среде и наблюдаем за изменениями. Мы делимся своей работой и позволяем другим пытаться найти проблемы. Только после полного раунда согласований что-либо продвигается в производство.
Шаг 9 (требование кредита) важен, и его часто упускают из виду. Большая часть этого процесса разработки программного обеспечения связана с общением, поэтому этот шаг помогает донести изменения до всех в компании, а не только до разработчиков программного обеспечения. Но этот шаг также означает признание тяжелой работы. Когда код передается в производство, мы делимся этой информацией со всей компанией и отдаем должное там, где это необходимо.
На последнем этапе (определение длинного хвоста/следующих шагов) мы смотрим в будущее. Когда проблема решена, нам еще есть над чем работать. В больших и сложных программах и кодовых базах изменения обязательно носят инкрементальный характер. Итак, десятый шаг позволяет нам посмотреть, что должно произойти дальше. Это могут быть этапы очистки или момент в процессе, когда мы снова начинаем работу над следующей функцией.
Заключение
В Forma Cloud мы гордимся нашей разработкой программного обеспечения. Я разработал SEMM, чтобы максимально расширить возможности нашей команды по созданию отличных продуктов, и был рад видеть, что это так успешно. Для этого необходимы эффективная командная работа и общение. SEMM гарантирует, что каждый четко понимает свои роли и обязанности, а также роли всех остальных. Командная работа, документация и строгое соблюдение правил комментирования помогают понять код, который мы пишем, как сейчас, так и в будущем. Опора на сотрудничество также помогает нам устранять задержки, доработки и, самое главное, ошибки. Члены команды поддерживают друг друга и дают ценную информацию и указания по всем аспектам наших продуктов.
Forma Cloud поможет вам сэкономить на облачных расходах. Наша опытная команда инженеров AWS и специалистов по управлению затратами отслеживает ваши расходы, чтобы вы могли понять и сократить их. Мы работаем на основе быстрой и эффективной модели SlackOps, поэтому мы можем быстро и надежно ответить на вопросы о стоимости вашей среды AWS. Посетите нас онлайн, чтобы узнать больше, или запланируйте демонстрацию, чтобы увидеть наши инструменты управления затратами в действии.
