Спасибо за статью.
.
P.S. С замиранием дыхания ждал — что же с запросами полицейских, наших и международных???
Помогли ли им или послали?
Облом… Осталось как интрига… :-))))
Реальное старое железо держать, и не только в уме, а и живое. Рабочее место для тестовой эксплуатации должно быть чуть слабее среднего реального рабочего места пользователей. Ну а уж лишать ли разработчиков комфорта — мне кажется в каждом конкретном случае с разработчиками надо согласовывать :-)
Вот это «сильно проще» и надо оценить.
— Трудозатраты на поддержку возрастут если не перейдем. -> Насколько.
— Стоимость доработок все более усложняющейся системы будет выше. -> Насколько.
— Стоимость перехода будет выше. -> Насколько.
— Риски от сохранения старой системы. -> Перечень, объем неприятностей если риск реализуется.
И другая чаша весов:
цена перехода сейчас; срок;
И глядя на это — вопрос ставить не «переходить или не переходить», а «какой критерий будет говорить, что пора»
Типа, если трудозатраты на отработку, а главное на поиск причины бага при все нарастающем количестве этих доработок — больше в три раза, чем сейчас.
Или если прогнозы на предмет того, «что надо параллельно и где поправить чтобы обновление не снесло старые доработки» начинают расходиться с фактом более чем в 1/3 случаев".
Опять же, переходить не в «лучших» традициях — «сразу скопом и потом год расхлебывать», а поэтапно. Готовить, переносить, в фоновом или полуфоновом режиме, с приостановками если ресурса на продолжение подготовки перехода в какие-то месяцы нет.
Это не коммуникативные вопросы, а управленческие, я считаю.
Код пишется либо в рамках хоть какой-то структуры — либо это «спагетти-код». Структуру, которая исходно делает код ясным, и легко модифицируемым без «поворота сибирских рек» — как раз и делает тот, кого называют архитектор. Можно его так не называть — но все равно есть (или должен быть, в моих проектах уж точно должен) человек, который отвечает за минимизацию рисков и издержек при разработке, эксплуатации и сопровождении системы.
На одного авторитетного толкового человека приходится пять таких же авторитетных, с апломбом, но бестолковых.
Если причина объективная — то дело скорее в неумении сформулировать это на бизнес-языке.
В противном случае, как отличить реальную необходимость стратегического плана от простой прихоти?
Я строителя приводил в качестве примера.
Со всем вышесказанным согласен — с добавкой, что хороший архитектор способен неспециалистам на пальцах объяснить, для чего.
Строитель — это пример.
Речь не о «каждом разработчике», я отвечаю на ваш вопрос «кто такой архитектор».
Если каждый разработчик принимает решения о том, как должен быть организован код — то он в этой части архитектор. И совершенно точно, кто-то конкретный должен отвечать за то, что ВЕСЬ код организован так, чтобы снижать риски и убытки при разработке, эксплуатации и сопровождении. Он тогда главный архитектор.
Я прагматик, и для меня строитель не тот, кто умеет — а тот, кто строит.
Аналогично архитектор — тот, кто делает такую архитектуру, которая снижает риски и убытки разработки, эксплуатации и сопровождения.
Те, кто делает такую архитектуру ПО, которая бы на практике отвечала бы критерию «выгодная архитектура, делающая процесс разработки и сопровождения программы более простым и эффективным»
Здесь говорится про «это ж не подвал здания, а ПО, все можно поменять».
А как же трудозатраты на изменения? А также списанные в убыток трудозатраты на те блоки и части, что не стали использовать, а выкинули и переписали?
Молчу уже про сроки…
Но кому лень лезть читать, основная мысль вот (и с ней я, как бизнесмен, недавно по уши влезший в разработку ПО, согласен на «стопицот процентов»):
Хорошая архитектура это прежде всего выгодная архитектура, делающая процесс разработки и сопровождения программы более простым и эффективным.
Программу с хорошей архитектурой легче расширять и изменять, а также тестировать, отлаживать и понимать.
Собственно, такая постановка вопроса об архитектуре — когда программа не «вещь в себе в вакууме», а находится в реальном мире, имеет цену создания, эксплуатации и сопровождения- дает свои плоды.
И наводит заранее на мысли про риски увязнуть, риски переписывать бесконечно, риски больше или меньшей зависимости от разработчика, и т.д., и т.п.
Отсюда в статье и появляются такие критерии для архитектуры, как хорошая читаемость кода, или что не требуется много менять в программе, если меняется один блок, и пр.
Если то, как организована программа, эти все риски и затраты предотвратить или существенно уменьшить помогает — это хорошая архитектура.
Ну и конкретика, из чего архитектура состоит в техническом плане, тоже подробно разложено в упомянутой статье.
.
P.S. С замиранием дыхания ждал — что же с запросами полицейских, наших и международных???
Помогли ли им или послали?
Облом… Осталось как интрига… :-))))
— Трудозатраты на поддержку возрастут если не перейдем. -> Насколько.
— Стоимость доработок все более усложняющейся системы будет выше. -> Насколько.
— Стоимость перехода будет выше. -> Насколько.
— Риски от сохранения старой системы. -> Перечень, объем неприятностей если риск реализуется.
И другая чаша весов:
цена перехода сейчас; срок;
И глядя на это — вопрос ставить не «переходить или не переходить», а «какой критерий будет говорить, что пора»
Типа, если трудозатраты на отработку, а главное на поиск причины бага при все нарастающем количестве этих доработок — больше в три раза, чем сейчас.
Или если прогнозы на предмет того, «что надо параллельно и где поправить чтобы обновление не снесло старые доработки» начинают расходиться с фактом более чем в 1/3 случаев".
Опять же, переходить не в «лучших» традициях — «сразу скопом и потом год расхлебывать», а поэтапно. Готовить, переносить, в фоновом или полуфоновом режиме, с приостановками если ресурса на продолжение подготовки перехода в какие-то месяцы нет.
Это не коммуникативные вопросы, а управленческие, я считаю.
Если причина объективная — то дело скорее в неумении сформулировать это на бизнес-языке.
В противном случае, как отличить реальную необходимость стратегического плана от простой прихоти?
А внятно и объективно.
Со всем вышесказанным согласен — с добавкой, что хороший архитектор способен неспециалистам на пальцах объяснить, для чего.
Спасибо!
Вновь написанного кода, да.
Речь не о «каждом разработчике», я отвечаю на ваш вопрос «кто такой архитектор».
Если каждый разработчик принимает решения о том, как должен быть организован код — то он в этой части архитектор. И совершенно точно, кто-то конкретный должен отвечать за то, что ВЕСЬ код организован так, чтобы снижать риски и убытки при разработке, эксплуатации и сопровождении. Он тогда главный архитектор.
Аналогично архитектор — тот, кто делает такую архитектуру, которая снижает риски и убытки разработки, эксплуатации и сопровождения.
А как же трудозатраты на изменения? А также списанные в убыток трудозатраты на те блоки и части, что не стали использовать, а выкинули и переписали?
Молчу уже про сроки…
Была же на хабре ровно два года назад внятная статья Создание архитектуры программы или как проектировать табуретку
Отличный обзор. Там и про критерии, и много ссылок на другие книги ресурсы и статьи, рекомендую.
Но кому лень лезть читать, основная мысль вот (и с ней я, как бизнесмен, недавно по уши влезший в разработку ПО, согласен на «стопицот процентов»):
Собственно, такая постановка вопроса об архитектуре — когда программа не «вещь в себе в вакууме», а находится в реальном мире, имеет цену создания, эксплуатации и сопровождения- дает свои плоды.
И наводит заранее на мысли про риски увязнуть, риски переписывать бесконечно, риски больше или меньшей зависимости от разработчика, и т.д., и т.п.
Отсюда в статье и появляются такие критерии для архитектуры, как хорошая читаемость кода, или что не требуется много менять в программе, если меняется один блок, и пр.
Если то, как организована программа, эти все риски и затраты предотвратить или существенно уменьшить помогает — это хорошая архитектура.
Ну и конкретика, из чего архитектура состоит в техническом плане, тоже подробно разложено в упомянутой статье.
Благодарности за перевод и публикацию