Мысли сторонникам мира 17.02.2024. Грустный пост.

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

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

Надеюсь, я пишу это из 1942 года, а впереди и 1943, 44, 45, и 2000, и очередной Фукуяма предскажет нам конец истории.

Сегодня очень многое решают деньги и связи, решает сила. Моральные соображения и мышление вдолгую чаще идут лесом. Добро, справедливость, репутация остаются в наших узких кругах. Они не побеждают сами по себе, им нужны мы: умные, сильные и умеющими жить в реальном мире.

Кто виноват? Мир такой.
Что делать? Оставаться собой и становиться сильными. Зарабатывать деньги и строить связи. Лепить уютный мир вокруг себя из того что есть. А там глядишь и всему миру сделаем чуть лучше.

24 февраля. Кадр 1, дубль Х.

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

Ладно, реальная картинка ещё сложнее. Силы разума когда-нибудь соберутся. Да и Кощеи смертны.

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

В память Навального.

Человек отдал жизнь за то, чтобы мы жили лучше.

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

И, без сомнения, достоин свечи в память
https://www.remember-navalny.io/

Главное чтобы код программы был максимально приближен к бизнес-логике 🤔

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

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

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

В 2017 году я был почти насильно пересажен на Kotlin, смотрел много лекций и постепенно пришел к тому, что главное совсем не гибкость конструкций, а их читаемость. Код куда чаще читается, чем пишется; и код на Scala, в который требуется вникать часами, куда хуже кода на Kotlin, который пусть длиннее, но зато куда проще для понимания.

———

Сейчас у меня новый виток отказа от сложных конструкций.

Если у вас начинающий и технически сложный стартап — ключевое, чтобы код понимали не только разработчики, а вообще все члены стартапа, проектирующие продукт: включая менеджеров, дизайнеров. Если вы хотите быстро пробовать 100500 гипотез, экспериментируя с разными пользователями, код продукта = документация для всех.

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

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

Если есть 5 похожих режимов с похожими настройками, но потенциально разные с точки зрения продукта: не страшно, что у вас будет дублирование, всем не сложно привыкнуть менять одно и то же 5 раз если оно относится к 5 режимам. Куда страшнее, если у вас будет многоуровневое наследование с виртуальными функциями, и пол-команды не смогут в этом разбираться. А потом еще выяснится, что для пользователей нужно чуть другое устройство этих режимов, их 4, а не 5 — и нужно будет переписывать либо костылить.

Думаю, целевой уровень сложности кода: процедурное программирование + структуры данных + лямбда-функции для работы с контейнерами. На этом вполне можно описать примерно всю бизнес-логику (которая часто будет изменяться); и это посильно всем сколько-нибудь знакомым с программированием.

———

Предвижу возражения: задача продуктов тщательно исследовать, что и для кого делаем, написать четкие требования, и только потом отдать в разработку. А дальнейшая разработка — ответственность разработчиков.

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