Что нас не убивает, то делает сильнее

Смарт-часы у меня вовсе не смарт. Для уведомлений я их не использую. Больше меня интересует запись показателей. И в первую очередь -- сна, а не физических активностей.

Тем не менее, ношу я какой-то там ми бэнд (шестой). И ношу я его в ванну тоже.

Ну и короче после очередного выхода из ванной я обнаружил, что у ми банда отказал тачскрин. Рад я этому не был. Это типа что, один сломал, другой потерял? (потому что предыдущий я потерял) Браслеты -- расходный материал и работают год?

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

Стал смотреть, что на рынке. С воодушевлением узнал, что в Gadgetbridge недавно добавили поддержку часов хуавей/хонор, а у них нет блокировки сторонних приложений, в отличие от ми бэнда. С печалью узнал, что ми бэнд 8 про имеет тенденцию тонуть. Подивился ценам на смарт-часы круглой формы (в 2-3 раза больше квадратных).

Пока я читал интернет, я продолжал ходить с текущим ми бэндом в ванну. Длилось это недели две.

И вот выхожу я из ванной в очередной раз, и обнаруживаю, что тачскрин заработал. Это как? Залившаяся вода восстановила контакт? Не может быть.

Штош. Как заработал, так и снова откажет. Но пока ещё попользуюсь.

---

Солнечное, пляж Ласковый

Доктор разрешил уже водить машину, и я поехал на работу.

Идёт ливень. Меня обгоняет кабриолет. У кабриолетов обычно есть закрывающаяся крыша. У этого либо крыши не было, либо водитель не стал её закрывать. Трудно представить, в каком состоянии у него был салон.

Водитель же был не в капюшоне. Не в шляпе. Он был в огромных наушниках -- на лысую голову.

---

ТЗ нечёткое, но виноват сам

Надо было сделать многократное измерение. Сколько максимум раз может пользователь захотеть его сделать? Неизвестно. Сотня точно. Может и больше.

Но как это тестировать? Это пользователь может мерить по своему желанию. Мне запустить замер на много часов или даже несколько дней -- сложнее.

10 итераций проверил. 50 итераций проверил. 100... не помню, проверил или нет.

Пользователь запустил 200. А потом пишет -- а почему у меня количество измерений отрицательным отображается?

Читаю логи. 126 измерений... 127 измерений... -128 измерений...

Это такая классика, что у меня олдскулы свело. Программа, отображающая ход измерений и программа, непосредственно проводящая измерения -- разные вещи. Они обмениваются пакетами. Формат пакетов задаю я сам.

И вот почему-то для общего числа итераций я использовал тип int32_t (4 байта), а для номера текущей итерации -- int8_t (1 байт). При этом в микроконтроллере номер итерации хранится 32-битный. Это он только наружу выходит в урезанном виде.

Конечно же, восьмибитное знаковое число будет "оборачиваться" в минус после 127...

---

Слишком умный

Магазин в ТЦ открыт, но двери закрыты. Двери стеклянные. Подхожу, вижу надпись, "от себя".

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

Перед выходом спрашиваю у продавца, почему дверь открывается не в ту сторону. А продавец отвечает:

"Да вы не переживайте. На самом деле она в обе стороны открывается".

---

Файловый указатель: какую я придумал аналогию

В Питоне я предпочитаю файл сразу считывать в память, а уже потом с ним работать. То же и при записи: сначала готовлю содержимое, потом его сразу пишу.

Но файл может быть большим, по нему надо ползать, что-то считывать и что-то записывать не по порядку. В Си для этого есть fseek. В Си++ есть seekp/seekg. В Питоне тоже есть seek.

В детстве я плохо понимал смысл файлового указателя. Вот же он:

FILE *f;

Но это не тот указатель.

Файловый указатель, управляемый функциями типа fseek, обозначает позицию для следующих записи/считывания. Как же это об'яснить студентам, с учётом того, что я сам этого долго не понимал?

