Главное чтобы код программы был максимально приближен к бизнес-логике 🤔
Уже не в первый раз я фиксирую у себя изменение взглядов на разработку. В частности, на написание кода. Подумал, что многое из этого очень гармонирует с логикой мира.
В детстве я очень любил строить из конструктора ЛЕГО. И к программирование для меня — как построение, комбинирование логики из уже готовых кубиков, которые авторы языка уже сделали измашинных кодов .
Почти всю студенческую жизнь я оценивал языки программирования по гибкости возможностей, которые они предоставляют. Если в Scala есть кубики, которых нет в C++ или Java, значитScala лучше.
В 2017 году я был почти насильно пересажен на Kotlin, смотрел много лекций и постепенно пришел к тому, что главное совсем не гибкость конструкций, а их читаемость. Код куда чаще читается, чем пишется; и код на Scala, в который требуется вникать часами, кудахуже кода на Kotlin, который пусть длиннее, но зато куда проще для понимания.
———
Сейчас у меня новый виток отказа от сложных конструкций.
Если у вас начинающий и технически сложный стартап — ключевое, чтобы код понимали не только разработчики, а вообще все члены стартапа, проектирующие продукт: включая менеджеров, дизайнеров. Если вы хотите быстро пробовать 100500 гипотез, экспериментируя с разными пользователями, код продукта = документация для всех.
Паттерны проектирования, избегание дублирований - это все для гигантских проектов с большими командами разработки.
А если стартап маленький, то ключевое чтобы код максимально точно описывал желаемую бизнес-логику, и чтобы его могли все прочесть.
Если есть 5 похожих режимов с похожими настройками, но потенциально разные с точки зрения продукта: не страшно, что у вас будет дублирование, всем не сложно привыкнуть менять одно и то же 5 раз если оно относится к 5 режимам. Куда страшнее, если у вас будет многоуровневое наследование с виртуальными функциями, и пол-команды не смогут в этом разбираться. А потом еще выяснится, что для пользователей нужно чуть другое устройство этих режимов, их 4, а не 5 — и нужно будет переписывать либо костылить.
Думаю, целевой уровень сложности кода: процедурное программирование + структуры данных + лямбда-функции для работы с контейнерами. На этом вполне можно описать примерно всю бизнес-логику (которая часто будет изменяться); и это посильно всем сколько-нибудь знакомым с программированием.
———
Предвижу возражения: задача продуктов тщательно исследовать, что и для кого делаем, написать четкие требования, и только потом отдать в разработку. А дальнейшая разработка — ответственность разработчиков.
Может быть все и так, а я пока не умею делегировать. Но думаю, если продукт сколько-нибудь сложный, обязательно потребуется несколько итераций на базе фидбека от клиентов, agile. И, если строить стартап малыми силами на свои, чем больше людей понимают код — тем эффективнее.
Уже не в первый раз я фиксирую у себя изменение взглядов на разработку. В частности, на написание кода. Подумал, что многое из этого очень гармонирует с логикой мира.
В детстве я очень любил строить из конструктора ЛЕГО. И к программирование для меня — как построение, комбинирование логики из уже готовых кубиков, которые авторы языка уже сделали из
Почти всю студенческую жизнь я оценивал языки программирования по гибкости возможностей, которые они предоставляют. Если в Scala есть кубики, которых нет в C++ или Java, значит
В 2017 году я был почти насильно пересажен на Kotlin, смотрел много лекций и постепенно пришел к тому, что главное совсем не гибкость конструкций, а их читаемость. Код куда чаще читается, чем пишется; и код на Scala, в который требуется вникать часами, куда
———
Сейчас у меня новый виток отказа от сложных конструкций.
Если у вас начинающий и технически сложный стартап — ключевое, чтобы код понимали не только разработчики, а вообще все члены стартапа, проектирующие продукт: включая менеджеров, дизайнеров. Если вы хотите быстро пробовать 100500 гипотез, экспериментируя с разными пользователями, код продукта = документация для всех.
Паттерны проектирования, избегание дублирований - это все для гигантских проектов с большими командами разработки.
А если стартап маленький, то ключевое чтобы код максимально точно описывал желаемую бизнес-логику, и чтобы его могли все прочесть.
Если есть 5 похожих режимов с похожими настройками, но потенциально разные с точки зрения продукта: не страшно, что у вас будет дублирование, всем не сложно привыкнуть менять одно и то же 5 раз если оно относится к 5 режимам. Куда страшнее, если у вас будет многоуровневое наследование с виртуальными функциями, и пол-команды не смогут в этом разбираться. А потом еще выяснится, что для пользователей нужно чуть другое устройство этих режимов, их 4, а не 5 — и нужно будет переписывать либо костылить.
Думаю, целевой уровень сложности кода: процедурное программирование + структуры данных + лямбда-функции для работы с контейнерами. На этом вполне можно описать примерно всю бизнес-логику (которая часто будет изменяться); и это посильно всем сколько-нибудь знакомым с программированием.
———
Предвижу возражения: задача продуктов тщательно исследовать, что и для кого делаем, написать четкие требования, и только потом отдать в разработку. А дальнейшая разработка — ответственность разработчиков.
Может быть все и так, а я пока не умею делегировать. Но думаю, если продукт сколько-нибудь сложный, обязательно потребуется несколько итераций на базе фидбека от клиентов, agile. И, если строить стартап малыми силами на свои, чем больше людей понимают код — тем эффективнее.
👍9❤4
Дорогие, всех с 8 марта 💐
Всем счастья, любви, тепла и добра!
--
Цветочки из походов
Всем счастья, любви, тепла и добра!
--
Цветочки из походов
❤9
Местная очередь из желающих проголосовать за мир и будущее
👍15🤔1🤡1
Угадате, что нужно сделать чтобы видеть в фейсбуке рекламу акселераторы стартапов и конференции?))
Податься штук в 20 и не обращать внимания на другую рекламу 😊
Правда, акселераторы в рекламе какие-то странные, то платные, то надо 100 листов заполнять только чтоб податься
❤3
Сходил в поход с аж 2мя ночевками (впервые за последние уже почти 2 года😔🙈)
И все собираюсь про стартап рассказать, тут много интересного. Но как-то слишком много, оно все время разное и постоянно меняется))
И все собираюсь про стартап рассказать, тут много интересного. Но как-то слишком много, оно все время разное и постоянно меняется))
👍6🔥5❤1
This media is not supported in your browser
VIEW IN TELEGRAM
👍13
This media is not supported in your browser
VIEW IN TELEGRAM
❤6😁3