Я понимаю что вопрос/комментарий не к переводу, а к первоисточнику, но меня сильно удивила цифра про «исследование, подтвердившее увеличение длительности проекта на 15-30% при использовании TDD». Оказалось, что это хороший пример ситуации, когда категорически не следует верить цитирующим, какими бы регалиями они не обладали, а искать первоисточник.

Первоисточник нашелся, это исследование Realizing quality improvement through test driven development: results and experiences of four industrial teams by Nachiappan Nagappan & E. Michael Maximilien & Thirumalesh Bhat & Laurie Williams, опубликованное Microsoft вот тут
www.microsoft.com/en-us/research/wp-content/uploads/2009/10/Realizing-Quality-Improvement-Through-Test-Driven-Development-Results-and-Experiences-of-Four-Industrial-Teams-nagappan_tdd.pdf

Интересно, что аннотации на самом сайте Microsoft это не совсем корректное «цитирование» про 15-30% повторяется почти слово в слово, но в работе мы видим нечто совершенно другое:

Прямо в абстракте: по субъективным ощущениям, время изначального написания кода увеличилось на 15-30%

Далее (стр 298), следом за таблицей 2, показывающей KPI команд после внедрения TDD, в статье говориться следующее, опять-таки категорически не совпадающее с «цитированием» в обсуждаемом тексте:
По субъективным оценкам менеджмента(sic!), время разработки выросло на 15-30%. Однако, это изменение будет компенсировано снижением эксплутационных расходов благодаря выросшему качеству. Этот эффект подтвержден практическими наблюдениями команд IBM и Microsoft.

К сожалению, далее, из некорректного цитирования исследования делаются выводы о «компромиссе между скоростью и качеством». В случае TDD этого «компромисса» просто нет, посколько вся «экономия» моментально съедается отладкой и интеграцией.

Компромисс между ценой/скоростью и качеством существует в совершенно другом измерении, но он не о «допустимом количестве багов». Он, скорее, о том что объем реализации требований во всем диапазоне FURPS+ сильно зависит от имеющегося времени и средств. Но есть принципиальная разница между требованиями или ожиданиями которыми пожертвовали для сокращения бюджета или сжатия сроков, и некачественным кодом. А работоспособность продукта, как и свежесть рыбы в известной цитате из Мастера и Маргариты, бывает только одна.

Особенно странно слышать это в контексте Agile, где, «только работающий продукт является измерением прогресса», и «постоянное стремление к техническому совершенству», и, в конце-концов, definition of done как ключевой элемент обеспечения прозрачности создаваемых артефактов.

1. Установить и настроить zram, проще всего через zram-tools.
2. Создать /etc/sysctl.d/60-dirty.conf со следующим содержимым:

vm.dirty_bytes = 67108864
vm.dirty_background_bytes = 16777216

vm.swappiness=100
vm.watermark_scale_factor=200

3. Убедиться, что используется достаточно свежее ядро (5.3+).

Эти три пункта заметно улучшают ситуацию. Если еще полтора года назад, во времена 4.19, я бы однозначно советовал Windows 10 для маломощных компьютеров с малым количеством RAM, то с параметрами, описанными выше, я ошибся с копированием файла, скопировав многогигабайтный файл в RAM целиком, и система только немного замедлилась. Также могу запускать несколько виртуалок одновременно, RAM в настройках которых превышает количество физически установленной памяти, и все также, не побоюсь этого слова, быстро работает, при 5+ ГБ в swap (и zram, и zswap).

В netflix есть сервис, который называется chaos monkey. Его задача — ходить по серверам и ломать что попало. Задача системы — продолжать работать. Логика этого решения простая: аварии — это часть workflow, а не exception, и система должна продолжать обслуживать клиентов даже в случае частичного повреждения. Благодаря chaos monkey команда разработчиков в netflix может быть уверена, что система умеет реагировать на аварии нормальным образом (продолжать работу). Таким образом продакшен-система netflix оказывается более устойчива к авариям.

