Стабильную цивилизацию можно построить или везде по всей планете Земля, или нигде

Если это и возможно, то это будет стабильно убогая цивилизация.

А почему в 1991 году (!) не было суда над так званым «коммунизмом»

А кто будет судить? По-быстрому перекрасившиеся директора заводов?Юные и полные эгергии комсорги, для которых 91 год стал первым этапом стремительной капиталистической карьеры? Простый нарид, которому сейчас за 60, и большинство которых «уж я-то в советские времена оооо» ( c ) старая Масяня

Хочешь написать тест, способный работать на боевой базе

Что есть «боевая» в данном контексте? Потому как присутствие в одном предложении слов «тест» и «боевая» несколько смущает

у нас — изменнику Родины??? уж я дам, уж такую напишу,

Основной вопрос обычно не в том, что изменник Родины, не в том, что стало неинтересно, и не в +500. А в том, что расстаться можно нормально — сдал полноценно дела, подтянул долги какие есть, и удачи — в общем-то большинство людей адекватные и все понимают.
А можно, типа как уйти в отпуск, и в первый же день этого отпуска уведомить об своем уходе сразу после выхода, без передачи дел. Или другие подобные фокусы.

документ есть — вы уверены что он хотя бы просто прочитан?

Ну все-таки надеюсь что новые товарищи не прямиком с ясельной группы приходят, и обладают хотя бы минимальной ответственностью. Вплоть до административных мер в обратном случае.

Если учесть, насколько лучше некоторые программисты, чем другие (а речь идет о 5 — 28:кратном превосходстве), ..

28кратное, это уже что-то совсем запредельное, но в несколько раз — да.

то как вы хотя бы избежите издержек по управлению 5ю джунами вместо 1го синьора?

Это тоже корректно. Простите, но я не улавливаю ход вашей мыслей в целом. Много джунов — плохо, ибо несамостоятельные дебилы. Мало сениоров — плохо ибо бас фактор.

трактовка работы фон Неймана

Фон Нейман, насколько я помню, был про разработку железа. Это не маппится 1:1 на разработку софта, по крайней мере на процесс так уж точно

свой внутренний продукт.

что-то там с домами, арендами

спросил для порядку о тестах. Не, смеется, нету. Были, и сейчас болтаются. но поломаны давно, и никто и не пытается их чинить.

Непрофильная компания (в смысле не ИТшная) + слабый CIO, не особо понимающий в разработке или не могущий нормально продавить.
Вполне себе реальная ситуация, бывает достаточно часто

какими методами обеспечивается уменьшение рисков от бас фактора?

1. Начиная с документирования. Как дизайна всего приложения, так и специфичных модулей
2. Писать, ВНЕЗАПНО, понятный код с минимумом неявных вызовов (ОСОБЕННО, каскадов триггеров). Чтобы попытка понять, что же должно происходить в рамках конкретного процесса для нового бойца не превращалась в два дня реверс-инжиниринга с тремя аудиенциями у местного гуру. Который обычно и становится таким вот бас-фактором.

какими методами достигается стабильность и предсказуемость разработки ПО?

Если я бы знал исчерпывающий ответ на этот вопрос, я бы жил на огромном приватном острове в теплых морях. Но начать можно хотя бы от противного. Обращаясь к нестареющему Бруксу,

Если есть N программистов, то количество пар программистов равно N(N—1)/2, то есть с ростом числа программистов затраты времени на взаимодействие растут квадратично. Поэтому начиная с какого-то N, рост числа программистов замедляет выполнение проекта.

На одних и тех же данных — пропустили.

речь была только об одном виде тестов — юнит.

Скажите, вы вообще в принципе понимаете что такое юнит тесты?
Как у юнит тестов могут быть разные данные на входе?

понятно что из правила — чтобы создать надежную систему из ненадежных элементов нужно увеличить количество элементов и связей между ними следует

Эммм ... Первый раз слышу о таком правиле. Т.е. чем больше ненадежных элементов, причем связанных между собой, тем надежнее система в целом? Это просто переворот в теории надежности. Если же речь шла об резервировании, либо избыточности, то это полностью отличается от банального увеличения количества

там же треба показувати — метрики. а покриття — то дуже зручна метрика. ... а успіх проекту, то такє

Хорошо. Вот у вас есть условный проект. Ну, не знаю там, 10 модулей, 5000 строк кода, или 20 модулей и 20000 строк, не принципиально. Каким образом вы можете хотя бы очень примерно оценить качество кода? Желательно в измеримом виде, а не «я ревьювил, все Ок, отвечаю». Или эта информация тоже НЕ НУЖНА ?

P.S. Ну и без демагогии на тему «видел проект с хорошим покрытием, но внутри ужасный» — такие случаи тоже бывают. Но их много меньше обратных. Хотя бы потому, что при достаточном количестве нормально написанных юнит тестов, стуктура проекта скорее всего будет более-менее вменяемой, с минимумом функций с запредельной цикломатической сложностью и гвоздями прибитых зависимостей. Иначе написать нормальные тесты либо очень трудозатратно, либо просто невозможно. Вот именно это и есть главный плюс, а не абстрактное число в 63.5% на выходе

да, юнит-тестами не получится.

предпочитаю просто функциональные и интеграционные.

Что вполне объяснимо.

менеджеры среднего звена любят.

Более того, еще и полиси продавливают, которые фэйлят попытки мержей из фича-бранчей при недостаточном покрытии. Менеджеры- вредители, как бы сказали в 30-х годах

мне нравится писать ее там — где удобнее и надежнее будет
а джуны да, пусть бегут туда где им нравится.

Классический паттерн поведения разработчиков\администраторов legacy систем, сталкивался не раз.
— «10 лет так делаю и проблем не было»
— «Mне юнит тесты не нужны, я и так свою систему знаю»
— «То у вас просто требования к системе неправильные»

