Продолжение.
К предыдущим постам и карте цикла.
Повседневная жизнь разработчика.
Цели определены, направления выбраны, задачи прожеваны.
Вам просто нужно писать код и жевать кашу.
Что может скрасить серость и однообразие существования? Конечно ежедневный стендап - шоу, в котором найдется место каждому! Ну и эти неожиданные «Я посмотрел архитектуру и там ошибка» или «Я добавил новый модуль, который может нам пригодиться в будущем» и, конечно же, «Я сделал все проще и быстрее».
Именно поэтому мы проводим все церемонии по уходу и планированию.
Чтобы как бы подготовить почву и дать всем время посидеть в тишине и подготовить кульминационные фразы к концу спринта.
И самое обидное, что затрачивая столько усилий, стоять в стойке у тебя обычно не получается и удары тебе перекладывают начальство.
https://www.flickr.com/photos/cosmic_flurk/5712236914@CCL В чем интрига? В самой сцене.
В самом начале дня мы обычно проводим ежедневное совещание по развитию.
Там все делятся своими успехами и проблемами.
Они готовы поделиться.
Давно и много.
Как раковые клетки.
Вы даже можете сделать тесты.
Чем больше тем об этом ежедневно, тем больше опухоль в проекте.
Тогда придется сжечь и разрезать.
Но команд много, а архитекторов недостаточно.
Поэтому ему не звонят, если он уже не курит. Затем разработчики выбывают, и в следующий раунд проходят только лидеры команд. Они более практичны и рассказывают о своих успехах и о том, что все идет по плану, а проблемы уводят в офлайн.
Сухо и без шуток.
С разработчиком.
менеджер обычно говорит, что все положительно, если только менеджер сам не начнет копать или не возникнет подозрение, что срок уже под носом.
А так как начальник человек занятой (его каждый раз кто-то занимает, но, как ни странно, каждый раз дает), команд много и проекты глобальные, то к команде присоединяется представитель от каждой площадки (ротация среди лидов).
общее собрание, куда обычно приглашается архитектор.
Это самые бесполезные полчаса.
Каждый уже пару раз рассказал свою историю и обдумал свои проблемы (и тут, видимо, как в анекдотах: проблема, повторенная дважды, перестает быть проблемой).
Кроме того, нужно говорить по-английски, который для большинства не является родным и там очень много акцентов.
Короче говоря, каждый избранник старается произнести одно-два предложения, чтобы не дай бог не задали вопросы.
Как на приеме в налоговой инспекции.
Ежедневная сетка игр В результате каждая команда поделилась своими проблемами только сама с собой.
Оставаясь в замкнутом круге бизнес-задач и решений, знакомых всем его участникам.
Я не против психотерапии, но если у тебя есть проблема и ее можно решить внутри коллектива, то зачем ждать планерки? А если не можете, что поможет озвучить это в том же кругу? Но я не менеджер и даже не Agile-коуч — не понимаю.
Я Винни Пух и я иду к тебе в гости утром.
Кому-то.
Желательно без приглашения (иначе рискуете услышать заученный текст на английском языке) на ту самую первую сцену, где профилактика обойдется дешевле лечения.
Это отличная экономия времени, поскольку альтернативой является просмотр коммитов.
Код обзора такой же, как и у рыбьего жира.
Это может быть полезно, но это никому не нравится.
Они любят мед. Но мёд, как известно, предмет странный — он существует только там, где тебя нет. Коррекция ветра Не все компании одинаковы.
Как маркеры.
В некоторых местах много архитекторов и мало команд. В некоторых местах отсутствуют три уровня сцены.
Там где черт не может быть сложностей с коммуникацией и прозрачностью деталей реализации.
Так что пробуйте на вкус и цвет. Если нет проблем, то жизнь хороша.
Но как сказал агент Смит, в утопии можно потерять весь урожай.
С местной командой всегда хорошие контакты и неформальные связи.
Разработчик может просто подойти и спросить.
Но если у вас куча удаленных подразделений и они находятся в какой-то далекой стране в другом часовом поясе, то установить с ними прямой контакт очень сложно.
Особенно там, где корпоративная иерархия пользуется большим уважением и не умеет сказать «нет».
Программистам не разрешается озвучивать свой голос вне церемоний и без участия своего непосредственного руководителя.
Из личного опыта: иногда доходит до абсурда.
Был проект, где архитектором была девушка.
А начальник участка в дальнем лагере — усатый седой парень в тюрбане.
Итак, пока кто-то из команды архитекторов-мужчин не прислал электронное письмо: «делай, как она сказала», раджа игнорировал все ее записи.
Такая культура.
В общем, мудрый Раджа оказался еще мудрее.
Чем являются будни архитектора, кроме кофе и рисования? Ведь многие считают, что архитекторы строят гнезда только из одноразовых стаканчиков в местах большого скопления досок.
Конечно, в ловле личинок клопов! В первую очередь, конечно, интересуют ошибки проектирования.
То есть собственные ошибки.
Перед началом разработки архитектуру обмеряли семь раз, но когда приходит время резать, оказывается, что попасть в цель сложно, пила не та, брус не тот. Все гармоничные теории начинают ускользать от вакуумного шара.
На этапе разработки первоначальной версии начинают уточняться все детали, которые вошли в финальную версию договора.
Самое важное: дата и точный набор функционала первой демо-версии для клиента.
Первые конфликты требований не заставят себя долго ждать.
Сами проблемы очень пунктуальны – никогда не опаздывают и даже стараются встретиться с вами пораньше.
Мои наблюдения за характером событий позволяют предположить, что источником часто являются благие намерения и ограниченность знаний (слабоумие и доброта).
Чем меньше деталей вы знаете, тем радужнее и проще картина.
Поэтому клиенту обещают немного больше и немного раньше.
Пусть даже и не официально.
Чтобы проявить себя, получить дополнительный балл за участие в торгах на следующем этапе или защитить сроки/качество, принудительно перенеся дату поставки на пару недель раньше.
Ну и оставить немного на доработку и стабилизацию.
Спринт дальше закалка .
Английское «закаливание» более уместно.
Как только сроки начинают сдвигаться туда-сюда, сразу чувствуешь закалку.
И если вы продолжите тянуть, проект может закончиться плохо.
Те же благие мысли подталкивают участников процесса добавить еще немного функционала из серии «чтобы не ходить дважды».
Такие вещи из задела, которые находятся в одном куске, разрабатываемом сейчас и мало весят. А они все равно будут прикрыты проверками, и код уже будет открыт в нужном месте.
Маленькие задачи.
Пара часов сюда, пара часов туда, и вот появляются первые участки дороги в инженерный ад. 
7 фишек этому господину! У каждого свой ад. У меня это как ежедневные дебаты с руководителями разных отделов, каждый из которых предлагает «вместо вашей дурацкой инфраструктуры давайте сделаем анимированные кнопки».
Слышали ли вы когда-нибудь: «Действительно ли нужно писать модульные тесты? А может, можно как-нибудь без нихЭ» или «нам это твое сейчас не нужно раскачиваемость , а красивый интерфейс — это лицо продукта».
Хорошее лицо тоже важно, но этот орган плохо поглощает кинетическую энергию и при встрече с конкретной реальностью лучше приземлиться на задницу.
Особую нишу занимает «тут на охрану отведено 20 дней, нужно успеть за 10, чтобы втиснуть еще пару фишек» из бессмертной серии «сможешь ли ты сделать семь шляпЭ» Мне всегда сложно объяснить кому-то, почему 2+2 = 4. Для сложных вещей всегда есть аргумент, а как объяснить то, что ты считаешь основным, да еще когда это невозможно доказать экспериментально за 5 минут. Световая граната Помню в университете преподавателя по линейной алгебре, который заставил меня на экзамене написать типа «один из результатов 2+2 будет 4. Точное определение операции сложения и поля чисел, над которым эта операция выполняются, указаны ниже».
В противном случае он сам дал произвольное определение, чтобы 2+2 было 4+С или, скажем, (+4;-4) и не засчитал ответ. Я тогда был в ярости, но, кажется, учитель был настоящим инженером.
Не зря его книги продаются в переводе на несколько языков.
Я зря пишу здесь и пытаюсь донести свою мысль: решений зачастую больше, чем одно, и в разных условиях правильными могут считаться разные варианты.
Чтобы снизить уровень ада, нужно делать презентации, которые бы наглядно показывали, «как у нас все работает и почему».
Конечно, мне бы хотелось Бош , но вам придется совмещать простые эскизы со стрелками.
Проанализируйте бэклог, найдите дублирующиеся требования и покажите, что «кнопки сейчас» по стоимости равны «кнопкам завтра», а «безопасность сейчас» намного дешевле, чем «безопасность завтра».
Выстраивается цепочка требований, ведущих или исходящих от кнопки, и одинаковая для требования безопасности.
Поскольку бизнес-требования обычно не пересекаются, цепочку таких требований легко перемещать по плану вперед и назад. Это означает, что цена останется неизменной.
Инфраструктура пронизывает все модули и цепочки, а это значит, что если завтра модулей будет в 10 раз больше, то и интеграций/внедрений и проверок будет в 10 раз больше (важная статья затрат и времени).
Кто бы мог подумать!? И обязательно погуглите что-нибудь из серии «цена сбоя в обеспечении безопасности» в вашем промышленном/бизнес-секторе.
Пример всегда хорошо работает для производства Иранские центрифуги .
Есть множество примеров в сфере финансовых технологий или розничной торговли.
Хорошая страшилка лучше любой формулы.
Детей пугает сказка о волке, а не расчеты семейного бюджета (хотя последнее может быть гораздо страшнее).
шашлычная инфраструктураНа моей памяти Около 10 лет назад один из наших клиентов, лидер своего сектора в развитой европейской стране, после взлома потерял пару пунктов в своем рейтинге и обороте.
А другой наш клиент, который был на третьем месте, сразу вложил в безопасность тройной бюджет и в том же году возглавил рейтинг.
Хотя по размерам и размаху он был в 4 раза меньше.
Сейчас проверил, они опустились на второе место, но с хорошим отрывом от предыдущего третьего места.
Теперь вы завершили семь раундов ежедневных встреч и можете приступить к работе.
Ваша компания выиграла большой тендер в том числе и благодаря волшебной пыли, которой вы сдобрили свое видение решения в документах и схемах.
Кто и как использует эту пыль – не наша забота.
Заключен договор и пора сдуть его со всех рисунков.
Под ним много пыли пустые места , который сейчас самое время заполнить.
Конечно, вы можете заполнить его своей фантазией – в начале все легко исправить и цена ошибки минимальна.
Поэтому советую привлекать к проектированию инфраструктурных модулей самих разработчиков.
Если хорошему программисту дать конечный результат в стиле «сделай вот так», то он может и сделает, но осадок останется.
Основные компоненты создают специалисты и у них есть свое мнение, которое они хотят высказать не просто на стенке, а чтобы его услышали.
Это неплохо, но мне нравится делать дела, а не говорить и слушать.
Если бы я умел слушать и говорить, я бы играл в Тиндер, а не в тендеры.
И я уже прислушивался к мнению ключевых экспертов, когда зарисовывал и готовил решение.
Теперь, когда все одобрено и подписано, начинать все сначала по меньшей мере непрактично.
Мои ноу-хау в этом процессе основаны на мозговой штурм .
У вас есть готовый вариант архитектуры модуля.
В моем случае это означает, что модель (абстракции) и контракты (данные) определены и имеется сопутствующая диаграмма взаимодействий или сущностей.
Итак, я начинаю строить эту диаграмму вместе с разработчиком, сообщая ему требования и проблемные аспекты, чтобы он в конце посмотрел на мое решение и сказал: «Как здорово, что мы придумали!» Конечно.
Это работает примерно так: Нам нужен модуль, который принимает пакет цифровых документов и отображает их в базу данных.
Разработчик сразу предлагает некоторые паб-саб , асинхронные (так почему-то 80% людей называют параллельные процессы) задачи и парочка микросервисов.
Где бы мы были без них? 
первый предложенный вариант Теперь вам нужно схватить его за руку и вести куда хотите.
Представлена проблема и предложено решение, записанное в вашей архитектуре.
Примерно так: «Хорошее решение, но если у нас будет «асинхронное» отображение, то возникнут проблемы с разделением.
Что, если вместо параллелизма сделать последовательность? 
второй предложенный вариант О параллелизме Иногда упускаются из виду проблемы последовательных запросов, перерастающих из очереди в параллелизм.
То есть с точки зрения бизнеса все в строгом порядке и по порядку.
Классический (для меня) пример — конвейерная обработка.
Здесь есть производственный конвейер, по ленте которого продукция переходит на следующий этап, а рядом стоит камера, снимающая каждую деталь для обработки данных в какой-то отдельной системе.
Данная система и камера являются отдельным продуктом для мониторинга и не участвуют в производстве, поэтому лента никого не ждет. Затем наступает тот самый неочевидный момент, когда скорость ленты превышает скорость обработки изображения.
Запросы, идущие непосредственно к серверной части, перекрываются.
Закон Литтла В бою.
А если об этом никто не подумал, то нас ждут все прелести конкуренции за ресурс, превратившийся из эксклюзивного в обычный.
Дальше скетч «одну проблему мы решили, но теперь нужно как-то обеспечить сохранность данных и доступность сопутствующих компонентов.
Что делать, если служба всего одна, а внутри есть шаблон, разграничивающий обязанности? Некоторый конвейер И теперь то, что было запланировано с самого начала, выходит наружу, только через руки исполнителя.
Он теперь понимает почему, а не только как.
При этом ему не нужно было анализировать и собирать всю колоду требований.
Вы открыли только нужные вам карты.
Да, обман, но почти святое.
финальный На 3-4 шагах мы уже достигаем желаемого результата.
В отличие от варианта, когда вы просто объясняете, почему стоит поступить именно так, вы не лишаете человека самого главного – поиска решения.
Разработчик не стенографист и не стал экспертом потому, что просто быстро записывал чьи-то записи построчно.
Если лишить его загадки, то работа может вызвать протест и массу негативных эмоций.
С другой стороны, он не знает всей картины.
Ни что и как будут делать в других командах, ни то, что запланировано на полгода вперед. Это основная причина существования должности архитектора – широкий и дальний взгляд на проект. Но ничего не будет работать, если ваша архитектура не соответствует требованиям.
Руководить разработчику будет нечем, да и незачем.
В этом случае лучше честно положить партбилет на стол.
У нас с этим строго.
Утром я Винни-Пух, а к концу дня свинья с ружьем! 
архитектор бьет вымышленного леопарда чучелом пистолета И всегда есть в кого стрелять.
Пока все старательно пишут код, нужно следить, чтобы все не старательно.
Здесь нам на помощь приходят всевозможные индикаторы и статические анализаторы кода.
Делать метрики для программистов — это работа менеджеров.
Меня лично беспокоят метрики кода.
Показатели работоспособности проекта:
- Никакого взрывного роста строк кода после первых шагов.
После того, как мы закончим создание базы и перейдем непосредственно к делу, коммиты должны быть небольшими и частыми.
Меньше кода почти всегда означает лучший код. Поэтому, если кто-то навалил кучу, то, скорее всего, проблема с задачей и несоответствие линии архитектуры.
- Длинные функции и классы — неплохой показатель спешной работы и костылей.
Этого не должно происходить на начальном этапе.
- Сложность кода можно отследить по количеству модульных тестов с высоким покрытием.
Много тестов – значит много ветвей, а значит, что-то опять чем-то пахнет.
- Нарушение конвенций также должно быть автоматизировано и контролироваться.
Закладывается фундамент дома, в котором мы все будем жить долгое время.
- Много статики (классы, методы, поля), обычно проявления антипаттернов.
- И, конечно же, проверки безопасности на наличие встроенных паролей и плохих ссылок на некоторое программное обеспечение с открытым исходным кодом, имеющее уязвимости или сложные лицензии.
Я вообще не люблю долги.
В общем, тут дело в том, что не вы берете на себя долг, а вы распоряжаетесь долговыми обязательствами.
Мы нашли дурака.
Ох блин, нашли - это часть задач архитектора.
Поэтому лучше помнить о своих KPI. Чтобы подготовиться к следующему этапу, вам необходимо построить хороший механизм журналирования.
Желательно на двух уровнях – один с понятной историей для бизнеса, а второй для технического анализа, что же все-таки произошло.
Когда мы перейдем от стадии демо, пусть и к ограниченному производству, будут первые пожары и охота на ведьм.
Наблюдать, как в полнолуние кто-то с седеющими руками вводит код прямо в программу – плохая примета.
Постарайтесь избежать этого, если это возможно.
Итак в одном потоке пишем: «пользователь ****341 запросил функцию «Поиск заказа» с аргументом 3480-4341-1334. Результат: не найден».
Этот лог будет использоваться службой поддержки при остановке процесса.
И второй поток со стеком, сервисами и всеми подробностями (опять же, кроме тех, которые необходимо скрыть в целях безопасности или для сохранения личных данных).
и коммерческая тайна).
Сюда придут разработчики, когда процесс начнется.
Логирование нужно делать с самого начала.
Они нужны всегда еще вчера, когда все произошло, а завтра от них будет мало пользы клиенту.
услышать: «Ваше производство здесь остановилось вчера, но мы не знаем почему.
Но в следующий раз у нас будет больше данных для анализа!» Хотя в некоторых компаниях только под угрозой штрафов начинают понимать, что стоит сразу вкладываться в аудит и мониторинг, и начинают чесать затылки (те, в которых едят, и те, на которых сидят).
Мысли вслух Есть разные архитекторы.
Теперь самый ажиотаж - архитектор решений .
Но нам нужен проблемный архитектор.
Тот, кто предсказывает несоответствия и видит конфликты.
Любую правильно поставленную задачу опытный разработчик может решить сам.
Архитектор нужен, чтобы задача была правильной и полной (не бодипозитивной, а с жирными штрихами в местах болевых точек и сочным описанием того, что будет, если на точку нажать).
Для меня не имеет значения, наполовину пуст стакан или полон.
Мне важно определить, что такое «половина» и что стакан окажется в том месте и в то время, когда начнут наливать.
И стоит уточнить, что серную кислоту в бумажный стаканчик наливать не будут.
| RFI | архитектура архитектура | |
| запрос предложений | О клиентах и продавцах | |
| ДД | Удар в дилижанс | |
| ЛОИ | Воспаленный аппендикс | |
| НОА | Один за всех и все за одного | |
| MVP | Ежедневный стендап | Вы здесь |
| POC | Нос в кепку | |
| Р.
О.
| Развертывание без конца | |
| БАУ | ||
| окончание срока действия |
-
Фаерфокс 6.0
19 Oct, 24 -
Как Работает Цифровой Компас
19 Oct, 24 -
Джейлбрейк Ipod Touch 2G
19 Oct, 24 -
Как Перейти На Облачный Мессенджер
19 Oct, 24
