A
Плохой код + хорошая архитектура - это не страшно
смелый ты
Size: a a a
2021 March 02
O
И это мы еще на касались самого определения "хорошей архитектуры"...
Y
Нельзя рассматривать код и архитектуру отдельно и качество одного совершенно не гарантирует качество другого. Итоговый продукт выйдет не особо хорошим и при плохой архитектуре, и при плохой реализации.
С аргументами согласен, с обобщением не согласен
Y
Я же не сказал что хорошо, я сказал: не страшно ;)
O
С аргументами согласен, с обобщением не согласен
Ты можешь привести хороший продукт, где архитектура прекрасная, а код - говно?)
O
Особенно если взять ну хотя бы OPEX поддержки этого добра. С точки зрения CAPEX кстати дерьмовый код вполне может зарулить, спроси у 90% галер:)
A
Разово
кажется, написать для этого скрипт будет быстрее, чем нагуглить решение
VG
в этом подходе что-то есть. вообще интересная идея писать какие-то маленькие модули не так, чтобы они были прекрасны навсегда ("хороший код"), а так, чтобы их можно было легко выбросить и заменить ("хорошая архитектура"), при всей ее интуитивной расточительности явно имеет немало плюсов. это как креш-онли но на уровне разработки а не рантайма. мне кажется, с кложуром к этому приходят на высших уровнях (он очень райт-онли, как ни крути)
A
Особенно если взять ну хотя бы OPEX поддержки этого добра. С точки зрения CAPEX кстати дерьмовый код вполне может зарулить, спроси у 90% галер:)
что такое орех и сарех?
Y
Особенно если взять ну хотя бы OPEX поддержки этого добра. С точки зрения CAPEX кстати дерьмовый код вполне может зарулить, спроси у 90% галер:)
Дерьмовый код отлично работает и плохо дорабатывается
O
Я же не сказал что хорошо, я сказал: не страшно ;)
На счет "не страшно" я бы тоже поспорил. Особенно когда программисты побегут, видя прекрасную архитектуру и обязанность разобраться в этом всем, чтобы с этим работать:)
KS
что такое орех и сарех?
Операционные расходы и капитальные расходы
A
Дерьмовый код отлично работает и плохо дорабатывается
если он отлично работает, значит не такой уж он дерьмовый
KS
что такое орех и сарех?
OPEX условно подписка, CAPEX покупка
O
если он отлично работает, значит не такой уж он дерьмовый
Вот да:) Код может быть дерьмовым по разными причинам. Стилистически - это в целом еще не самое страшное.
A
OPEX условно подписка, CAPEX покупка
спасибо
O
в этом подходе что-то есть. вообще интересная идея писать какие-то маленькие модули не так, чтобы они были прекрасны навсегда ("хороший код"), а так, чтобы их можно было легко выбросить и заменить ("хорошая архитектура"), при всей ее интуитивной расточительности явно имеет немало плюсов. это как креш-онли но на уровне разработки а не рантайма. мне кажется, с кложуром к этому приходят на высших уровнях (он очень райт-онли, как ни крути)
Все сильно от масштаба зависит. Если это продукт на 50-100 и больше человеколет, то любое не самое значительное изменение будет настолько медленным и болючим, что тысячу раз все проклянешь.
KS
спасибо
В контексте этого обсуждения OPEX это когда платим команде которая разрабатывает продукт с постоянной доработкой или подписались на SaaS. CAPEX когда купили у галеры разработку и поставку без доработок. Возможно тут я не совсем хороший пример привел, но примерно так.
O
В контексте этого обсуждения OPEX это когда платим команде которая разрабатывает продукт с постоянной доработкой или подписались на SaaS. CAPEX когда купили у галеры разработку и поставку без доработок. Возможно тут я не совсем хороший пример привел, но примерно так.
Я это написал скорее в контексте того, что ты хочешь оптимизировать. Если принцип "написать и свалить" - это CAPEX важнее, главное запустить и сдать. Если ты думаешь о том, во что тебе выльется поддержка при цикле жизни продукта, то тут OPEX может быть на порядки больше, чем изначальная стоимость.
VG
Все сильно от масштаба зависит. Если это продукт на 50-100 и больше человеколет, то любое не самое значительное изменение будет настолько медленным и болючим, что тысячу раз все проклянешь.
ну вот представь себе ты пишешь и дизайнишь модуль не так, чтобы навсегда, а так, чтобы его легко было заменить (то есть с упором на изоляцию и тесты, которые не слишком много знают про имплементацию) - тогда и изменять этот модуль будет проще