Сейчас я полагаю, что лучшая аналогия -- это курсор. Любой современный человек, пользующийся хотя бы смартфоном, понимает, что такое курсор. И интуитивно понятно, что запись в файл происходит в положение курсора. Чтение тоже происходит из положения курсора.

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

Ещё сложнее понять, что при записи в середину фалйа, а не в конец, происходит перезаписывание содержимого. Это то же самое, что режим курсора overwrite, хотя о нём знают не все.

Но изначально я писал не просто про файловый указатель, а про функции типа fseek. И вот каково об'яснение их назначения:

Функции fseek занимаются ничем иным, как установкой положения курсора -- от начала, от конца файла, или относительно текущего положения. Вот и всё.

---

Горячие пирожки наоборот

Это очень просто, но понимание ко мне пришло не сразу:

Лёд в кубиках надо из формы в чашку перекладывать как можно быстрее, чтобы рука замёрзнуть не успела.

---

Приоткройте ворота

Явление достаточно редкое, но от этого не более понятное. В Телеграме.

Публичный канал с запретом копирования и пересылки сообщений.

Я понимаю, когда канал приватный. Мало ли что вы там публикуете -- это дело ваше. Вы можете не хотеть распространения. Но если канал публичный, то что? Человек не властен над тем, что он уже опубликовал.

Существуют разные способы получить текст поста. Например, у таких телефонов на анрдроиде нельзя снять сркиншот. Но на компьютере можно. Тот, кто захочет получить текст -- это сделает.

А потом... отправит текст тому, кому собирался. Если бы пересылка была разрешена, то при пересылке было бы видно, откуда это . И человек бы зашёл и подписался. А нет форварда -- нет подписки.

---

Для чего, по-вашему, нужна иконка?

Интернет-магазин, товар. Под товаром зелёная галочка. Я такой -- отлично.

Читаю текст рядом с зелёной галочкой: "Нет в наличии".

*волк крутит пальцем у виска*

А если есть в наличии, то какой значок?

Проверил: тоже зелёная галочка.

---

Я не матерюсь, у меня просто лицо такое

Из-за руки (и не только) в последнее время мне часто приходится общаться с незнакомыми людьми. Или не так: незнакомым людям приходится общаться со мной.

Я часто слышу претензию насчёт того, что я слишком громко говорю. А говорю я действительно громко, особенно когда волнуюсь.

"Не кричите на меня!"
"Можно потише?"
"Да он просто плохо слышит"

Увы, потише нельзя. Слышу я хорошо. Проблема в другом.

Родители всю жизнь вели занятия по бальным танцам. У детей. Это значило, что им надо было перекричать не только музыку, но и, собственно, детей.

Дальнейшее я только предполагаю. Придя домой, они продолжали орать уже дома. Что же оставалось делать мне и сестре? Или просто молчать, потому что нас не услышат, или начинать орать точно так же. (К сестре тоже бывают претензии по поводу голоса)

Результат понятен. Но что с ним делать? Как можно научить себя не кричать? И нужно ли это делать?

---

Показалось

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

Лежу я себе, засыпаю, и вдруг понимаю, что на каждом вдохе я слышу... хрип. Это меня несколько встревожило. Я поэкспериментировал с дыханием -- хрип повторялся. Очень плохо. Я решил перевернуться на бок, чтобы посмотреть, что будет. И когда я переворачивался, я услышал хрип, хотя в это время не вдыхал...

ОКАЗАЛОСЬ, что это скрипели липучки у косынки, на которую была подвязана рука...

---

Оставьте меня в покое

Был удивительный период в моей жизни, когда мой папа шестым чувством знал о моём нахождении в туалете. Стоило мне туда зайти -- он звонил на телефон, чтобы что-то узнать и т.п. Я решил эту проблему: стал всегда брать телефон с собой.

Через какое-то время такие случаи прекратились.

Потом оказалось, что такое бывает не только у меня и не только с туалетом. Например, лёг вздремнуть на полчаса -- начинают одновременно звонить спаммеры и коллеги с работы. И у самого папы на днях было то же самое: лёг поспать, начали писать и звонить.

