Как мне прекратить разработку и начать проектирование этого проекта, как это было предложено моим руководителем? [закрыто]

Я младший разработчик (~ 3 года опыта), и на моей работе мы находимся в процессе разработки новой системы. Мой ведущий разработчик будет главным архитектором, однако он бросил мне вызов попробовать самостоятельно спроектировать систему (параллельно).

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

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

Как выйти из режима конструктора программного обеспечения и начать думать больше как архитектор?

Вот несколько примеров «дизайнов», которые я придумал, и которые не были сочтены актуальными для архитектуры:

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

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

Вот некоторые более конкретные детали о проекте :

• Проект, который мы проектируем, является веб-приложением.
• Я оцениваю около 10-100 тысяч строк кода.
• Мы начинаем. Наша инженерная команда составляет около 3-5 человек.
• Самое близкое, с чем я мог сравнить наше приложение - это легковесная CMS. Он имеет аналогичную сложность и имеет дело в основном с загрузкой и выгрузкой компонентов, управлением компоновкой и модулями в стиле плагинов.
• Приложение AJAX-Y. Пользователь загружает клиент один раз, а затем запрашивает данные, когда они ему нужны, с сервера.
• Мы будем использовать шаблон MVC.
• Приложение будет иметь аутентификацию.
• Мы не очень заботимся о поддержке старых браузеров (вот так!), Поэтому мы стремимся использовать новейшие и лучшие из них, которые будут и будут выходить. (HTML5, CSS3, WebGL ?, Расширения Media Source и многое другое!)

Вот некоторые цели проекта :

• Приложение должно масштабироваться. В ближайшем будущем число наших пользователей будет составлять от сотен до тысяч, но мы планируем от десятков тысяч до миллионов и более.
• Мы надеемся, что приложение будет вокруг навсегда. Это не временное решение. (На самом деле у нас уже есть временное решение, и то, что мы проектируем, является долгосрочной заменой того, что у нас есть).
• Приложение должно быть безопасным, так как оно может иметь контакт с конфиденциальной личной информацией.
• Приложение должно быть стабильным. (В идеале это было бы стабильно на уровне gmail, но это не обязательно должно быть на пределе марсохода.)

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

Сказав все это, вам нужен совет для ситуации, в которой вы находитесь. Существует целый мир программной архитектуры, бумаг, книг, конференций, но вы, как правило, ищете шаблоны и абстракции. Без более подробной информации о проекте я могу привести только широкий пример. Например, если вы работали в интеграции, есть сервис-ориентированная архитектура ( SOA)) шаблон, в котором вы разделяете части системы на «сервисы», чтобы вы могли работать с каждой частью определенным образом, в веб-программе это часто затем реализуется как веб-сервисы (хотя не следует ограничиваться этим) и в последнее время рост RESTful API с JSON, еще раз, я бы сказал, это дизайн, основанный на архитектуре SOA. Я бы сказал, что Model, View, Controller (MVC) - это еще один пример общепринятого шаблона архитектуры, который разделяет ответственность компонентов системы, позволяя заменять части, содержать ошибки и тестирование.

С уровня 10 000 футов, если вы можете нарисовать это на доске и объяснить это компетентному программисту, который не работает в вашей области и не знает ваш язык программирования и текущие детали реализации, то это, вероятно, архитектура. Если вы можете написать об этом книгу, которая будет интересна всем, кто находится за пределами вашей компании, то, вероятно, это архитектура. Если вы обнаружите, что вы объясняете детали и не можете обобщить их для других баз кодов / компаний / отраслей, то это, вероятно, дизайн.

Я согласен, что два примера, которые вы приводите, - это дизайн кода, а не архитектура. Во-первых, потому что я думаю, что когда вы говорите, что придумали «алгоритм» для загрузки ресурсов, я думаю, вы имеете в виду, что вы разработали набор инструкций для выполнения этой задачи, а не то, что вы разработали новый алгоритм, которому они будут учить в течение 1-го года. COMSC в следующем году. Во втором примере, опять же, я согласен, что это дизайн. Если бы вы показали мне одну из этих идей, я бы не смог использовать их в своем проекте случайного программного обеспечения. Вы должны перейти на «более высокий уровень», объектно-ориентированный (OO) в Java, а не чтобы класс клиента был подклассом класса Person. Даже говорить об исключениях в целом можно было бы считать слишком низким уровнем (слишком близко к реализации).

