Disclaimer: Статья Мартина Фаулера была опубликована в 2003 годув журнале IEEE Software. В сети (но не на Хабре) есть замечательный перевод пятилетней давности от Сергея Теплякова (SergeyT).
Недавно я встретил в коридоре явно раздраженного коллегу, Дэйва Райса (Dave Rice). Мой вводный вопрос вызвал резкое заявление: «Нам надо игнорировать любого кандидата, имеющего пункт «Архитектор» в резюме». Смущало в этой странной фразе то, что мы же сами, обычно, представляем Дейва как одного из наших ведущих архитекторов.
Причиной его «титульного психоза» являлся тот факт, что по меркам даже нашей индустрии, смысл слов «архитектор» и «архитектура» чрезвычайно переоценен. Многим кажется, что к термину «архитектор программного обеспечения» отлично подходит тот самодовольный и все контролирующий образ из финальных сцен «Матрица: Перезагрузка». Но даже в компаниях относящихся с большим презрением к такому отображению, все равно, существует жизненно важная роль технического лидера, в сущности – архитектора, такого, как сам Дейв.
Что такое архитектура?
Когда я изводил себя по поводу названия книги «Архитектура корпоративных программных приложений» (Patterns of Enterprise Application Architectureб Addison-Wesley, 2002), каждый наш рецензент соглашался, что «архитектура» попала в заголовок по праву. Однако у всех нас возникли сложности с попытками дать определение этому слову. Так как это была моя книга, я чувствовал, что был обязан разделаться с этим понятием.
Первым порывом уйти от неясности было – удариться в цинизм. В известном смысле я определял архитектуру как слово, которые мы используем, когда хотим обсудить дизайн, пытаясь, при этом, придать ему побольше важности. (Да, это же можно применить и к архитекторам). Как это часто случается, однако, в любом разливе цинизма обнаруживается капля истины. Понимание пришло ко мне после прочтения сообщения Ральфа Джонсона (Ralph Johnson) из списка рассылки «Экстремальное программирование». Переписка была настолько хороша, что я приведу ее тут полностью.
В предыдущем сообщении говорилось:
RUP, опираясь на определение IEEE, описывает архитектуру как «самое высокоуровневое понятие о системе в рамках ее среды. Архитектура программной системы (в заданный момент времени) – это ее организация или структура важных компонент, взаимодействующих через интерфейсы, где каждая из компонент собрана, в свою очередь, из еще более мелких составных частей и интерфейсов».
Джонсон ответил:
Я был рецензентом упомянутого стандарта IEEE и доказывал, безрезультатно, что это было целиком и полностью фальшивое определение. Нет никакого высокоуровневого понятия о системе. У пользователей свое видение системы, отличающееся от того, чем оперируют разработчики. Пользователям вообще нет никакого дела до структуры важных составных частей. Да, возможно архитектура и является самым высокоуровневым представлением разработчиков о системе в рамках среды. Но давайте забудем о тех разработчиках, которым доступно понимание лишь своего небольшого участка. Архитектура – это самое высокоуровневое представление системы разработчиками-экспертами. Что делает определенный компонент важным? Он важен, потому что так сказал эксперт.
Таким образом, лучшим определением могло бы быть: «В наиболее успешных проектах разработки ПО, наиболее высококвалифицированные разработчики, работающие над данным проектом, имеют одинаковое представление о дизайне системы. Такое совместное понимание и называется «архитектура». Это понимание включает в себя то, как система делится на компоненты и как эти компоненты взаимодействуют между собой через интерфейсы. Данные компоненты обычно составлены из более мелких частей, однако архитектура включает в себя только те составные элементы и интерфейсы, которые понятны сразу всем разработчикам».
Такое определение могло бы оказаться лучшим потому, что становится ясно, архитектура – это общественный конструкт (да, само программное обеспечение тоже, но архитектура в еще большей степени), потому что она зависит не просто от ПО, но от того, какие части ПО признаны важными в результате согласованного мнения группы.
Есть и другой способ определения архитектуры, вроде такого: «архитектура – это набор решений, которые должны быть приняты на ранней стадии проекта». Такой вариант я тоже критиковал, указывая, что архитектура – это решения которые вы хотели бы принять правильно в самом начале проекта, при том, что не факт, что они окажутся более удачными, чем любые другие.
В любом случае – по второму определению, для большинства проектов, язык программирования окажется частью архитектуры, а по первому – нет.
Является ли что-либо частью архитектуры – полностью зависит от того, расценивается ли это как важное разработчиками. Люди, которые создают «корпоративные» приложения считают критически важной персистентность. Когда они начинают обрисовывать архитектуру, сразу получают три уровня. Упомянут что-то вроде «мы используем Oracle в качестве нашей базы данных и создадим свой слой хранения для отображения в нем объектов». А вот приложение для медицинских снимков может включать технологии Oracle без рассмотрения их с архитектурной точки зрения. Так происходит потому, что самые большие трудности для них заключаются в обработке изображений, а не в хранении. Получение и сохранение изображений обеспечивается лишь маленькой частью приложения и большинство разработчиков ее попросту игнорируют.
Именно это делает сложным делом объяснение людям того, как им описывать архитектуру. «Скажите нам, что здесь важно». Архитектура о важных вещах. Чтобы под ними не подразумевалось.
Роль архитектора
Итак, если архитектура — это о важных вещах, тогда архитектор — это персона (или группа людей), который заботится о важных вещах. И тут мы подходим к сути отличия вида архитектора из «Матрица: Перезагрузка» с тем стилем, который представлен в лице Дэйва Райса.
Аркитектус Рилаудус (Architectus Reloadus) – это персонаж, который принимает все важные решения. Архитектор занимается этим, потому что для обеспечения концептуально целостной системы необходим единый взгляд и, возможно, потому что архитектор не считает членов команды достаточно квалифицированными, чтобы принимать такие решения. Часто такие решения нужно принимать на самых ранних стадиях, чтобы у всех остальных имелся план, которому они могли бы следовать.
Аркитектус Оризус (Architectus Oryzus) это другой зверь (если не получается угадать, попробуйте archives.nd.edu/latgramm.htm). Такой тип архитектора должен быть очень внимателен к тому, что происходит в проекте, выискивая важные вопросы и решая их до того, как они превратились в серьезные проблемы. Когда я наблюдаю за архитектором такого рода – я вижу, что самая заметная часть его работы – это интенсивное сотрудничество. По утрам такой архитектор программирует вместе с разработчиками, выискивая наиболее общий «стопорящий» код. Днем этот архитектор участвует в собраниях по определению требований, помогая объяснять разработчикам требований технические последствия некоторых из их идей через нетехнические понятия, такие как стоимость разработки, например.
Во многих отношениях самым важным занятием Аркитектуса Оризуса является наставничество для команды, подъем ее до уровня, на котором она сможет решать более сложные вопросы. Повышение способностей команды дает в руки архитектору гораздо более сильный рычаг, чем из положения одинокого руководителя, что, в свою очередь, помогает избегать опасности стать архитектурной пробкой проекта. Это подводит нас к эмпирическому правилу: ценность архитектора обратно пропорциональна количеству решений, которые он или она принимают.
На недавнем выездном собрании ThoughtWorks я обсуждал с некоторыми из коллег тему архитекторов. Мне показалось интересным, что мы быстро пришли к единому мнению о природе должности, имея в виду Аркитектуса Оризуса, но вот подобрать ему название было уже непросто. Аркитектус Рилаудус же, слишком знаком нам, чтобы причислять его к «архитекторам», и, кроме того, основан на некорректной метафоре (см. тут). Майк Ту (Mike Two) предложил лучшее название из тех, что мне довелось услышать: проводник, в альпинистском смысле. Проводник – это более опытный и умелый член команды, который учит остальных участников группы лучше справляться с опасностями самостоятельно, и, в тоже время, всегда оказывается рядом в особо сложных случаях.
Избавляясь от архитектуры ПО
Люблю писать провоцирующие заголовки, лучшие из которых, как и в данном случае, содержат важный, но не всегда очевидный изначально, смысл. Вспомните второе определение от Джонсона: «Архитектура — это решения, которые вы хотели бы принять без ошибок еще на ранних стадиях проекта». Почему людям кажется, что некоторые моменты надо решить правильно уже в самом начале проекта? Суть в том, что они, очевидно, считают данные элементы слишком сложными для изменения в будущем. Т.е. в итоге мы можем перефразировать определение архитектуры как «элементы, которые люди считают сложными для изменения в будущем».
Общепринятым в построении корпоративного приложения, например, считается необходимость определиться со схемой базы данных с самого начала. Потому что изменить схему базы действительно сложно, особенно если приложение уже используется. В одном из наших проектов, администратор БД Прамод Садалаж (Pramod Sadalage) придумал систему, позволявшую нам менять схему (и переносить данные) без проблем (см. тут, а тут перевод). Сделав это, он исключил схему БД их разряда архитектурных элементов. Я считаю это решение замечательным, так как оно позволило нам лучше справляться с изменениями.
Экономист Энрико Занинотто (Enrico Zaninotto), в восхитительном выступлении на конференции XP2002, представил основные идеи, стоящие за идеей agile на производстве и в разработке программного обеспечения. Один момент, который показался мне особенно интересным, заключался в его комментарии о том, что необратимость была одним из первичных факторов, приводившим к сложности. Он рассматривал agile методы в промышленности и в индустрии разработки ПО как сдвиг парадигмы в поисках способа борьбы с необратимостью, в противовес попыткам избавиться от других предпосылок, приводящих к запутанности. Я считаю, что одна из главных задач архитектора – избавляться от архитектуры, находя способы предотвращения необратимости в дизайне ПО.
И снова вернемся к Джонсону, в этот раз привожу ответ на мое письмо:
Одно из различий между строительной архитектурой и архитектурой программного обеспечения заключается в том, что многие строительные решения очень трудно изменить. Сложно, хотя все еще возможно, вернуться в начало и изменить подвал.
Никаких теоретически обоснованных причин считать что-либо трудно изменяемым в программном обеспечении нет. Если Вы выберите любой отдельный аспект ПО – его легко изменить, но сложность в том, что мы не знаем, как сделать легко исправляемым сразу все вместе. Попытки сделать что-либо легко изменяемым немного усложняют всю систему, попытки сделать все изменяемым приводят к тому, что вся система становится очень сложной. Запутанность – вот, что усложняет изменение программного обеспечения. Это и дупликация.
Суть моего замечания по поводу Аспектно-ориентированного программирования состоит в том, что мы уже имеем достаточно хорошие способы выделения аспектов программ, имеем, но не используем. Не думаю, что реальная проблема будет решена за счет лучших техник выделения аспектов. Мы не знаем, которые аспекты нужно выделять, не знаем, когда они стоят отдельного рассмотрения, а когда нет.
Программное обеспечение не ограничено физическими законами мира как те же здания. Оно ограничено фантазией, дизайном, организацией. Если коротко – оно ограничено человеческими свойствами, не характеристиками мира. «Мы встретили врага, и он оказался нами».
Мартин Фаулер, ведущий научный сотрудник в ThoughtWorks
Комментарии (43)
africaunite Автор
28.02.2018 14:39В детстве я мечтал стать агрономом и, возможно из-за этого, аналогия с процессом выращивания деревьев мне казалась более подходящей, чем строительство, для большинства успешных проектов, в которых довелось принять участие. С удовольствием почитал бы статью "Кому нужен садовник?".
White_Scorpion
28.02.2018 15:20Это уже наверное боян, но мало ли кто не видел…
BalinTomsk
28.02.2018 18:54---В одном из наших проектов, администратор БД Прамод Садалаж (Pramod Sadalage) придумал систему, позволявшую нам менять схему (и переносить данные) без проблем (см. тут). Сделав это, он исключил схему БД их разряда архитектурных элементов
Мне всегда казалось что DB Administrator не то что к разработке софта отношения не имеет никакого, но даже должности такой может не быть в компании разработчике.
DBA — это на продакшине, у разработчиков архитект и девелопер.
А на ссылке — там нет архитекторных решений, а просто автоматизировання поддержка разработки. Судя по имплементации выльется позже в плохую производительность.africaunite Автор
28.02.2018 19:27Может не быть должности, но может быть роль. И потом — это 2003 и архитектура корпоративных приложений. ;)
По поводу того, что нет архитектуры — ровно об этом и фраза автора. Убираем проблему, не нужно сваливать на архитектуру. Те же микросервисы, кстати, дать инструмент и отодвинуть многие архитектурные решения на уровень выше.
Добавил ссылку на перевод той статьи об эволюционом дизайне БД, кстати, спасибо, что напомнили (https://habrahabr.ru/post/312970/).
Busla
01.03.2018 13:08Микросервисы — это тоже часть архитектуры.
В том виде, как их преподносят — Kubernetes и т.п., исходят из принципа «пользователь утрётся» — это допустимо для публикации и просмотра котиков интернете: рубанул оркестратор контейнер с которого фотка скачивалась — ничего страшного пользователь обновит страницу и всё будет чики-пуки. А какая-нибудь медицинская система кого-то убъёт с таким подходом. — кто-то должен об этом подумать и принять решение. Этот человек — архитектор системы. А система — это серверы, данные, базы данных, протоколы, сети, API, представления о бизнес-процессах, знание best practice в смежных областях. Он, конечно, может совмещать эту роль с работой программиста, но совершенно не обязательно.africaunite Автор
01.03.2018 13:59Абсолютно согласен, у меня там выпало слово "попытка" перед "дать инструмент и отодвинуть решения на уровень выше". Но суть в том, что это всегда было и будет одним из основных способов борьбы со сложностью — стараться абстрагироваться и создавать новые инструменты, которые помогут уводить принятие решений на уровень выше, чтобы не засыпало и все еще иметь возможность управлять все расширяющейся пирамидой под.
Иногда такие инструменты нифига не помогают, конечно ;) Особенно если энтропия берет вверх еще до очередного слоя и пирамида сама расползается на всех нижележащих уровнях.
lexpenz
01.03.2018 14:00+1Мне нравится определение от Uncle Bob, которое примерно звучит так: «Хорошая архитектура — это то, что позволяет откладывать принятие основных решений до того момента, когда их действительно необходимо принимать»
VitalyZhandarov
01.03.2018 14:00+1Здесь говорится про «это ж не подвал здания, а ПО, все можно поменять».
А как же трудозатраты на изменения? А также списанные в убыток трудозатраты на те блоки и части, что не стали использовать, а выкинули и переписали?
Молчу уже про сроки…
Была же на хабре ровно два года назад внятная статья Создание архитектуры программы или как проектировать табуретку
Отличный обзор. Там и про критерии, и много ссылок на другие книги ресурсы и статьи, рекомендую.
Но кому лень лезть читать, основная мысль вот (и с ней я, как бизнесмен, недавно по уши влезший в разработку ПО, согласен на «стопицот процентов»):
Хорошая архитектура это прежде всего выгодная архитектура, делающая процесс разработки и сопровождения программы более простым и эффективным.
Программу с хорошей архитектурой легче расширять и изменять, а также тестировать, отлаживать и понимать.
Собственно, такая постановка вопроса об архитектуре — когда программа не «вещь в себе в вакууме», а находится в реальном мире, имеет цену создания, эксплуатации и сопровождения- дает свои плоды.
И наводит заранее на мысли про риски увязнуть, риски переписывать бесконечно, риски больше или меньшей зависимости от разработчика, и т.д., и т.п.
Отсюда в статье и появляются такие критерии для архитектуры, как хорошая читаемость кода, или что не требуется много менять в программе, если меняется один блок, и пр.
Если то, как организована программа, эти все риски и затраты предотвратить или существенно уменьшить помогает — это хорошая архитектура.
Ну и конкретика, из чего архитектура состоит в техническом плане, тоже подробно разложено в упомянутой статье.africaunite Автор
01.03.2018 14:05Да, это понятно. Но кто такие архитекторы?
VitalyZhandarov
01.03.2018 14:06Те, кто делает такую архитектуру ПО, которая бы на практике отвечала бы критерию «выгодная архитектура, делающая процесс разработки и сопровождения программы более простым и эффективным»
VitalyZhandarov
01.03.2018 14:08+1Я прагматик, и для меня строитель не тот, кто умеет — а тот, кто строит.
Аналогично архитектор — тот, кто делает такую архитектуру, которая снижает риски и убытки разработки, эксплуатации и сопровождения.africaunite Автор
01.03.2018 14:17То есть каждый разработчик (строитель), я правильно понимаю?
VitalyZhandarov
01.03.2018 14:28Строитель — это пример.
Речь не о «каждом разработчике», я отвечаю на ваш вопрос «кто такой архитектор».
Если каждый разработчик принимает решения о том, как должен быть организован код — то он в этой части архитектор. И совершенно точно, кто-то конкретный должен отвечать за то, что ВЕСЬ код организован так, чтобы снижать риски и убытки при разработке, эксплуатации и сопровождении. Он тогда главный архитектор.VolCh
01.03.2018 15:28+1Не только и не столько код, сколько модули системы.
VitalyZhandarov
01.03.2018 15:57+1Ну да, конфигурацию и взаимоотношение /связи частей кода.
VolCh
01.03.2018 18:49Кода может вообще не оказаться в системе, если архитектор построит её на базе имеющихся на рынке или в организации решений. Чистая интеграция.
White_Scorpion
01.03.2018 20:43Иногда позволять делать архитектуру тому кто строит — это очень плохое решение. Личный опыт — работал с человеком, который делал по принципу "делать, что запросят". Давным-давно, когда я ещё не работал в компании — он сделал программку, которая обслуживала клиентов, но этих клиентов было сравнительно немного. В те времена она была достаточно современна и шустра, да и выглядела неплохо (были куплены сторонние компоненты), да и использовалась из офиса 3.5 человеками. Время шло — в программку вносились запрошенные фичи… Вносились-вносились… И на момент моего прихода получилось весёлое состояние:
- Программой уже пользовались примерно 30-40 человек, для заведения тысяч записей в БД ежедневно.
- Часть людей использовала программу с рабочих компов, а часть через терминал
- Базу данных кроме программы — начали пользовать и другие сервисы.
- Всё это нещадно тормозило
- Всё это было трудноподдерживаемо, потому что работало ещё на .NET Framework 1.1
- Использовались сторонние компоненты без сурсов, которые не позволяли применить эволюционный подход и изменить всё постепенно.
- Бизнес откровенно недоумевал на предложения — закрыть нафиг программу и написать что-то более современное под базу данных, потому что "это надо ж новые элементы покупать", это ж "работа будет стоять, а у нас бизнес идёт" и наконец "всё это лишнее, лучше добавьте нам вот ещё вот эту фичу и ещё это и чтобы 7 перпендикулярных линий, две линии синие, одна — прозрачная, а ещё одна линия — в виде котёнка".
Так моё ИМХО: Архитектор, это та "неведома зверушка", правильно применяя которую — подобные ситуации становятся невозможными. Он должен подумать о перспективах роста, должен подумать о сменяемости фреймворков, устаревании и используемости сторонних компонент и авторитетно сказать начальству — как мы будем писать ПО и обслуживать бизнес. Как мы будем прыгать с версии на версию. Как и когда.
В случае "железа" — есть сисадмин, который может "померить графики/трафики" и доказать бизнесу, что "новый сервер нужен", "нужно больше памяти" или "нужно больше золота". В случае программного обеспечения мотив перехода от одной версии фреймворка к другому именно в этот конкретный момент — штука очень важная, но абстрактная для лица непосвящённого, которое относится к коду в стиле "шо ви мене тычете этими аббревиатурами хренворков?", неочевидно. Это подразумевает лишние, с точки зрения бизнеса, затраты и простой, но при этом он нужен. И нужен человек, который выйдет и скажет — мы должны это сделать. И это — Архитектор.VitalyZhandarov
01.03.2018 21:40Я строителя приводил в качестве примера.
Со всем вышесказанным согласен — с добавкой, что хороший архитектор способен неспециалистам на пальцах объяснить, для чего.
VitalyZhandarov
01.03.2018 21:41Не авторитетно — ибо тут будет «чья глотка громче» и «кто к телу ЛПР ближе».
А внятно и объективно.White_Scorpion
01.03.2018 21:57"Объективно" обычно не получается, потому что то, что для программиста — объективная и аргументированная причина, для бизнеса — фигня какая-то. У них аргумент всех времён и народов "сейчас же всё работает, зачем что-то менять? Ты просто добавь фичу. Ну да… Подтормаживает… Ну мы сервер новый закажем". Для этого и нужна назначенный на должность — "архитектор" с возможностью принимать решение, который авторитетно сказал — "завтра мы меняем, рефакторим, пинаем пинусы, потому что ЭТО НАДО СДЕЛАТЬ", а бизнес — заткнулся и принял как должное. Должности — обычно верят. А вот когда обычный разраб приходит и начинает что-то доказывать — у бизнеса обычно принимается вид "Ах оставьте меня — я в печали".
VitalyZhandarov
01.03.2018 22:22+1На одного авторитетного толкового человека приходится пять таких же авторитетных, с апломбом, но бестолковых.
Если причина объективная — то дело скорее в неумении сформулировать это на бизнес-языке.
В противном случае, как отличить реальную необходимость стратегического плана от простой прихоти?White_Scorpion
01.03.2018 22:43Допускаю — коммуникативный дефект. Но тебя могут просто не услышать и это аргумент в пользу специальной должности. Т.е. одно дело, когда приходит человек, поставленный и говорит "Нам нужны плановые инфраструктурные изменения, чтобы избежать потенциального трындеца, на который мы обязательно нарвёмся спустя 1-2 года", а совсе другое когда тоже самое говорит обычный разраб. Почему он говорит, а другие — нет? Может быть там не всё так страшно? Может быть он — нагнетает ситуацию? У меняющих регулярно железо админов — есть графики, есть замеры. А как объективно объяснить замену фремворка №1 на версию фрейморка №2? Потому что сейчас — это будет сильно проще, чем если пару лет спустя менять №1 сразу на №5.
africaunite Автор
01.03.2018 23:11А почему разраб не может поднять свой авторитет и быть поставленным, а только лишь кто-то со стороны? Это особенность компании такая?
White_Scorpion
01.03.2018 23:21Увы. Я получил репутацию. Я бы сказал, что как минимум пара человек к моему мнению прислушиваются ибо мне есть что сказать в отдельных случаях. Но вертикаль власти есть вертикаль власти. Если неоднократные разумные доводы "за" начальством не принимаются — то на то оно и начальство. Начать же делать наперекор и, впоследствии, гарантированно огрести — увы это не по мне.
VitalyZhandarov
01.03.2018 23:57Вот это «сильно проще» и надо оценить.
— Трудозатраты на поддержку возрастут если не перейдем. -> Насколько.
— Стоимость доработок все более усложняющейся системы будет выше. -> Насколько.
— Стоимость перехода будет выше. -> Насколько.
— Риски от сохранения старой системы. -> Перечень, объем неприятностей если риск реализуется.
И другая чаша весов:
цена перехода сейчас; срок;
И глядя на это — вопрос ставить не «переходить или не переходить», а «какой критерий будет говорить, что пора»
Типа, если трудозатраты на отработку, а главное на поиск причины бага при все нарастающем количестве этих доработок — больше в три раза, чем сейчас.
Или если прогнозы на предмет того, «что надо параллельно и где поправить чтобы обновление не снесло старые доработки» начинают расходиться с фактом более чем в 1/3 случаев".
Опять же, переходить не в «лучших» традициях — «сразу скопом и потом год расхлебывать», а поэтапно. Готовить, переносить, в фоновом или полуфоновом режиме, с приостановками если ресурса на продолжение подготовки перехода в какие-то месяцы нет.
Это не коммуникативные вопросы, а управленческие, я считаю.
africaunite Автор
01.03.2018 22:00Как и предыдущий комментатор, согласен. По поводу второй части.
А по истории — можно вопросы?
Первый — Вы считаете, что аргумент бизнеса "работа будет стоять, а у нас бизнес идёт" не очень существенен?
Во-вторых, а парень бездельничал, или был загружен? Или умения действительно хватило только на первоначальную версию (успешную в рамках того момента, насколько я понимаю)
Третий, самый интересный для меня, вопрос — Вам лично удалось сыграть роль архитектора? Систему переделали, больше не тормозит? (будет или нет — не спрашиваю)White_Scorpion
01.03.2018 22:14- Аргумент существенный, потому что обслуживаем интересы бизнеса, чьи действия и обеспечивают нашу зарплату. Тут вопрос в том, что архитектурные решения надо принимать вовремя. А не когда уже всё трындец сливайте воду. А наличие архитектора — как раз и предполагает, что будет лицо, который говорит и этому решению следуют.
- Парень не бездельничал, но нужно ли мне объяснять, что в том же бизнесе, кроме получения непосредственно прибыли и премий необходимо ещё делать и такую неприятную вещь, как — платить налоги? Т.е. есть необходимые вещи, которые тем не менее стоит делать в любой сфере. В программном обеспечении — в результате тратятся ресурсы не только на написание кода, но и на поддержку оного. Улучшение.
- В профессиональном плане нет. Хотя несколько решений по результатам моей настойчивости — приняли. Это были скорее инфраструктурные вещи, н опроцесс они улучшили. Систему в результате просто слили. Она стала настолько legacy, что новый ЛПР от IT — ужаснулся. И продавил решение купить другое. Купить, а не создать самим.
africaunite Автор
01.03.2018 22:34Жму руку за пункт номер три.
А по поводу всего остального — ничего не поделаешь, мне кажется. Бизнес (клиент) is a king. Бывает, что и себе во вред, конечно, обычно-же — как может (успешный — больше, чем можно). Но главное, что Вы пробовали и тренируете навыки общения на понятном для него языке.
Иногда, кстати, купить — выгодный вариант ;)
White_Scorpion
01.03.2018 23:13Да, но следуя изменениям эволюционно — этого можно было избежать. Так сказать — следовало немножечко подумать "на перспективу" вначале иииии… Всё могло быть по другому.
Что касается "купить" — да это порой выгоднее и уж тем более быстрее, но лично меня, как программиста — это коробит. Спрашивается — зачем тогда меня нанимали? Затыкать дыры? Был достойный challenge применять навыки, но его слили кому-то другому. Ведь вначале становления — использовала компания исключительно свой софт. А из-за пролюбливания полимеров — пришлось решать проблему. Т.е. это как бы… щас вот придумал формулировку "чисто профессиональная жадность" — их деньги могли бы быть моими (хотя на самом деле это естественно не так) =))))). Но где-то в глубине души сидит червячок и грызёт. =)
oxidmod
01.03.2018 22:06Вопрос не в архитекторе, а в том как пишется код. Даже на самом свежем .net Core 2 можно напилить неподдерживаемое нечто.
VitalyZhandarov
01.03.2018 22:26+1Код пишется либо в рамках хоть какой-то структуры — либо это «спагетти-код». Структуру, которая исходно делает код ясным, и легко модифицируемым без «поворота сибирских рек» — как раз и делает тот, кого называют архитектор. Можно его так не называть — но все равно есть (или должен быть, в моих проектах уж точно должен) человек, который отвечает за минимизацию рисков и издержек при разработке, эксплуатации и сопровождении системы.
White_Scorpion
01.03.2018 22:28Я уверен, что любой программист, отрывший очень старый код (5+ лет) — может найти то, как его улучшить: чисто стилистически, появились новые структуры новой версии языка или фреймворка, новое видение, убирание старых костылей. Даже свой код. Я однажды открыл код которому было 10 лет и ужаснулся и не поверил — "как я мог это написать?! Да я был дауном!" Это совершенно нормально для того, кто развивается и растёт над собой.
Но именно и поэтому фраза "я должен просмотреть на свой работающий код и поменять его, потому что я вырос профессионально" — скорее всего вгонит бизнес в состояние ступора: "Зачем?" спросит он и будет прав. Эти изменения они накопительные, но их стоит делать. Например сообразно приведённому фреймворку .NET Framework 1.1 -> 2.0: Если мне не изменяет память в этом переходе одним из важнейших изменений было — внедрение Generic классов, позволяющих ускорить код за счёт исключения boxing/unboxing (это изменение совершенно точно было), а дополнительно были изменения в работе классов String и StringBuilder, работа с этими классами в новом фреймворке была оптимизирована и ускоряла процесс обработки строк в 3 — 10 раз. И вот эта вот вторая часть — решалась всего лишь переключением на новый фреймворк и rebuild все проекты и зависимые библиотеки. Для программиста — эти причины могут быть существенными аргументами для смены фреймворка, но вот для бизнеса — тут как посмотреть. Учитывая, что надо перетестировать считай всё приложение.africaunite Автор
01.03.2018 22:38Ну вот, у меня снова тот же вопрос, а что мешало Вам по чуть-чуть рефакторить, тестировать и потом накатывать в продакшн? (что-то точно должно было мешать)
White_Scorpion
01.03.2018 23:02+1ну если мне попадался код, который мне можно было улучшить — я так и делал, но переход на фреймворк мог вызвать серьёзные проблемы в 3rd Party коде. Мало того — в фоновом режиме я пробовал сконвертнуть, но там затронуло GUI компоненты (относительно легко решил эту проблему) и компонент протокола передачи данных. Т.е. для разбирания проблемы требовалось приличное время, которое я и хотел получить, но увы.
oxidmod
02.03.2018 11:57+1А у вас требуют отчитываться за каждую потраченную минуту? оО
White_Scorpion
02.03.2018 16:41Понимание "почему не работает то что работало" в вещи, которую нельзя отдебажить — это не одна минута.
sshmakov
Один мой друг долго ржал над фразой из начала этой книги, звучавшей в первом русском издании 2004 года примерно так «Сложная схема база данных, включающая до 200 таблиц». («We also see a complex database schema with perhaps two hundred tables and connections to packages for asset valuation and pricing.»).
africaunite Автор
Да, теперь там упоминается "несколько сотен таблиц". Но и 200 для учебного примера — достаточно сложная схема ;)