Раньше я думал, что причина таких совпадений мистическая. Типа вселенная предупреждает -- сейчас не спи, проспишь что-то важное. Но сбор статистики показывает: никто ничего важного не проспал.

Тем не менее, что причина мистическая, я по-прежнему не сомневаюсь. А вот в чём смысл -- не знаю.

---

Светская беседа

Раньше, когда кто-нибудь на работе начинал разговор с фразы "а я вот видел видео на ютьюбе...", я кривился. Ну что это такое. Видео он видел! Я тоже видел, но можно же как-то поумнее начать рассказывать.

А потом ничего, привык. Сам тоже теперь так делаю.

И уже сейчас я не понимаю, чего это я кривился. Это мало отличается от "по телевизору рассказали". А разговоры про то, что рассказали по телевизору, существуют очень давно.

---

Для сладкого второй желудок

Кассовый чек является документом. А важность этого документа определяется важностью товара.

Я беру чеки почти всегда, а потом складываю их в кучу. Сейчас я начинаю склоняться к идее о том, что малозначимые чеки можно не брать. Тем не менее, у меня бывали случаи, когда на выходе из магазина останавливают и просят чек.

Конечно, при оплате банковской картой чек может быть в банковском приложении, но там будет отображаться только сумма, а не список товаров. Если же ваше банковское приложение получает ещё и список товаров, то откажитесь от приложения и от самого банка. Список покупок банку знать совершенно незачем. Пусть его знает только платформа ОФД. К сожалению, я пока не понял правил, когда формируется электронный чек ОФД, а когда нет.

Есть более важные чеки, связанные не с хлебушком, а с гарантией на различные девайсы. И вот, устройство сломалось, я начинаю искать чек.

Многие магазины электроники печатают кроме чека ещё и накладную. Это крупногабаритная, осязаемая вещь, которую проебать непросто. Но, например, DNS печатает только чек. А в последнее время даже отказывается ставить печать на гарантийный талон. У вас есть чек!

Чек был, да сплыл. Я перерыл все кучи и осязаемых документов, и продуктовых чеков. Нашёл все чеки кроме нужного.

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

---

Ещё раз про знак "меньше" на diary.ru

Пару недель назад я писал о проблемах со знаком "меньше". В том посте я очень гордился тем, что нашёл способ отображения этого знака без проблем. И даже собрал четыре лайка, что очень интересно с учётом того, что я обнаружил позднее.

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

Я не буду описывать процесс расследования, а перейду сразу к выводам.

Правила отображения знака меньше и html-подстановок, о которых я писал в прошлом посте, зависят от настройки: Настройки -- Картинки (аватары, смайлы) -- Показывать или нет графические изображения смайликов.

При этом правила такие.

1. Если у пользователя опция ВКЛЮЧЕНА, т.е. текстовые смайлики заменяются на графические, то HTML-подстановки НЕ ЗАМЕНЯЮТСЯ. Вы можете спокойно писать &lt; в тексте поста. Эта подстановка "как есть" будет передана в браузер, а он её отобразит как знак "<".

2. Если у пользователя опция ВЫКЛЮЧЕНА, то текстовые смайлики заменены не будут. Вместо этого БУДУТ заменены HTML-подстановки! В этом случае писать их напрямую уже нельзя, а надо использовать тот метод, что я описывал в прошлом посте. Иначе движок дайари сам раскроет подстановку и отправит знак "<" в браузер, что недопустимо, и может быть отображено некорректно.

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

У меня, естественно, опция была выключена (вариант №2), поэтому-то я и знал о проблеме. Но проблема эта была только моя. Я уверен, что большинство пользователей, включая анонимов, имеют включённую опцию. Поэтому-то мне и интересно, что за четыре человека поставили лайк. У них, значит, опция тоже отключена, поэтому они увидели текст поста так, как я задумал?