Вот только этот код невозможно покрыть юнит-тестами

покройте интергациоными тестами

Как насчет разницы во временнЫх затратах в пересчете на простейшее изменение?

А как же

(самый яркий пример что видел — когда офисное приложение-клиент на дельфи, уже в количестве 4 штук клало на лопатки локальную сеть

Аргумент блондинки: «А вот я знаю случай!»
не обсуждаю.

Будьте последовательны, что ли

Каскад неявных вызовов тригеров плох не «спагети кодом» а тем что может сильно замедлить работу бд, при простых на вид действиях над данными.

Регулярное появление словосочетания «неявных» в контексте мне прозрачно намекает на:
— Не самое простое тесттирование
— Не самое простое сопровождение кода

Это все конечно мелочи. и в жизни всегда есть место подвигу, тут уж, как говорится, на вкус и цвет ...

А если с Джавы надо перейти на Хаскель? Ужас, нельзя писать на Джаве, вдруг на Хаскель придется переходить — банальность того же рода, как и вывод.
Ну ладно, не на Хаскель — на Rust вдруг надо будет переходить с Джавы?

Аналогия абсолютно неуместна. Очень грубая подмена понятий

Или, или, или, ... — вы предлагаете посоревноваться в фантазии?
например:

.

Я не люблю фантазировать и говорю про еще один реальный случай из своей практики. Только речь шла не непосредственно о покупках (собствено покупки произошли раньше), а о миграции региональных биллинговых систем достаточно большого телекоммуникационного холдинга в единую централизованную.
Которая, к сожалению, была написана большими любителями запихнуть-побольше-логики-в-БД. По факту, если обращаться к классической трехуровневой архитектуре, уровень бизнес-логики там был редуцирован в «получили данные-заинсертили в базу-там разберутся». И которая уперлась в бутылочное горлышко дискоовой посистемы при росте нагрузки всего лишь в 3 раза.

это топовая потребность для информационнй системы уровня ERP?

Это была не ERP-система. Это был набор in-house OSS/BSS систем.

переписывают все — и по куче других причин, оставаясь и на той же БД
И переписывание да — трудозатратно. Вообще, даже не переписывание, а написание с нуля — трудозатратно.
Такая вот банальность — разработка ПО — это трудозатратно.

Тут шаблон для того чтобы за умного сойти -телепатировать и выдавать наиболее общие фразы

И ведь не поспоришь ...

Нюанс в том что есть упоротые «программисты фаангов» которые только тем и заняты что масштабируют перемасштабируют, когда оно нафиг не надо

Это еще одна крайность, абсолютно согласен. Когда на мелкий стартап требуют что-то типа Oracle RAC, а то вдруг через 5 лет будут миллионы пользователей.

потому в бизнесе рост в 10 раз за небольшое время — это ого редкость, и в конкретном и большинстве проектов тоже,

Это может быть необязательно прямой рост, вида в «интернет магазине было n закзазов в месяц, а стало 10*n за три месяца». А может быть вида «появилась необходимость собирать и хранить детальную статистику по определенным\всем услугам». Или «купили компанию-конкурента и интегрируем их данные»

Разумеется, эти упоротые выдают в большинстве случаев банальные фразы и умозаключения

Еще одну банальную фразу «логика реализовання в БД на хранимым процедурах и триггерах трудно переносится при переходе на другой тип БД» наверное слышали все.
И почти все обычно думают, «ну что за нереальный сценарий».
И в целом правы, это достаттчно редкий случай. Только я вот лично видел, работа онсайт у одного из кастомеров, с какими огромными проблемами у них шел глобальный переход с DB2 на Oracle в enterprise масштабе — в этом была плотно задействована команда с их сторовн которой мы непосредственно работали по своим активностям — так как по факту они просто переписывали все.

Тригер по сути, это метод объекта, вызываемый автоматически при его изменении, создании и удалении

Нет. Триггер, по сути, это статическая функция, которая принимает как параметр объект, при этом объект на ход выполнения этой функции влиять никак не может.

каскад неявных вызовов,

Идеальное описание спагетти-кода в трех словах

Берете этот шаблон, подставляете по контексту — и за умного сойдёте.

Мне не надо «сходить» за умного. Я и так не дурак.

У всех DB-centric систем на основе классических реляционных баз есть одна общая проблема — они на порядок хуже и на порядок дороже масштабируются.

В данном случае я старался выразился конкретно. Запасаюсь попкорном и с удовольствием жду саксесс-стори про элементарное масштабирование реляционной БД в 10 раз, и главное — во сколько это обошлось по финансам итого :)

Другими словами, не требуют строгой consistency

Другими словами для части информации не требуется абсолютная точность или достоверность

Как я понимаю, вторая цитата должна означать что-то радикально противоположное... Но не могу уловить нюансы, можете просветить?

без зловживання трігерами.

Золотые слова. Имхо, основная проблема триггеров — это классический спагетти-код, который получается если попытаться «лианеризовать» (не знаю как более лучше © сформулировать) их логику, со множеством возможных точек входа и состояний

— катастрофічне падіння швидкодії. і ніяке кешування на равні аплікації не допоможе, або буде дужа складна інвалідація

У всех DB-centric систем на основе классических реляционных баз есть одна общая проблема — они на порядок хуже и на порядок дороже масштабируются.

— кешування, накопичення у memory tables змін, які можуть бути втрачені, та не потребують актуальності, і основні данні оновлюються по event

Другими словами, не требуют строгой consistency. Для таких задач есть другие типы БД,

интелектуальные системы обнаружения нетипичных операций.

Это чаще stream платформы, на основе events