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

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

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

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

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

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

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

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

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

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

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

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

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

———

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

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

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

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

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

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

———

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

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

Раз 20 встречал в лесу следы медведя. И сегодня наконец встретил его самого:)

Угадате, что нужно сделать чтобы видеть в фейсбуке рекламу акселераторы стартапов и конференции?))

Податься штук в 20 и не обращать внимания на другую рекламу 😊

Правда, акселераторы в рекламе какие-то странные, то платные, то надо 100 листов заполнять только чтоб податься