Теперь надо понять, что делать. Я, конечно же, хочу спокойно писать знаки меньше и больше, и чтобы все их видели правильно. Но пока что не понимаю, как это сделать. Возможно, придётся воспользоваться методом CD_Eater'а, который оборачивает эти знаки в тег span, вот так:<span><</span>. Это нарушает правила вёрстки, но даёт предсказуемый результат: знаки отображаются корректно. Теперь надо проверить, что это одинаково работает во всех дизайнах и при всех настройках.

---

Комплимент "с добавкой"

Такие комплименты я, к сожалению делал сам, а иногда и получал.

В чём суть?

Хотя комплимент чаще всего делается противоположному полу, но явление это более общее. Комплимент -- это что-то вроде похвалы. Может быть не совсем корректным сказать бородатому мужику что он "молодец" и "умничка", а симпатичной девушке что она "баба хоть куда". Но можно сделать и кое-что похуже.

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

Короче говоря, иногда, когда делают комплименты, их "разбавляют", сообщая кроме основной похвалы ещё какое-нибудь малоприятное обстоятельство. В экстремальных случаях это может выглядеть примерно как "молодец, но мог бы и лучше" или "умничка, жаль что лицом не вышел".

Это не просто уменьшает степень похвалы, как может показаться говорящему. Это меняет её знак на противоположный. "Молодец, но мог бы и лучше", это не 90% похвала вместо 100%. Это –90% похвала.

Так что лучше уж перехвалить и вовремя остановиться, чем попытаться "уточнить" комплимент. Хуже будет.

***

А вот и реальный пример, который был у меня.

Конный инструктор мне говорит: "Я бы с вами на лошадях на войну поехал".

Несмотря на моё отношение к войне, слышать такое было приятно. Конница требует не только надёжных лошадей, но и надёжных всадников. Если вам такое говорят, то это определённый уровень доверия, а также признание вашего навыка.

А потом инструктор сказал "добавку":

"Я бы вас поставил обоз сторожить. У вас всегда всё предусмотрено".

Кхм!

---

Учебный код и серьёзный код

Все мы когда-то писали кривой код на лабах по программированию. А кто-то такой код пишет до сих пор по работе.

Учебный код должен выполнять то задание, которое написано на листочке, и его он должен выполнять без ошибок. Если при разрешённых входных данных получается чушь, это должно быть исправлено.

Но что делать с запрещёнными входными данными? Я полагаю, что учебные программы имеют право работать некорректно, если пользователь попрыгал по клавиатуре или нажал кнопки не в том порядке. Потому что смысл упражнения не в том, чтобы сделать законченный продукт. Задача лаб в том, чтобы студент понял ту или иную концепцию и применил её на практике.

Сейчас я пытаюсь вспомнить, требовал ли я от студентов жёстких проверок на всех этапах работы программ или нет? Вроде не требовал. Но если даже требовал тогда, то сейчас моё мнение такое, как я написал выше.

Если, конечно, студент сам захотел и сделал все проверки -- то это замечательно. Потому что такой код уже может считаться серьёзным.

Серьёзный код -- это такой, который корректно отрабатывает все разрешённые взаимодействия с пользователем. Программа может падать, если пользователь покопался в настроечных файлах -- это он сам виноват. Но программа не может падать, если пользователь не там пощёлкал мышкой.

Я не знаю, как принято в современной методологии разработки ПО. Я вижу только то, как делаются проекты у нас на работе и в соседних организациях. А происходит вот что. Любой код начинается как учебный, и сначала пилится основная часть, которая правильно работает при правильных действиях пользователя.

А вот когда это заработало, начинают делать защиту от оператора, от стихийных бедствий и от кота. Это-то и переводит учебный код в серьёзный.

---

История, рассказанная с конца. Приёмное отделение

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

В больницу я получил направление из травмпункта после того, как там посмотрели снимок и сказали, что не возьмутся лечить руку консервативно. Никакую скорую помощь мне не вызывали, отправили пешком.

Какое-то время меня оформляли, а потом сказали куда идти, подойти там к ресепшну и сказать, что я "на травматолога". Ходят обычно на босса, а не на врача. Но там все так говорят. "На травматолога", "на хирурга". На самом деле никуда "на" я не пошёл. Меня отправили в палату для обследования.