Роскомнадзор используется в интернете с той же целью. Он бегает по Интернету и ломает произвольные куски интернета. Логика этого решения проста: блокировки — это часть нормального digital resistance, а не исключительное событие в случае беспорядков в стране. Пользователи должны продолжать иметь полный доступ в интернет, даже если им всё время что-то блокируют. Благодаря роскомнадзору пользователи рунета могут быть уверены, что смогут продолжать пользоваться интернетом, даже если власти решат заблокировать критические ресурсы. Таким образом пользователи рунета оказываются более готовыми к любым закидонам власти.

… Минуй нас пуще всех печалей и барский гнев и барская любовь.

Вспоминается знаменитая цитата:
«С Хабра:

socket378: Меня давно удивляет и настораживает то, с какой легкостью законотворцы лезут в область IT, являясь при этом абсолютно некомпетентными в ней. Похоже любой, кто освоил кнопку «Пуск» уже считает, что знает «как нам обустроить интернет». Почему они не лезут в область ядерной физики, например? Чем IT так провинилась?

Почему бы не принять закон, например, «об энергетической эффективности», обязывающий производителей электроэнергии использовать только вечные двигатели? Откуда они эти двигатели будут брать — вопрос десятый, но ведь начинание-то благое! Бесплатная энергия поднимет ВВП в триллион раз, все будут счастливы.

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

Почему Go — плохо продуманный автомобиль?
1. Коробка переключения передач — в бардачке.
2. Тормоз — не всегда тормоз.
3. Забавно работают поворотники.
4. Ты не можешь просто взять и залить воду в бачок омывателя.
5. Неочевидная логика использования ремней безопасности.
6. Сомнительная строгость сигнализации и противоугонной системы.
7. Квадратные колёса — это просто костыль.

И да, чувак, который это придумал — немного не в себе.

НИФИГА! Go это хорошо продуманный автомобиль. Потому что:

0. Оставим в стороне наезд на чувака. Теперь о деле.
1. Неопытные водители часто включают не ту передачу. Именно так мы похерили новенькую коробку на прошлых выходных, когда друг врубил заднюю на трассе. И тут Его посетила мысль — а давайте чтобы водилы реже ошибались, уберём нафиг этот рычак в бардачок. Пока он туда тянется, он успеет несколько раз подумать и наверняка уж не ошибётся. И хватит уже сравнивать Go с BWM.
2. Обожаю этот момент. В мануле чётко сказано, что тормоз — это не всегда тормоз. А если ты не прочитал мануал, ты сам тормоз. И это великолепное достоинство Go, в отличие от других поделок.
3. Они работают так как должны. Да, немного непривычно их включать, да, они не выключаются автоматически, да они мигают разными цветами (а иногда не мигают). Но вы должны привыкнуть. Потому что это правильно. Вот увидите, вас и вашу люстру будут пропускать везде!
4. У меня тоже сначала не получалось. Но потом я выяснил, что обычная вода не подходит, нужен легкий раствор соды. И чистит лучше! И да, если ты не прочитал об этом в первый же вечер в мануале, ты снова тормоз.
5. Если ты плохо выспался, или ты просто тормоз, то естественно эта логика покажется тебе неочевидной. Короче, Go — это не Мерседес тоже. А ты — тормоз. Учи мануал.
6. У тебя ещё ничего не угоняли? А вот у меня угоняли. Поэтому рядом с моим Go всегда дежурит наряд полиции, к машине подпускают строго по паспорту, конвой, все дела. У тебя ещё просто ничего не угоняли.
7. Есть огромная пропасть между водилами-теоретиками и водилами-практиками. Практики знают, что с квадратными колёсами гораздо проще удержать автомобиль на наклонной плоскости. Все остальные — тормоза.

— Стёб на стёбе, конечно. Но если убрать шелуху, то всё выглядит именно так. И с языком, и с его комьюнити, и с этими двумя статьями.