6️⃣ Роберт Мартин и его чистота
Если у вас совсем нет времени, то поговорите про эти книги с chatGPT или Gemini. AI прекрасно о них осведомлен и умеет подготавливать “краткие выводы”. Не сказать, что вы прям станете супер-умным, но поддержать разговор должно хватить. И вообще рекомендую посмотреть дядюшку Мартина на YouTube — крайне приятно, интересно, а еще— простой, понятный английский без проглатывания 50% звуков.
Ну и конечно же читаем его блог, там еще есть интересно про Agile, который испортили коучи и бизнесмены
7️⃣ Событийный шторминг
Конечно же, возьмите EventStorming от Сережи Баранова — там наглядненько, с примерами.
8️⃣ Внезапно рекомендую свой доклад с ArchDays
Доклад не про то, что можно/нужно переписывать код, а про то, что иногда его практически не переписать, и единственный путь, который — это писать рядом отдельный новый. И это долго, дорого, и никому из бизнеса обычно не нравится. Но, что странно, как раз ответов от сеньор-разработчиков/лидов о том, что они пойдут что-то доказывать и объяснять бизнесу, в момент обсуждения задачи на System Design Interview — практически не случается. И дело вовсе не в том, что ты не ведешь кандидата к этой теме, а в том, что большая часть кандидатов принимает за базу позицию «это не моя зона ответственности».
9️⃣ И вот тут, когда надо погрузиться чуть глубже в проблемы бизнеса и пользователей, на помощь приходит книга “No Interface” — у нее есть целый сайт
ИМХО, это прежде всего книга не для дизайнеров и UX-еров, а как раз для “глубоких подкапотчиков”, потому что все, кто работают в core и платформенных продуктах, со временем теряют связь с пользователем
Но, к сожалению, при таком подходе могут получиться настолько удивительные кариозные монстры, что офигеют все.
🔟 Ну и если вы пробрались через ВСЕ вышеперечисленное — на закуску остаются: стратегия, риски, работа с командой, бюджетирование…
Тут, к сожалению, книг и статей либо слишком много, либо слишком мало. И отправить в какие-то конкретные источники действительно сложно. Да и многое завязано на “принципах веры”. Потому что со временем я уже не понимаю, как объяснять, почему в callback, который приходит мерчанту в ошибке, кроме кода внутренней ошибки, если вы еще и решили показать код ошибки системы, с которой вы интегрированы, — на это надо выделять отдельное поле, а не кидать в «простыню» поля message, где может быть до 40 параметров (я не шучу — это очень распространенная практика и часто еще и идет под руку с 200 OK + error message).
🎬 Вместо эпилога…
Не знаю, насколько это все было полезно, но, возможно, этот пост — прежде всего для меня самой, чтобы при запросах по System Design не рыться по закромам, а просто выдавать все материалы списком.