Традиционно процесс разработки программного обеспечения сравнивают с конструированием.
Термин «архитектор» лишь усиливает ассоциативную связь между этими процессами.
Но современные реалии сделали эту модель неактуальной, поскольку существуют механизмы, которые она не может объяснить:
- Если мы создаем какой-то физический объект или продукт, то почему программное обеспечение никогда не считается законченным?
- Если мы говорим об инженерных решениях, почему мы никогда не можем с уверенностью планировать заранее?
- Если мы архитекторы или строители, то почему так много проектов заканчиваются полным провалом?
- И, наконец, почему при таком большом количестве советов, лучших практик, принципов, книг и отчетов по разработке программного обеспечения так много проектов становятся жалким местом для работы?
Почему важно иметь модель
Модель позволяет провести аналогию между незнакомым или трудным для понимания процессом и чем-то знакомым, понятным нам.При этом она должна не только точно описывать ситуацию, когда все хорошо, но и, как любая хорошая аналогия, модель должна направлять нас в пограничных ситуациях.
Процесс разработки программного обеспечения представляет собой совокупность двух связанных, взаимодействующих, но, тем не менее, отдельных объектов: кода и команды.
Это подтверждается законом Конвея.
Связь между этими сущностями говорит нам о том, что проблемы в коде связаны с проблемами в команде и наоборот. Поэтому у нас есть два варианта их решения: со стороны кода и со стороны команды.
Некоторые проблемы кажутся чисто проблемами кода, некоторые — чисто командными проблемами.
На самом деле, это все проблемы с обоими компонентами.
Поэтому новая модель должна соответствовать современным реалиям и отражать связь обеих составляющих процесса развития.
Описание новой модели
Пространство, в котором живет приложение
Строительство здания состоит из трех этапов: проектирование, строительство и обслуживание.Раньше разработка программного обеспечения выглядела аналогично: результатом разработки был готовый продукт. Его установил пользователь и передал на поддержку отдельной команде, а разработчики начали заниматься чем-то другим.
Но в мире веб-приложений, развертываний и выпусков несколько раз в день, по сути, ничего не является завершенным.
Аналогичная ситуация наблюдается в мобильных приложениях и играх, когда они автоматически обновляются на консоли через Steam (чаще всего в самый неподходящий момент).
Кроме того, в меняющейся бизнес-среде приложения должны быть гибкими и способными меняться.
Много усилий уходит на разработку, чтобы обеспечить такую гибкость.
Чего нельзя ожидать от зданий.
Инфраструктура, которую мы используем для разработки приложений, больше похожа на здание.
Мы создаем не сами здания, поскольку большинство приложений занимают место в заранее построенных структурах.
Это звучит как понижение от архитекторов до дизайнеров интерьеров, но в этой модели много силы.
В нем здания — это основа для наших приложений: фундамент — ОС, уровень парковки — язык программирования, само здание — используемые фреймворки, и внутри них мы разрабатываем приложения.
Внутреннее пространство (структура), обеспечиваемое зданиями, изменчиво, но изменить его сложнее, чем собственный код. Точно так же, как снести стену сложнее, чем переставить мебель.
Таким образом, само здание (каркас) накладывает определенные ограничения на возможности и внешний вид вашего интерьера (применения).
Каждое здание оптимизировано для своих целей.
Приложение можно разместить в любом из них, но какие-то пространства подойдут для него лучше, а какие-то хуже.
Следовательно, код, который вы собираетесь поместить в предварительно сформированное пространство, будет определенным образом сформирован этим пространством.
В нашей отрасли по-прежнему ведется огромный объем строительных работ, но большинство из нас по-прежнему работают над интерьерами (приложениями).
Новая цель развития
Если ко всему этому добавить тот факт, что проекты сейчас никогда не считаются завершенными, то приходишь к выводу, что код — это не то, что мы создаем, а то, где мы живем .Это заставляет взглянуть на саму цель разработки под другим углом.
Место, где мы живем, нужно сделать пригодный для жизни : пригоден, комфортен и удобен для проживания.
И не только для себя, но и для тех, кто живет с нами.
С кодом недостаточно просто закончить продукт и двигаться дальше.
Это тоже нужно сделать пригодный для жизни : понятный, поддерживаемый, расширяемый — для команды, которая в нем «живет».
Что такое живой код
Пригодный для жизни Применительно к дому это означает, что вы живете в пространстве, где вы можете заниматься повседневными делами с комфортом и легкостью.В спальне есть лампа для чтения, салфетки на журнальном столике, коробка для джойстика в гостиной и стойка для велосипедов в коридоре.
Но что это значит пригодный для жизни для группы людей зависит от них самих.
Комфортный дом для молодых родителей с ребенком – это не то же самое, что дом для студентов или пожилых людей или одинокого родителя с подростком.
Пригодный для жизни для кода означает то же самое: вы можете изменить или добавить то, что хотите, но не слишком усложняя и не раздражая.
Вы понимаете, что где, поэтому можете легко перейти в нужное место кода и работать с ним.
Здесь принцип тот же: что пригодный для жизни для одной команды, не подходит для другой.
Что пригодный для жизни для одного старшего и четырех юниоров отличается от пригодный для жизни для пяти пожилых людей и сильно отличается от концепции пригодный для жизни для аутсорсинговой команды.
Люди приходят и уходят, поэтому создание и поддержка кода пригодный для жизни Это непрерывный процесс.
Появление нового члена команды похоже на появление нового соседа по комнате: у него есть странный диван, который ему почему-то очень нравится, поэтому вы неохотно соглашаетесь поставить его в гостиной.
А через пару дней сосед предлагает заменить шторы и жалюзи, ведь они более эргономичны.
И самое ужасное, что он моет посуду табами вместо пробелов! 
Но теперь вы живете вместе, поэтому вам придется договариваться.
Получается, что ваше настроение и состояние больше зависят от тех, с кем вы живете, чем от конкретных вещей в квартире и еще меньше от ее планировки.
То же самое и с кодом: ваше благополучие зависит в основном от тех, с кем вы работаете, и гораздо меньше от самого кода или фреймворка.
Как проект становится захламленным
Но что, если ваш код выглядит как эта комната? Как сделать его подходящим для команды? С чего начать?
Согласитесь, здесь сложно передвигаться, не говоря уже о том, чтобы придумать, как навести порядок.
Почему дома доходят до такого состояния? Часто говорят, что это лень.
Психологи думают иначе: дом попадает в такое состояние из-за ряда, казалось бы, незначительных неверных решений.
Представьте себе, как все могло начаться.
Есть небольшая комната, в которой вы постарались оптимизировать пространство: добавили несколько полок и ящиков, использовали подоконник.
Какое-то время все было хорошо: ты поддерживал порядок каждый день.
Но вечер наступил после тяжелого дня, когда ты не убрался.
Утром вы проспали, а вернувшись домой, поужинали прямо за столом и забыли убрать тарелку.
На выходных твои родители принесли твои старые вещи.
Разбирать их некогда было и ставишь коробки как есть.
И вы чувствуете, что комната уже не в порядке, но ее состояние настолько удручающее, что вы не можете понять, с чего начать исправлять ситуацию и вскоре она превращается в ? Серия маленьких плохих решений: в комнате и так жуткий беспорядок, почему бы не выбросить книги на пол? То же самое происходит и с кодом.
Вы открываете уже плохой файл, полдюжины шаблонов, которые уже не работают. А за тобой стоит менеджер и ждет, пока баг исправят. Первое, что приходит на ум, — как можно лучше зафиксировать жучок скотчем и как можно быстрее уйти отсюда.
Эти, казалось бы, небольшие локальные решения — именно то, что приводит код в состояние.
непригодный для жизни .
Однако есть способы выбраться из этой ямы, которую мы роем сами.
Спасение через изменение привычек
Замечали ли вы, что в большинстве захламленных и неопрятных домов часто бывает много журналов, вырезок из газет с красивыми и уютными интерьерами? Также есть фотографии, проекты, советы по правильному обустройству жилого пространства.Люди, живущие в захламленных домах, хотят жить по-другому, они просматривают все эти журналы и чертовски хотят себе такого же интерьера, но не знают, как этого добиться.
И они думают, что только какое-то радикальное решение или событие позволит им сделать свой дом таким, как на картинке.
По американскому телевидению идет шоу под названием Hoarders. Люди, живущие в вечном беспорядке, соглашаются участвовать в команде профессионалов, чтобы навести порядок и создать дизайнерский интерьер в своем доме.
Ну и как всегда в конце программы красивые фото ДО и ПОСЛЕ.
Интересно, что большинство участников признаются, что в итоге их дом вернулся в исходное состояние.
Все просто: одна и та же последовательность мелких неправильных решений привела их к одному и тому же результату.
Оказывается, более эффективный путь — постепенная, длительная работа, работающая не с содержимым дома, а с самими людьми.
Цель состоит в том, чтобы изменить их привычки, чтобы они сделали соблюдение порядка частью своей повседневной жизни.
К сожалению, продюсеры сочли бы такой вариант слишком скучным для реалити-шоу.
Захламленный код ведет себя точно так же: мы боремся с ним изо дня в день, лишь бы решить текущую проблему, и мечтаем все переписать.
Вот если бы мы могли сделать все заново, мы бы точно не совершали тех же ошибок! Нам нужно переписать jQuery на Ember! Надо разрезать монолит на микросервисы! Иногда это срабатывает, по крайней мере, на время, достаточное для того, чтобы написать триумфальный пост в блоге.
Но затем гаснет свет, камеры перестают работать, съемочная группа покидает съемочную площадку, и если вы не измените свои привычки, вы снова окажетесь в беспорядке, даже быстрее, чем вы ожидали.
Люди думают, что большие ошибки нас убивают: дом слишком мал, планировка плохая, неправильный каркас, монолит, недостаточно ресурсов.
Это не верно.
Нас убивают маленькие решения, которые исходят из привычек и образа мышления.
Вы можете переписать что угодно.
Но если ваша команда не изменит своих привычек, вы окажетесь в запутанной паутине микросервисов, точно так же, как в вашем монолите была запутанная паутина классов и модулей.
Командные привычки
Следует отметить, что речь идет не об индивидуальных, а о командных привычках и нормах.Это объясняет, почему образ разработчика как отдельного профессионала, ремесленника не отражает действительности.
Это не индивидуальный разработчик, ленивый и непрофессиональный.
Это команда с плохой культурой командной работы.
Точно так же, как и с соседями по комнате: каждый должен делать ежедневную уборку, мыть за собой посуду, периодически убирать ванную и туалет, наводить порядок в общей гостиной.
Но есть и более сложные виды деятельности, которые необходимо улучшить.
пригодность для жизни , который можно оставить «только для интересующихся».
Например, перевесить кухонные шкафы или выбрать для гостиной подходящий стол вместо слишком громоздкого.
Но ежедневная работа – это то, что должен делать каждый.
То есть в команде могут быть люди, заинтересованные в глобальном архитектурном рефакторинге, разбивке слишком больших модулей, оптимизации взаимодействий между ними, и те, кто не хочет этим заниматься.
Не все обязаны участвовать в перестановке мебели, но мыть посуду каждый должен сам.
Две крайности непригодный для жизни или почему книги не работают
Замечательный интерьер, не правда ли? Все идеально подобрано и продумано, ничего лишнего.
Одним словом - мечта.
Точно так же, как описывать шаблоны, которые показывают красивую версию идеально согласованного, совершенно абстрактного кода.
Настолько красиво, что радует глаз.
Да, квартира на картинке красивая, но жить в ней не получится.
Квартиры со страниц журналов намеренно лишены беспорядка, ведь беспорядок – это нечто индивидуальное.
Из чего состоит этот бардак, у каждого разное.
Если вы любите читать, то это книги, если любите компьютерные игры, то это консоль и джойстики, а если любите активный отдых, то это велосипед или каяк.
Вещи, которыми вы пользуетесь, должны быть под рукой, поэтому вам придется смириться с определенным беспорядком.
Главное, чтобы его не было слишком много.
Журналы о красивых интерьерах в мире разработки программного обеспечения показывают нереально чистый код и поэтому задают неверные ориентиры.
К ним относятся книги по разработке программного обеспечения, шаблонам проектирования, советы из блогов и статей.
Код, удовлетворяющий всем их требованиям, идеально последовательный и абстрактный, нежизнеспособен в реальном мире.
Даже если вам удалось этого достичь, вы не сможете в этом жить.
Нам нужен небольшой беспорядок, чтобы чувствовать себя комфортно.
Это справедливо как для квартиры, так и для кода.
Обе крайности непригодный для жизни .
Если перед вами кусок кода, который вы не понимаете и не умеете с ним работать, то это одна из этих крайностей.
Либо он слишком захламлен, что невозможно отличить подходящие идеи от неподходящих, либо настолько чист, что подходящие идеи просто невозможно найти.
Более того, эти две крайности могут существовать одновременно в одном проекте.
Иногда даже по соседству друг с другом.
Пригодный для жизни код находится где-то посередине.
Точно так же, как комфортное жилое пространство находится где-то между фотографиями с обложек журналов и захламленной квартирой.
Поэтому вам нужно уметь принять небольшой беспорядок, потому что он освобождает пространство.
пригодный для жизни .
Манифест
Вы можете сказать: «Все это очень интересно, но что, если мой код и так полный бардак? Или что, если проект не так уж и плох, но я хочу убедиться, что он не движется в неправильном направлении? Допустим, ваш код выглядит как захламленная устаревшая гостиная, через которую проходят узкие тропинки понимания.Не волнуйтесь, вы не плохой человек – такое может случиться с каждым.
Если посмотреть на проблему с инженерной точки зрения, она просто кричит: «Перепиши! Как можно что-то организовать в таком месте, не имея свободного места? Просто забери все это отсюда и начни заново!» Такое нисходящее планирование хорошо работает для некоторых инженерных задач, но не для большинства программ.
Это не потому, что мы плохие инженеры или плохо стараемся, а потому, что в нашей области инженерный подход не работает. Что работает, так это рассматривать код как пространство, в котором живут люди.
Нужно понимать, что люди – это именно то, над чем вам нужно работать.
Вот как это сделать.
Есть четыре правила, которые справедливы для любого языка и структуры.
Не навреди
Почти как в медицине.Открывая и без того захламленный файл, пообещайте, что не сделаете его хуже.
Даже если у вас нет времени исправлять то, что и так ужасно.
Если во время проверки кода вы увидите, что кто-то нарушает это правило, просто напомните ему о том, о чем вы договорились.
Верьте в постоянные улучшения
Стопка из пяти книг на полу и одна, спрятанная в шкафу, лучше, чем стопка из шести книг.Возможно, тот, кто в следующий раз прикоснется к этому коду, перенесет из стопки на полку еще одну книгу.
Если вы будете ждать, пока появится время установить их все сразу, этого никогда не произойдет. Использование такого подхода может стать проблемой.
Для многих последовательные улучшения затруднены, поэтому они продолжают жить с жгучим желанием полностью переписать модуль, подсистему или приложение.
В результате стопка книг не уменьшается и остается на полу от итерации к итерации.
Сделайте поддержание порядка частью вашего рабочего процесса
Не создавайте пользовательские истории для рефакторинга.Не ждите две недели, чтобы исправить один файл.
Научитесь встраивать простые правила в свою повседневную работу.
Правило бойскаутов гласит: покидай лагерь чище, чем прибыл.
Если вы будете следовать ему постоянно, вы постепенно избавитесь от «вредных привычек».
Поддерживать связь
Будьте готовы всегда обсуждать с каждым членом команды то, что вы делаете.Предыдущий пункт не означает, что вам нужно скрывать то, что вы делаете.
Вам просто нужно рассматривать рефакторинг и наведение порядка как часть всего, что вы делаете.
Когда вы проводите рефакторинг:
- Не спрашивайте разрешения.
Это часть вашей работы.
Но будьте открыты для обсуждения ваших решений.
- Не уклоняйтесь от ответственности за свои ошибки и учитесь на каждой из них.
Ошибки также являются частью работы.
Именно через них мы приходим к пониманию того, над чем работаем.
Ты сделаешь их, прими это.
Иногда вы можете не завершить рефакторинг, иногда, наоборот, слишком увлечься, но главное — учиться на своих ошибках снова и снова.
- Просите совета, но не всегда следуйте ему.
Ваша задача как разработчика — определить, что необходимо рефакторить, а что нет. Вам нужна свобода принимать решения и совершать ошибки.
- Делайте все вместе, ведь вы здесь живете.
Это очень важно.
Мы должны изменить код, в котором нам приходится жить, на код, в котором нам нравится жить.
Заключение
Самая важная часть разработки программного обеспечения — это не код и не люди.Самая важная часть – это система.
Чем больше мы думаем о разработке как о взаимосвязанной системе кода и людей, тем ближе мы к революции и к проектам, над которыми мы хотим работать.
Вы тоже можете прийти к этому.
Как бы плохо сейчас ни было, ты можешь сделать все что угодно.
Если вы построите доверие и укрепите связи внутри команды, если все будут уважать код, в котором они работают, если вы примете реальность и откажетесь от иллюзий переписывать все заново и пообещаете друг другу следовать правилам, то у вас все получится.
Ссылки
- Оригинал отчет
- Статья Боб Мартин, в котором он делится своими мыслями о модели, предложенной Сарой Мэй.
- Родственники по духу принципы от Боба Мартина
-
Freedom84 – Стоит Ли Оно Того?
19 Oct, 24 -
К Вопросу О Linux (Л)
19 Oct, 24 -
Опрос С Использованием Облака Тегов
19 Oct, 24