В этой палате все лежат вместе, независимо от врача, от пола и от состояния. Мне сказали номер свободной койки и сказали туда сесть.

Койки все имеют шторку, которой можно закрыться полностью. Но в целом это не помогает. В приёмном отделении нет врачебной тайны. Вы по-любому будете примерно знать, у кого что. Потому что шторки редко закрываются плотно. Потому что разговоры пациентов и персонала всё равно слышны. И потому что...

Заходит врач. Я слышу с ресепшна чей-то голос, "уролог пришёл". Голос не очень громкий. После этого я слышу уже уролога:

"ТАК! ГДЕ ПАЦИЕНТЫ С МОШОНКАМИ? ВСЕ НА ОПЕРАЦИЮ!"

***

Я пробыл в приёмном отделении пять часов. Из них меня обследовали только три. Остальное время я ждал, отпустят меня, прооперируют сразу, или отправят в отделение. Меня отправили в отделение. За мной пришёл очень весёлый медбрат, который хотел увезти меня на каталке. Я сказал, что у меня рука, а не нога, и пошёл сам.

Вскоре после того, как я разместился, привели ещё одного страдальца с такой же травмой. Он рассказал, что в приёмном отделении произошёл один случай, которого я не застал. А может, этот случай был в другой палате?

Женщина лежит на койке, никого не трогает. В это время от вентиляционного люка отваливается решётка и падает прямо на неё. Хорошо, что решётка была пластиковая. Но расслабляться не стоит. Даже в больнице вы не защищены от дополнительного травматизма.

***

Дополнительная история, про мотоциклистов, находится у меня в лошадином канале: t.me/horseswtf/437

---

Kimetsu no Yaiba: Mugen Ressha Hen 01-07 END

О чём

У нас одно новое задание для героев, которое заключается в том, что в поезде поселился демон. А потом оказывается, что демон был не один...

Что думаю

Вообще это п/ф, но есть версия в виде сериала. Сериал смотреть удобнее, поэтому я смотрел так. Может быть, если бы я смотрел залпом, впечатление было бы немного другое.

Фильм состоит композиционно из двух частей. Первая -- это сражение с демоном в стиле первого сезона. Это получилось хорошо.

Вторая часть -- это сражение Огненного столпа с супер-сильным демоном. Это сражение нужно с совершенно конкретной целью.

Сёнэн -- это жанр, подразумевающей постоянную прокачку персонажа. А чтобы прокачка была оправдана, надо, чтобы противники становились сильнее. Данное сражение показывает, что ГГ имеет даже не 10% силы, которая нужна для больших сражений, а 1% силы. И это показано хорошо.

Несмотря на эти положительные моменты, концовкой я не доволен. Но ничего, сезонов ещё много...

Рекомендации

Как хотите.

Скриншоты

Десять скринов на семь серий я не соберу.

(скриншоты)

Не только ГГ качается, но и Нэдзуко.


Владыка -- это паровоз, если плохо видно.


The Thing.


Универсальный совет.


Ого, паровозный круг!


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

---

Планирование на ходу

Раньше я жил размеренной жизнью "по расписанию". Я почти всегда знал план не только на завтра, но и, скажем, на неделю.

Не всегда, конечно, план выполнялся. Не всегда было заранее известно, чего ожидать. И вот подвешенное состояние, когда оно всё-таки происходило, доставляло мне большой дискомфорт.

Хорошо ещё было, когда точка ветвления была расположена где-то в известном будущем. Точки можно было дождаться, а потом действовать по обстоятельствам. Но бывали и точки, не только исход которых был неизвестен, но и расположение по времени тоже.

Как я могу что-то планировать, когда не знаю не только, что будет, но и когда будет? Это очень нервировало.

Потом что-то изменилось. Когда -- точно не помню. Возможно, в 2019 году, когда меня отправили в командировку, делать неизвестно что.

У меня резко возросло число ситуаций, которые невозможно спланировать. То ли будет, то ли нет, и когда -- тоже неизвестно. Опа, нежданчик. Или наоборот -- опа, планировал, сорвалось.

