А проблематика, например, может включать “у тебя на проекте сидит Мария, и она тупой разработчик и все делает медленно, пусть сделает хоть как-то, но сегодня” 😅
Сказать, что это неверный подход — нельзя, так как его верность не может быть доказана характеристикой качества кода
А проблематика, например, может включать “у тебя на проекте сидит Мария, и она тупой разработчик и все делает медленно, пусть сделает хоть как-то, но сегодня” 😅
Да, у нас появляются более сложные процессы, типа тупки разраба, которые выходят за рамки описания модели, которую мы используем, чтобы верифицированно построить качественный код
программисты вообще стараются поменьше связываться с бизнесом и придумали целый layer model для этого чтобы не писать бизнеслогику, а писать только бесконечные слои абстракции
программисты вообще стараются поменьше связываться с бизнесом и придумали целый layer model для этого чтобы не писать бизнеслогику, а писать только бесконечные слои абстракции
И очень печалятся/возмущаются когда случается rampant layering violation ))
Т.е., всегда можно подобрать такую бизнес-проблему, для которой скорость отработки важнее читаемости, и там есть какой-то слишком сложный и супер нетипизированный клубок который выдает что хочет и его не надо переписывать и тд
а я и не говорю что хуже, но у меня трейдоф и делать 90% раоты ради того чтобы избежать 10% багов я не буду
вот именно поэтому люди и пишут верификаторы и генераторы, которые подобный головняк должны снимать с программиста. То есть чтобы для формальной корректности кода надо было прилагать минимум усилий
вот именно поэтому люди и пишут верификаторы и генераторы, которые подобный головняк должны снимать с программиста. То есть чтобы для формальной корректности кода надо было прилагать минимум усилий
Т.е., действительно не существует подмножества случаев, в котором время, потраченное на это, было бы не оптимальным решением?