Чтобы попытаться рассмотреть специфику, которую вы перечислите, я думаю, что вы должны подумать о том, как спроектировать веб-систему CMS. В Wordpress есть кодекс архитектуры сайта, в котором они много говорят о деталях реализации дизайна, но из этого поста ясно, что их основная архитектура сосредоточена на том, чтобы сделать Wordpress расширяемым темами. Разработка четкого интерфейса для темы, которая могла бы быть написана кем-то из компании, была явно архитектурным решением, которое они приняли. Это те вещи, о которых стоит подумать при разработке вашего «долгосрочного» (не временного) решения, чтобы все решения по проектированию и реализации, принимаемые во время разработки (всеми разработчиками, а не только архитектором) соответствуют этой идее.

Другие примеры архитектуры для вашей ситуации:

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

Может быть, попробуйте нарисовать всю систему на доске. Попробуйте на разных уровнях детализации, первая доска может быть GUI-> dispatcher-> backend-> DB или что-то еще, а затем углубляться в детали до тех пор, пока вы не начнете использовать местоимения.

Различие между этими двумя идеями действительно важно там, где я работаю.

То, что вы называете «архитектурой», мы называем «программированием на английском». Это отчасти важно, потому что если вы не можете описать это непрограммисту, значит что-то не так. Возможно, вы недостаточно хорошо понимаете проблему, или, может быть, вы решаете «призрачную» проблему (здесь не обсуждается).

Термины, используемые для этих двух различных аспектов дизайна, часто различны, но принципы легко узнаваемы повсюду. Один аспект (в вашем случае архитектор, в моем случае дизайнер) программирует на английском языке, тогда как другой (в вашем случае «дизайнер», в моем случае «разработчик») программирует на определенном языке. Они также довольно часто различаются как «дизайн» и «реализация». «Дизайн» - это то, что он должен выполнить, а «реализация» - это код, который делает это возможным.

Несколько примеров из того, над чем я работал:

Архитектура одной программы такова: нам нужен централизованный менеджер или концентратор, к которому мы можем легко добавлять модули. Этот менеджер будет распространять события на все зарегистрированные модули. Модуль может зарегистрироваться в Менеджере событий и, таким образом, публиковать события для остальной части системы и получать события, о которых он заботится. Каждый модуль имеет «почтовый ящик», который он может проверять и очищать по своему усмотрению. Это позволило бы нам разместить новые модули, которые мы еще не знаем, в которых мы нуждаемся.

Там нет кода. Может быть написано на любом языке. Реализация не продиктована этим описанием.

Архитектура другого проекта такова: нам нужен способ надежного запуска и остановки других программ, не дожидаясь их. У нас может быть менеджер, который отвечает за конкретную программу. Мы можем просто сказать ему запустить или остановить его программу, и менеджер позаботится об этом. Если эту другую программу попросят остановить и не произойдет в течение заданного времени, менеджер знает, как заставить ее остановиться, и исправит беспорядок. Программа не запускается и не останавливается кем-либо еще, и у менеджера можно спросить, работает ли его программа, остановлена ​​или ожидает остановки. Это позволяет нам заниматься другими делами, которые нам нужно делать, и в то же время запускать и останавливать эти другие программы должным образом.

Опять же, здесь ничто не диктует реализацию, хотя некоторые реализации явно более полезны, чем другие.

Разница между дизайном (то, что мы бы назвали шаблонами или реализацией) и архитектурой (что мы назвали бы дизайном) заключается в том, что один из них решает проблему кодирования / реализации, а другой - реальную проблему.

Может быть, это поможет. Я всегда рассматривал старшинство инженера как вопрос того, насколько большую проблему они могут решить самостоятельно.

Грубо говоря, передать идею:

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

• Разработчик среднего уровня - это тот, кто может взять описание некоторой части приложения и заставить его работать в контексте этого приложения.

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

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

... но это не жесткие и быстрые правила. И некоторые люди выходят за ворота как «старшие» ИМХО, даже если им приходится проводить какое-то время с другим названием.

Архитектор просит рассмотреть проблему более широко, чем это. Если вам пришлось собрать несколько приложений, чтобы система работала:

• Какие приложения и услуги вам понадобятся?
• Какие части взаимодействуют с клиентами, а какие взаимодействуют друг с другом?
• Как они будут общаться?
• Где они будут хранить данные?
• Где риски неудач?
• Как вы обеспечите надежность?
• Как вы будете обеспечивать безопасность?

Таким образом, в некотором смысле техническая архитектура похожа на архитектуру здания. Это макет или план. Он показывает, что нужно для различных частей, как они держатся вместе, и не менее важно, почему .

(Кстати, у меня была похожая кривая роста, объясненная мне для архитекторов, начиная от разработки семейства связанных приложений или набора очень сложных функций, до определения технического направления для группы, до принятия стратегических технических решений для всей организации .)

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

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

