Биография автора приведена ранее.
Архитектор прежде всего разработчик Майк Браун
который не был бы хирургом? Даже достигнув того, что может считаться венцом их карьеры, люди, занимающие такие должности, продолжают осваивать новые разработки в своей области. Мы, архитекторы программного обеспечения, обязаны соответствовать тем же стандартам.
Как бы качественно ни было спроектировано решение, успех его реализации в существенной степени определяется тем, сможете ли вы привлечь на свою сторону разработчиков. А самый быстрый способ сделать это завоевать их уважение и доверие. Всем известно, как проще всего завоевать доверие разработчика: ваш код ваша «визитная карточка». Если разработчики будут знать, что вы не какой-то абстрактный мечтатель, не способный написать ни строчки кода, они будут меньше ворчать по поводу ухищрений, на которые вы «заставляете» их идти для отображения данных на странице, ведь вы способны с полным на то основанием сказать: «Можно сделать проще, всего лишь привязав датасет к гриду», и им будет нечего возразить.
И хотя это не является моей непосредственной работой, я часто беру на себя некоторые наиболее сложные задачи. Во-первых, это интересно и помогает мне поддерживать на уровне свои навыки программирования; во-вторых, этим я наглядно показываю своим разработчикам, что мои слова не пустое сотрясание воздуха.
Архитектор должен стремиться к созданию решения осуществимого, удобного в сопровождении и, конечно, отвечающего сути задачи. Одним из критериев осуществимости решения является возможность адекватно оценить объем работы и усилия, необходимые для реализации элементов решения. Поэтому я считаю, что если вы проектируете систему, вы должны быть способны ее реализовать.
Майк Браун (Mike Brown) ведущий разработчик в компании Software Engineering Professionals, Inc. (). Обладает 13-летним опытом работы в сфере информационных технологий, включая 8 лет разработки корпоративных решений для разнообразных вертикальных рынков. Является учредителем группы пользователей Indianapolis Alt.NET, соучредителем WPF Disciples, а также организатором группы профессиональных пользователей Indy Arc.
Окупаемость как фактор проектирования Джордж Маламидис
Одним из показателей успешности инвестиций является окупаемость (ROI, Return on Investment). Например: мы предполагаем, что дополнительные затраты времени на создание тестов уменьшат количество ошибок в следующем выпуске приложения. Размер инвестиций в этом случае определяется временем, потраченным на написание тестов, а прибыль это время, сэкономленное на исправлении ошибок в будущем, плюс удовлетворение клиентов, работающих с более
системы во время эксплуатации. Например, система с «разросшейся» архитектурой, опутанной уродливыми зависимостями, в эксплуатации часто ведет себя, как зверь в клетке. Подумайте о других (обычно менее опытных) разработчиках, которым придется исправлять ошибки в вашей программе и отлаживать код.
В кругах разработчиков не любят термин «унаследованный», но на самом деле этот ярлык несет на себе любая программная система. И в этом нет ничего плохого, потому что такое определение может означать лишь то, что ваша система долговечна, соответствует ожиданиям пользователей и обладает коммерческой ценностью. Если программную систему никогда не называли унаследованной, ее, скорее всего, отправили пылиться на полке, так и не запустив, а это вряд ли можно считать свидетельством удачной архитектуры.
Дейв Андерсон (Dave Anderson) главный специалист по разработке ПО в компании Liberty IT (Белфаст), которая поставляет IT-решения для компании Liberty Mutual, входящей в список Fortune 100. Дейв обладает более чем 10-летним опытом разработки ПО для многих ведущих IT-компаний в разных отраслях и странах.
Когда видите единственное решение, спросите других Тимоти Хай
Создание архитектуры программного обеспечения сводится к поиску наилучшего решения задачи при некоторых заданных ограничениях. Редко когда удается обеспечить выполнение всех требований и уложиться во все ограничения с первым же решением, которое пришло вам в голову. Обычно приходится идти на компромиссы, выбирая решение, лучше всего удовлетворяющее тем требованиям, которые определяются важнейшими приоритетами.
Если вы видите только одно решение текущей проблемы, это означает, что у вас отсутствует свобода выбора для поиска таких компромиссов. Вполне возможно, что это единственное решение окажется неудовлетворительным для некоторых заинтересованных в проекте сторон. Это означает также, что при смене приоритетов, обусловленной изменениями бизнес-окружения, у вашей системы не будет возможности адаптироваться к новым требованиям.
Такая ситуация крайне редко возникает из-за реального отсутствия альтернатив. Гораздо более вероятное объяснение неопытность архитектора в предметной области конкретной задачи. Если вы знаете, что это относится к вам, не постесняйтесь обратиться за советом к кому-нибудь из более опытных в этом вопросе коллег.
Другое, более коварное проявление этой проблемы встречается при проектировании архитектуры «по привычке». Архитектор может иметь богатый опыт применения одного архитектурного стиля (например, трехуровневая система типа клиент-сервер), но ему не хватает знаний, чтобы определить, когда этот стиль неуместен. Если вы оказались в ситуации, когда решение известно вам сходу, без сопоставления с другими возможными вариантами, задержитесь, сделайте шаг назад и попытайтесь придумать другой способ решения той же задачи. Если это не получается, возможно, стоит обратиться за помощью.