Когда для проекта не требуется разработчик приложений?

Question

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

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

Answer 1

Если у вас уже есть шаблон архитектуры / системы, который позволит вам построить свой проект, вам вообще не понадобится архитектор.

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

Ключевым моментом является получение качественных сценариев и умение применять методы / шаблоны проектирования, которые соответствуют этим качествам. Или изобретать что-то на лету, если нужно.

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

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

UPDATE: Я думал, что сопоставлю некоторые мысли, высказанные в других ответах.

• Архитекторы являются центральным коммуникационным пунктом.
• Архитекторы сообщают о дизайне - хорошие делают это эффективно.
• Архитекторы привносят необходимый опыт в продукт / проект.
• Более крупные конструкции нуждаются в более крупных проектах, большем количестве планирования, прототипирования и т. Д. И нуждаются в ком-то, чтобы гарантировать, что «правильная система построена правильно».
• В отличие от разработчиков, архитекторы считают разработчиков заинтересованными сторонами и внедряют тактики для решения их желательных не-исполняющих качеств (масштабируемость, ремонтопригодность, тестируемость, возможность повторного использования, конфигурируемость (MeTRiCS)).

Answer 2

Я собираюсь использовать аналогию здесь, используя дома. Не так давно (относительно) люди могли строить дома без архитектора или архитектурных планов. Они рубили дрова, использовали усвоенные навыки, чтобы рубить и строгать доски и строить свои дома. Соборы, замки и т.д .... У них были архитекторы и инженеры, конечно. Но в подавляющем большинстве случаев люди строили дома, используя навыки, переданные по наследству.

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

Современные жилые дома имеют инфраструктуру для подключения, кодексы, которые должны соблюдаться, и т. Д. Нам нужно, чтобы наши жилищные проекты были созданы или одобрены архитектором, прежде чем их можно будет построить. Архитектор позаботится о том, чтобы все было в порядке и что дом будет стоять и пригоден для жилья.

---

Приложения не отличаются. Мы не живем в мире, где сложные структуры могут уйти, не подвергаясь архитектуре. Конечно, я могу написать базу данных для своей библиотеки в качестве тривиального упражнения; Я также могу создавать книжные полки для своей библиотеки, не вовлекая архитектора. Но как только вы выйдете за рамки простых структур, вы должны быть абсолютно уверены, что кто-то обращает внимание на общую картину - собирается ли ваша структура (дом или приложение) делать то, что ей нужно, хорошо ли она играет с другими, и он соответствует правилам, установленным при его строительстве.

Answer 3

Определите «Требовать».

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

Преимущества наличия Application Architect, по моему опыту, значительно превосходят и перевешивают недостатки, и чем больше проект, тем больше эффект.

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

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

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

Простой факт заключается в том, что роль [i] - это [/ i] то, что вы захотите занять. Как вы сидите, зависит только от вас, но самый проверенный и самый эффективный метод - это заставить человека сделать это.

Answer 4

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

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

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