По аналогии с этой аналогией вы можете думать о роли архитектуры как о том, что вся система выглядит как волшебный ящик. Итак, если вы возьмете Gigantic Glass Box и поместите внутри себя клиентов, клиентские приложения, брандмауэр, уровень обслуживания, базу данных и даже разработчиков, то, как архитектор, вы будете зациклены на том, как сделать этот огромный системный блок. работать хорошо .

Точная разница между «дизайном» и «архитектурой» немного субъективна, и есть некоторые совпадения. Тем не менее, это разница, насколько я понимаю:

Архитектура смотрит на концепции высокого уровня. Кто актеры в системе? Каковы основные объекты и какие за что отвечают? Когда я думаю об архитектуре, я думаю о Visio, а не о коде.

Например, система событий может иметь менеджер событий, который принимает входящие события и отправляет их обработчикам событий. Идея потоков, асинхронных, синхронных и других понятий более низкого уровня здесь не вступает в игру. MVC является еще одним примером: конкретные детали не указываются на высоком уровне взаимодействия этих трех частей, только то, что есть три отдельных вопроса, которые обрабатываются отдельными пакетами кода.

Проектирование включает в себя создание прототипов, создание набросков интерфейсов кода, скелетов кода и т. Д. Он находится между абстрактной архитектурой и работой низкоуровневой «обезьяны кода».

В каркасе событий дизайн может сказать «событие использует этот интерфейс» и «существует пул потоков, который менеджер событий использует для отправки событий работникам». Проектом для MVC может быть «использовать Hibernate для модели, Spring для контроллера и GWT для представления».

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

Надеть архитектуру - значит очистить свой разум от кода и мыслить объекты на доске. Подумайте об объектах, пакетах, инфраструктурах и потоках сообщений между ними. Если вы думаете хотя бы об одной строке кода, вы делаете это неправильно. Не увязайте в чем-то вроде «о, это сообщение может быть строкой, или использовать SOAP, или что-то еще». На этом уровне достаточно того, что общение происходит. Детали не имеют значения.

Если я могу добавить что-нибудь здесь, это так: не думайте, код . Вообще.

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

Для вашего конкретного варианта использования, на мой взгляд, было бы больше архитектурных вопросов:

• Почему вы используете MVC? Это все, что ты знаешь? Есть ли лучшие образцы для использования? Зачем?
• Какие рамки вы будете использовать и почему ?
• Как вы будете масштабировать? Не в коде, потому что это еще не имеет значения. Какие будут условия для горизонтального масштабирования; какой сервис (AWS) вы будете использовать для этого?
• Как будет выполняться аутентификация? Не в коде: вы будете генерировать случайный, уникальный токен при каждом запросе и проверять его на соответствие ожидаемому токену? Не думай, как ты это сделаешь в коде. Подумайте, зачем вы это делаете - потому что это можно сделать практически на любом веб-языке.

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

Подумайте обо всех операциях (т. Е. Сценариях использования), которые может выполнять ваша система. Для каждой операции запишите, что происходит с точки зрения вашего бизнес-домена для каждой операции. Вы должны говорить только с точки зрения вашей проблемной области и не описывать детали реализации. Нарисуйте большой блок и назовите его System. Комбинация этого «большого блока» и описания операций является архитектурой системы самого высокого уровня.

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

Таким образом, вы придерживаетесь той же общей идеи, что и подход «большой блок», только начинаете добавлять «подблоки», необходимые для выполнения каждой операции. Эти «подблоки» часто называют классами домена или модулями. Они легко идентифицируются с помощью ваших описаний операций (из подхода большого блока) и построения диаграмм последовательности. Они называются классами домена, потому что они не предназначены для того, чтобы быть «реальными» классами, но они предназначены для описания вашей системы с точки зрения проблемной области вашей системы.

Конечный результат создания всей диаграммы последовательности и идентификации всех «подблоков» состоит в том, что теперь у вас есть список классов домена и их списки операций. Обычно это приводит к довольно удобной программной архитектуре, где каждый из «подблоков» / модулей может быть разнесен разным разработчикам для разработки и реализации.

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

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

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

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

Я считаю, что это помогает описать проблему, которую вы пытаетесь решить в первую очередь. Каковы требования? Каковы ограничения? Можете ли вы поговорить с заинтересованными сторонами, чтобы узнать эти требования?

Это может помочь, если вы сможете описать свои собственные цели дизайна. Нужно ли масштабировать ваше решение или достаточно дизайна для одного пользователя? Как долго ваше решение должно оставаться в силе? Это одноразовое решение или долгосрочное инфраструктурное решение? PErhaps также важен: каковы допустимые пределы вашей архитектуры?

А поскольку это учебный опыт, не бойтесь задавать вопросы, даже если они глупые.