"Без требований и без проектирования программирование -- это искусство добавления ошибок в пустой текстовый файл".
-- Louis Srygley, ИТ-архитектор сервиса доставки UPS

Микросервисная архитектура, которую спроектировали не занимавшиеся в моей Школе.

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

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

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

Поможет ли тут самый продвинутый AI?

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

Но для этого у меня есть полуформальный приём от ИТ-святого, который скоро расскажу курсантам в СильныхИдеях.

MVC-архитектура, которую спроектировали не занимавшиеся в моей Школе.

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

"Системе не хватает модульности, если изменение одного из её компонентов влияет на функционирование других"

Модульность -- безусловно, очень важный аспект в программировании, но её достижение требует дополнительных усилий. Стандартный подход, когда вы стараетесь отделить каждый тип от другого с помощью абстракций. Именно это и подразумевается под словами " low coupling, high cohesion".

Как уже раньше не раз говорил, если довести эти принципы до логического конца, то в итоге получатся сотни (а то и тысячи) небольших типов, которые можно вырвать из вашего приложения и бросить в любом другом месте, поскольку они отвязаны от вашего кода (этот момент рассматриваем на курсе ООАП), но в этом есть и свои минусы (много лишнего кода, объёмное и излишне детализированное юнит-тестирование...).

Поэтому для курсантов в СильныхИдеях я отдельно написал 5 заметок по принципам SOLID, как их лучше воспринимать с точки зрения функционального программирования.

Что происходит, когда во время выполнения возникают проблемы с разрешением зависимостей, волшебным образом зарегистрированных в вашем чудесном DI-контейнере?

Ричард Хикки, автор Clojure:
"Нет состояния, только снапшоты данных"

Анатта (бессамостность) в буддизме:
"Нет неизменной сущности, только процессы"

Два мира, одна интригующая перспектива.

"Из всех способов бегства от реальности математика достигла наибольшего успеха...
Все остальные побеги - секс, наркотики, хобби и т.д. - по сравнению с ней эфемерны.'
-- Джан-Карло Рота, математик, философ, МИТ

Математика самая крутая вещь в мире.

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

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

Python и PHP более производительны, чем Си.

А чем будет монада продолжения в категории эндофункторов?

Поясняю за последний опрос.

Умножение n-разрядных целых чисел занимает время O(n), поскольку алгоритм умножения предполагает многократное сложение. При умножении двух чисел их необходимо многократно складывать друг с другом до получения результата. Количество необходимых сложений зависит от размера перемножаемых чисел, который квадратично увеличивается с ростом n. Поэтому время выполнения этой операции линейно растёт с ростом n.

Умножение log(n)-разрядных целых чисел занимает время O(1), если мы вспомним энтропийную формулу Шеннона. В теории информации количество информации, передаваемой сообщением, измеряется с помощью его энтропии. Энтропия двух независимых сообщений A и B определяется как H(A|B) = H(A) + H(B), поэтому умножение log(n)-разрядных целых чисел можно рассматривать как объединение нескольких независимых сообщений с одинаковым количеством битов, что уменьшает общую энтропию объединённого сообщения. В результате получается более быстрый алгоритм умножения, который с точки зрения теории информации занимает время O(1).

(если вы не изучали теорию информации, то скорее всего не знаете, что значит дробное число бит -- красивое объяснение на хабре)

Ну ладно, ладно, а то ещё скажете так на собеседовании 😂

Умножение n-разрядных целых чисел занимает O(n^2)
(по Карацубе, O(n^1.5849))

Умножение log(n)-разрядных целых чисел занимает O(n log n)

P.S. Но на самом деле, в некоторых экзотических теориях возможно и O(n) и O(1), как-нибудь расскажу.

Иногда я пишу O(n!) код, чтобы научить пользователей терпению 😎
Напишите кстати что-нибудь подобное, императивную и рекурсивную версии.

Поучительная практика -- писать тесты для макросов и темплейтов.

По поводу серии постов "умножение n-разрядных чисел за O(n)". Проконсультировался у ребят из Массачусетского технологического института, где проходил курсы по software design, и PhD предложил почитать вот эту лекцию "Hashing: Universal and Perfect Hashing".

Речь о специфической вычислительной модели, ориентированной на продуктивную реализацию хэш-памяти. Я делал курсы по АСД во многом на основе 15-121 CMU, ну а 15-421 это более продвинутый. Хочу добавить эту тему в мои дополнительные курсы по АСД повышенной сложности, для которых использовал также материалы ШАД. И есть ещё одна секретная работа по этой теме из Renmin University of China, которую дам только курсантам.

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

P.S. Пацаны из MIT, кстати, позвали к себе поработать, стартап какой-то у них по автоматической "перекодировке" кода на разных языках. Ответил, что против утечки мозгов "Уезжай!" (с) Цой "Кто может уехать — уезжайте" (с) Карпин подумаю, и зимой решу.

P.P.S. Дорогие, не волнуйтесь, вас не брошу конечно )

8 признаков плохого программиста с т.зр. тимлида

1. Он работает в macOS
2. Он использует более чем 1 монитор
3. Он обращается к ChatGPT
4. Он не может обратить связный список
5. Он постоянно наливает себе кофе
6. Он изучает новые языки программирования ради "фана"
(особенно тимлидами не любим хаскель)
7. Он не пушит в прод по пятницам
(хочет отвлечься от работы на выходных?)
8. Он работает над сайд-проектами после работы