Отношение к таким ситуациям тоже изменилось. Сейчас подвешенность перестала меня нервировать и вызывать дискомфорт. Если ждать неизвестно чего и неизвестно сколько -- я найду себе занятие. Что-то изменилось? Что же, давайте подумаем, как можно всё переиграть. Решения можно принимать на месте. Поменять что-то местами. Договориться с одними людьми, а не с другими.

Планирование у меня, конечно, осталось, но теперь это или несколько вариантов, или планирование "в целом", а не "в деталях".

---

Хориков Владимир // Принципы юнит-тестирования (2021)

Это, скорее, не обзор на книжку, а нытьё о моих проблемах.

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

Что я делал раньше? Я прогонял все скрипты, а потом сравнивал выходную папку с файлами и "эталонную", полученную с предыдущей версией скриптов. Сравнением занимался WinMerge. Если я видел разницу, я начинал выяснение -- должна была эта разница появиться или это ошибка.

Такой подход довольно затратен.

Исключением был модуль по работе с БД, db.py. Хотя у него и не было "юнит-тестирования", но у него был "генеральный прогон", вызывавший все функции модуля по очереди с тестовыми данными. Данные не проверялись, просто результаты выводились на экран. Я сэкономил немало сил и времени постоянно запуская этот прогон после модификаций. Он быстрее ловил ошибки в SQL и в питон-синтаксисе, чем если бы я каждый раз проводил полное преобразование дневника.

Тестирования модуля БД было мало. Мне была нужна уверенность в конечном результате. Тем не менее, я решил начать именно с модуля БД, превратив "генеральный прогон" в серию тестов. Я написал несколько первых тестов для py.test, разобрался что к чему, а потом понял, что у меня есть философские вопросы о том, как же следует делать тесты. И практические вопросы -- как делать принято?

В интернете есть достаточное количество статей о юнит-тестировании для начинающих. Их об'единяет общая проблема. Они показывают тестирование на примере функции сложения двух чисел. Как же приложить такое тестирование к более сложной системе?

За ответами на этот вопрос я обратился к данной книжке и не ошибся.

Книжка короткая, всего 300 страниц. Информации в ней мало, и она довольно простая. Но подана она систематически. Всего десяток тезисов, каждому из которых дано подробное обоснование, и приведены примеры -- сложнее, чем сложение двух чисел. После чтения у меня в голове образовался каркас знаний по теме. И я могу его применять.

Настолько вменяемых книжек существует совсем немного.

Кроме того, я нашёл в книжке подтверждение догадок, которые у меня появились, когда я пытался написать тесты. А ещё я нашёл ответы на все мои вопросы, которые у меня возникли до чтения.

И главный вопрос у меня был такой: почему для модуля БД тесты написались практически сами собой, а для остальных модулей я даже понять не могу, как к этому подступиться? Почему я не понимаю, куда приложить тесты к коду в проектах по работе?

А ответ такой. Чтобы тесты писались, код должен быть разделён на логику и на работу с внешними зависимостями ("коллабораторами", как называет автор). Наши рабочие проекты производят реальные замеры реальных значений, и выдают выходные значения сразу на железо. Это "переусложнённый код", который требует кардинальной переработки. В принципе, разделить логику и работу с внешними устройствами у нас можно, хотя придётся потратить на это довольно много усилий. Но вот можно ли симулировать серии из десятков тысяч входных значений? Как потом анализировать десятки тысяч выходных, не вглядываясь вдумчиво в графики? Это нужно пилить отдельный фреймворк для работы с фальшивыми значениями. И, возможно, этим стоит заняться.

Скрипты по скачиванию дайари проще. Но они всё равно по классификации автора относятся к "переусложнённому коду". Моя 500-строчная функция download() из download.py делает всё. А должна делать только одно действие. Модуль БД, напротив, содержит десятки мелких функций, каждая из которых делает простую вещь. Поэтому-то этот модуль так легко тестируется.

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

И, возможно, эта треть важнее, чем сами тесты и тестирование вообще.