Тогда вам и вся остальная статья будет неподвластной.
Можно просто заменить технологию на мороженое и все будет ок (плюс некоторые переделки): Не купите мороженого, если вам хорошо, когда мороженого нет.
Что эквивалентно: "не купите мороженого, от отсутствия которого вы не впадете в кому".
Говорить, что архитектура и алгоритм не одно и тоже, тоже самое, что и сказать, что холодильник и еда — это не одно и тоже. Имею в виду, что «да это же и моей бабушке понятно, черт возьми, так в чем же проблема»? А проблема в том, что вы пытаетесь показаться умным, может и не на голом месте, может и вы разработали несколько успешных проектов или что-то в этом роде, но прощу, не пытайтесь доказать разработчику, что процесс — это код и данные.
Где в этих стандартах говорится о проектировании ПО?
>> … и ПО по ним иногда требуется сертифицировать...
Это совсем другое, если некий ГОСТ требует, чтобы военное ПО было безопасным, это не значит, что этот ГОСТ рассказывает как проектировать это само ПО.
Такое ощущение, что вы смотрели только «трейлеры» к предметам, а самого «фильма» так и не смотрели.
Слушайте, вы сильно смахиваете на Шелдона Купера тем, что не различаете сарказм от не-сарказма. Мне и вправду нечего вам сказать, разве что жалеть времени, которую потратил на чтение и ответы к вашим комментариям. И напоследок, пожалуйста, не разбросайтесь умными аббревиатурами. Если бы на архитектуру софта был бы единый стандарт, то мы бы с вами не прочитали бы этот и многочисленные посты такого рода, и не впали бы в кому диалог.
Если будете отвечать и на этот комментарий, то прошу прежде досконально обьяснить, что вы понимаете под изучением ГОСТ, ISO, IEEE стандартов на архитектуру ПО. Уж очень прощу.
Интерфейс тоже не похоже на них, и вообще, может вы и начнете «долго рассуждать, что правильно, а что нет», но до этого предлагаю перечитывать мой комментарий выше как минимум 6 раз и пытаться вникать, вникать, вникать…
А кто-то будет долго рассуждать, как правильно нужно распределять ресурсы, как проектировать и т.д. А в итоге окажется, что кто-то просто пересказывает Макконнела (ну или Фаулера, кто там этой, как его, архитектурой балуется?).
Ничего нового здесь нет. Если сравнить со «старыми» архитектурными решениями, то смысл «разработки через страдания» сведется к разработке прототипа системы, который потом можно будет выбросить и начать разработку с нуля, основываясь на опыте и знаниях о предметной области, когда разрабатывался прототип.
Только дело вот в чем, или даже больше — дела.
1. Если вы разрабатываете проект для вас, то есть хотите реализовать некую идею, то ограничений на время у вас нет, если только вы не ставите их, а если таковых нет — то можно бесконечно долго совершенствовать проект, делая красивее, делая быстрее, делая… Но этого никогда не бывает, лишь в редких случаях мы возвращаемся к работающему, но «уродливому» коду, чтобы, выражаясь мягко, отрефакторить.
2. Если вы работаете над проектом в некой фирме, то у вас конкретные проблемы — со сроком, в основном. В идеале, проект должен быть разработан через, описанное выше, прототип. Но проблема в том, что «почти» всем фирмам не хватает времени/денег/нервов, и вскором времени прототип превращается в рабочий бета и все последующие разработки ведут к исправлению багов… прототипа.
3. Чтобы превосходно представить предметную область нужно очень много времени (мы же говорим о достаточно больших и сложных системах), а время нужно не только на теоритические размышления или митинги (которые так любят idle-разработчики), а еще и на постоянные разработки для увеличения знаний. По статистике, это время превосходит в 3-4 раза времени, которое фирма предполагает потратить на разработку готового продукта.
Вот и идите разрабатывайте через страдание или как его там, лично я разрабатываю через «рвание жопы», «очередной хреновый митинг», «выслушивание трепа idle-коллег», «фикс опупенного количества багов, исправление которых явлвяется причиной появлению других»…
P. S. За статью/перевод благодарен, отличная работа.
Все просто — 0.3 рубля за каждый лайк, ну или тоже самое только за «Отлично! Спасибо!».
Это фраза уже стала эпической — «Отлично! Спасибо!», как-то смахивает на «Щастя! Здoровья!» :)
Можно просто заменить технологию на мороженое и все будет ок (плюс некоторые переделки):
Не купите мороженого, если вам хорошо, когда мороженого нет.
Что эквивалентно: "не купите мороженого, от отсутствия которого вы не впадете в кому".
>> … и ПО по ним иногда требуется сертифицировать...
Это совсем другое, если некий ГОСТ требует, чтобы военное ПО было безопасным, это не значит, что этот ГОСТ рассказывает как проектировать это само ПО.
Такое ощущение, что вы смотрели только «трейлеры» к предметам, а самого «фильма» так и не смотрели.
комудиалог.Если будете отвечать и на этот комментарий, то прошу прежде досконально обьяснить, что вы понимаете под изучением ГОСТ, ISO, IEEE стандартов на архитектуру ПО. Уж очень прощу.
А так, я могу лишь…
Только дело вот в чем, или даже больше — дела.
1. Если вы разрабатываете проект для вас, то есть хотите реализовать некую идею, то ограничений на время у вас нет, если только вы не ставите их, а если таковых нет — то можно бесконечно долго совершенствовать проект, делая красивее, делая быстрее, делая… Но этого никогда не бывает, лишь в редких случаях мы возвращаемся к работающему, но «уродливому» коду, чтобы, выражаясь мягко, отрефакторить.
2. Если вы работаете над проектом в некой фирме, то у вас конкретные проблемы — со сроком, в основном. В идеале, проект должен быть разработан через, описанное выше, прототип. Но проблема в том, что «почти» всем фирмам не хватает времени/денег/нервов, и вскором времени прототип превращается в рабочий бета и все последующие разработки ведут к исправлению багов… прототипа.
3. Чтобы превосходно представить предметную область нужно очень много времени (мы же говорим о достаточно больших и сложных системах), а время нужно не только на теоритические размышления или митинги (которые так любят idle-разработчики), а еще и на постоянные разработки для увеличения знаний. По статистике, это время превосходит в 3-4 раза времени, которое фирма предполагает потратить на разработку готового продукта.
Вот и идите разрабатывайте через страдание или как его там, лично я разрабатываю через «рвание жопы», «очередной хреновый митинг», «выслушивание трепа idle-коллег», «фикс опупенного количества багов, исправление которых явлвяется причиной появлению других»…
P. S. За статью/перевод благодарен, отличная работа.
Это фраза уже стала эпической — «Отлично! Спасибо!», как-то смахивает на «Щастя! Здoровья!» :)
P. S. Только цитировать...