Как же хочется иногда остановить дикую гонку разработки и получить удовольствие от вдумчивого, размеренного написания кода. Как же не хватает времени на обдумывание алгоритмов и исследование перспективных архитектурных вариантов системы. Как же тянет протянуть руку к стоп-крану и остановить взбесившийся конвейер по штамповке недолговечных решений.
Если вы устали от бесконечных дедлайнов, совещаний и спринтов, то, возможно, вам придётся по душе концепция медленного программирования. По своей сути она полностью противоположна мейнстриму — постоянному ускорению разработки. Попробуем рассмотреть все плюсы и минусы этой концепции.
Медленная жизнь
Медленное программирование — это часть большого «медленного движения» (Slow Movement). Это культурный тренд, к которому осознанно обращаются всё больше людей. Медленное движение имеет множество течений и направлений, которые объединены одной общей идеей: люди устали от сумасшедшего ритма жизни, хотят замедлиться и снова получать удовольствие от работы, образования, чтения, питания и других повседневных занятий.
Медленное искусство пропагандирует не только тщательное и продуманное создание произведений искусства, но и протестует против быстрой пробежки туристов по музеям и достопримечательностям.
Медленное чтение борется с противоестественным скорочтением и агитирует за медленное и вдумчивое изучение книг, перечитывание и анализ текстов.
Медленное питание — это просто обычное здоровое питание безо всяких фастфудов и полуфабрикатов. Сторонники этого направления ратуют за возврат культуры застолья и за сохранение национальных и региональных кулинарных традиций.
Медленное телевидение противостоит клиповому монтажу, дёрганому ритму и беспрецедентному падению уровня телевизионных передач. Всё большую популярность набирают каналы, которые транслируют многочасовые медитативные записи природы, поездок, путешествий.
Медленное путешествие, в свою очередь, осуждает слишком быстрое перемещение, которое значительно уменьшает удовольствие от поездок и притупляет впечатления от незнакомой страны. Сюда же примыкает и медленная фотография. Она призывает делать вдумчивые редкие кадры вместо десятков тысяч фотографий, которые оседают в цифровых архивах их авторов.
Есть ещё медленное садоводство, медленное образование, медленное воспитание, медленная наука, медленная мода… Количество направлений этого движения постоянно растёт. Люди хотят, чтобы их наконец оставили в покое и дали пожить в своё удовольствие.
Программисты — тоже люди и тоже порядком устали от бесконечной погони за призрачными показателями и результатами. Поэтому в этом ряду направлений и возникло медленное программирование.
Медленное программирование
Концепция медленного программирования подразумевает:
продуманное и вдумчивое проектирование;
большое внимание к деталям;
тщательное тестирование;
стремление к совершенству.
Попробуем разобраться, что это означает на практике.
1. Тщательное проектирование
Для того чтобы запрограммировать что-нибудь ненужное, требуется сначала всё как следует спроектировать. Это означает, что нужно:
как следует проанализировать пользовательский опыт;
провести поиск оптимальных решений;
обдумать и проверить различные варианты реализации.
Любая хорошая, добротная вещь начинается с исследования и проекта. В современном корпоративном мире эту работу обычно выполняют не программисты, но это не так важно. В любом случае торопиться тут точно не стоит — прежде, чем отрезать, нужно как следует отмерить.
2. Программирование без компьютера
Помните мемы о «ленивых» программистах, которые вместо того, чтобы усердно стучать по клавиатуре, занимаются неизвестно чем? С точки зрения эффективного менеджера стороннего наблюдателя они просто плюют в потолок и зря получают зарплату.
Сложно бывает объяснить, что:
почти любой фрагмент кода требует обдумывания и нескольких внутренних итераций его улучшения;
программист не должен начинать разработку сразу после получения ТЗ;
обдумывание алгоритмов вдали от клавиатуры — важная часть его работы.
Кстати, качество этой самой работы не может оценивается количеством написанного кода за единицу времени.
3. Стремление к совершенству
Всем известно, что совершенства достичь невозможно, к нему можно только стремиться. Но хочется хотя бы начать двигаться в его сторону. Для этого требуются:
тщательное проектирование дизайна и оформления приложения;
кропотливый поиск наиболее эффективных решений;
проведение НИР (научно-исследовательских работ) — поиск наилучшего решения путём экспериментов.
Один из способов улучшения качества кода — это парное программирование. Для менеджеров это кошмар: двойное увеличение ресурсов на решение поставленной задачи.
Возможно, в какой-то момент может прийти мысль, что совершенство — это минимализм и простота: кода, интерфейса, архитектуры. Вряд ли можно достичь истинного совершенства на базе множества лишних надстроек, библиотек и фреймворков. Многолетнее легаси тоже не добавляет системе изящества.
4. Качество и отказ от долгов
Ревизия и рефакторинг старого кода не менее важны, чем разработка нового. Естественно, рефакторинг нужно делать осторожно — медленно и вдумчиво. И обязательно сопровождать тестированием — регрессионным и автоматическим.
Термин «технический долг» лучше всего вообще исключить из лексикона:
всё, что требуется для проекта, делается сразу, а не откладывается на потом;
никаких временных компромиссов, «костылей» и «велосипедов» в угоду срокам.
5. Получение удовольствия от процесса
Этот пункт — самый «эгоистичный», но, пожалуй, самый важный. Медленное программирование — это способ снова превратить разработку кода в искусство. Это путь к тому, чтобы вернуть программисту:
гордость за свою работу и за продукт своего труда;
здоровый баланс между работой и жизнью;
комфортный ритм рабочих процессов;
возможность саморазвития.
Быстрее — не значит лучше
Множество статей и книг учат нас, как стать эффективнее и быстрее работать. При этом почему-то между эффективностью и скоростью ставят знак равенства. Корпоративный мир требует постоянного ускорения и сокращения трудозатрат. Нас окружают методики быстрых итераций, таск-трекеры и дедлайны. Всё нацелено на быстрое получение прибыли и сокращение времени между проектированием и внедрением.
Значит, времени на качественную работу остаётся всё меньше. Иногда, конечно, шедевры получаются случайно. Но чаще всего для того, чтобы сделать что-то качественное и красивое, нужно время. Его-то как раз у нас и нет.
Снимаем розовые очки
Теперь попробуем рассмотреть другую сторону проблемы. Перестанем мечтать об идеальном мире с бирюзовыми единорогами бездонными бочками трудозатрат. В современной корпоративной реальности медленное программирование — это утопия:
бизнес нацелен на быстрое получение прибыли и опережение конкурентов;
увеличение трудозатрат снижает прибыль и конкурентоспособность решения;
игра не стоит свеч — идеальный сферический продукт в вакууме, на разработку которого потрачен год, устаревает через месяц после выпуска;
все хотят знать, когда получат прибыль — бесконечные проекты с невозможностью прогнозирования сроков и результатов никому не нужны;
медленному программисту будет тяжело работать в команде, в которой остальные пишут код быстро;
шедевры никому не нужны, рекорды продаж — у однодневных поделок.
Существует также опасность уйти в штопор перфекционизма — любой проект можно совершенствовать до бесконечности. Здесь важно уметь вовремя остановиться.
Вдобавок на горизонте замаячило нечто — как нас стращают в СМИ, ChatGPT скоро сможет заменить разработчиков. Достаточно будет лишь правильно поставить задание, и решение — раз-два, и готово! Безо всяких сроков и затрат — полная противоположность медленному программированию. Дело за малым: знать бы только, как это задание корректно сформулировать.
Однако есть всё же оазисы, где медленное программирование не будет белой вороной:
пет-проекты, где медленный программист — сам себе хозяин;
НИР в рамках больших коммерческих проектов — выделенная песочница для неторопливых поисков истины.
Сергей Павлович Королёв однажды сказал: «Можно сделать быстро, но плохо, а можно — медленно, но хорошо. Через некоторое время все забудут, что было быстро, но будут помнить, что было плохо. И наоборот». Концепция медленного программирования — это одна из попыток неравнодушных профессионалов вернуть качество, надёжность и красоту в наш мир недолговечных пластмассовых решений.
Комментарии (70)
vkomp
07.04.2023 06:43+6В своей итерации бизнес тоже можно разделить на "медленный" и нет. И в принципе всё сводится к философии и мировоззрению: живешь ли в согласии с собой и своим ритмом или выпрыгиваешь из штанов, чтобы угодить KPI... и стоит напомнить что все эти показатели - это коэффициенты в отвлеченных единицах, а даже не в попугаях.
victor_1212
07.04.2023 06:43+3> В своей итерации бизнес тоже можно разделить на "медленный" и нет. И в принципе всё сводится к философии и мировоззрению:
если про бизнес, то необходимо учитывать environment, типа зайцы в лесу бегают быстро не потому что у них такая философия, а потому что волк имеется + законы дарвина,
так и с бизнесом - если конкуренция острая, на философию + мировоззрение время обычно не хватает, конечно если экономика не рыночная, или конкуренция временно отсутствует (такое бывает) можно и на философию время найти, и на многое другое тоже,
ps
если хотите медленного, вдумчивого программирования, выбирайте области hi tech подальше от "конвейерной " разработки sw, например при разработке новой os обычно не торопятся
vkomp
07.04.2023 06:43+1Да я вроде не жаловался. Скорее о том, что "медленно/быстро" можно на что угодно натянуть, как и написано в начале статьи. Но к концу блок, что виноват бизнес. И мой тезис о том, что бизнес тоже не последняя инстанция.
У меня ассоциация с психологическим вопросом "Зачем?", где на какой-то итерации всё упирается "А вот хочу так!"victor_1212
07.04.2023 06:43+1понимаю, упирается, но возможно для большинства деловых людей в тезис "выжить бы еще год-другой", хотя одно другого не исключает :)
"кто виноват" вообще обширная тема, для начала желательно определиться с вопросом согласно ли общество платить за комфорт и hi tech стрессом связанным с конкуренцией, вероятно простого ответа нет
vkomp
07.04.2023 06:43у меня нет таких вопросов в повестке. Уже как-то расставил в систему, которая меня устраивает. В основном вижу, что вы рассматриваете систему в статике, в разрезе перекосов в какую-то сторону. В динамике особых проблем не наблюдаю, потому что когда-то узнал про законы диалектики. Переход количества в качество отлично объясняет вложения в хайтек, нет?
Про "виноват" тоже особо не напрягаюсь. Потому что переношу психологию личности на организации и на общество. Я в полном восторге от треугольника Карпмана, хотя его больше склоняют для липких манипуляций. В контексте темы "виноватые" активно участвуют и получают нехилые бонусы в общей системе. Вообще, если роль денег понизить, то всё вокруг богаче связями становится.victor_1212
07.04.2023 06:43> Переход количества в качество отлично объясняет вложения в хайтек, нет?
каким образом?
vkomp
07.04.2023 06:43+1прямым. Сначала издержки значительные, но вложения аккумулируются, на каком-то шаге издержки падают до минимума, а качество остается и масштабируется. Дороги с твердым покрытием, пар, жд, самолеты, бесплатный вай-фай в метро.
victor_1212
07.04.2023 06:43> Дороги с твердым покрытием, пар, жд, самолеты, бесплатный вай-фай в метро.
дороги, мосты, аэропорты, и пр. обычно называют инфраструктурой, в которую конечно надо вкладывать, что делали начиная с времен римской империи построив стратегические дороги, виадуки и т.д., о чем догадались без диалектики
vkomp
07.04.2023 06:43диалектика не является технологией. Это вроде как философия. Обычно догадываются без нее - тут вы правы.
vvbob
07.04.2023 06:43+9Самые "быстрые" проекты, которыми я занимался в своей рабочей карьере (а их уже было овердохрена), в которых все с горящими жопами писали код, работали в выходные, оставались после работы что-бы писать код.. все они без исключения оказались пустышками. Бизнес тупо выбросил деньги, люди бесполезно потратили свое время и здоровье на все это, ни один из таких проектов не взлетел.
Nansch
07.04.2023 06:43+3А это значит, что если кодер не владелец бизнеса и не в доле, то это не его проект. Подчинённые совершенно необдуманно разменивают ресурсы своих собственных жизней на осуществление чужих желаний. Бизнес хотел на скорую руку проверить код и все работали с горящими жопами, но проверка не удалась, за попытку спасибо, возвращайтесь в понедельник.
vvbob
07.04.2023 06:43+2У меня были проекты, когда это даже под интересы бизнеса не подтянешь. Крупная бюрократическая машина, в недрах которой рождаются выбросы инферно в виде новых "прорывных" проектов, на которых сначала по полгода-год нихрена не происходит, а потом перед тем как надо отчитываться руководству о "прорыве", нанимаются люди и им ставится задача за месяц написать то, что по хорошему надо было год вдумчиво разрабатывать. По итогу успешный менеджер сваливает на повышение, прогнувшись перед руководством, провал проекта сваливают на тупых разработчиков и мелочь типа тимлидов, после чего все незамедлительно приступают к другому столь же прорывному проекту. Не шучу, практически дословное описание одного из проектов в котором лично имел неудовольствие поучаствовать. Сейчас бы я сразу свалил с такого, тогда еще был молодым и наивным..
AnyLog
07.04.2023 06:43+14мой племянник 27 лет ха-ха-ха (фронтендер) недавно сказал, что устал от бесконечной гонки технологий и хочет уйти в бэк-енд на яву, где вроде поспокойней
stackjava
07.04.2023 06:43+1Там тоже не сильно спокойно.
Ява меняется медленно но окружайка в виде бд, очередей сообщений, мониторинга, метрик и прочего... Это все нужно тоже знать и от проекта к проекту оно разное.
aploskov
07.04.2023 06:43+1Да не, там просто нужен опыт и выдержка. Ява - идеальный инструмент для тех, кто часть корабля, часть команды. Все эти MQ, базы, реактивщина, Spring Native, K8s, Micrometer, фп - почти все это приехало из других продуктов, уже отшлифованным - если интересовался другими языками/технологиями, то лишь чувствуешь удовлетворение, что тебе подлили ещё немного фруктового йогурта в твою программистскую жизнь.
Вопрос в другом: медленное программирование может привести к медленному карьерному росту, к медленному повышению доходов. Удовлетворяет ли это тебя, или ещё есть силы брыкаться?
Тут ничего нового, я "медленных программистов" встретил лет 6 назад, в начале своей карьеры. Это не инновация, это возраст топикстартера. Добро пожаловать ему, так сказать. ????
Джависты в их вечном бою, на пути в Вальхаллу, и скоро мы там будем.
MinimumLaw
07.04.2023 06:43+58На поверку оказывается, что "медленное" программирование не "медленее" быстрого, а вот затрат на него надо в разы меньше. Что технических, что эмоциональных.
Впрочем, пусть расцветают сто цветов, пусть соперничают сто школ (с). В идеальном мире должны быть и спринтеры и марафонцы. В конце концов людям с разным темпераментом и в разное время оказывается комфортнее в разных концепциях.
Myclass
07.04.2023 06:43+11Интересная статья. Спасибо. Медленная работа приходит также с опытом. Когда начинаешь замечать, что ты за свой, условный час выдаёшь похожее количество результата, как твои коллеги за неделю. Ты можешь смотреть вперед и делать за раз правильные шаги, не заниматься пржиранием времени в бесконечных встречах, работать безошибочно, иметь в головемного паттернов для решения любых задач, в личных библиотеках иметь наработки, которые мгновенно можно использовать итд.
Kelbon
07.04.2023 06:43+17Чем хуже написан код, тем больше работы он провоцирует своим существованием.
По факту можно работать медленнее и мудрее и успевать гораздо больше
panzerfaust
07.04.2023 06:43+24На самом деле вы описываете обычное поведение профессионального инженера. Все типичные истерики бизнеса и менеджмента о том, что фича нужна вчера и поэтому нам нужно наговношлепать что-то как-то и без тестов - это дешевый балаган для новичков. Профессионала наняли за большие деньги ровно затем, чтобы код был чистый, быстрый, надежный и протестированный. Если по мнению профессионала это занимает столько-то времени, то на этом разговор о времени в общем-то и заканчивается.
bestann
07.04.2023 06:43+4Проблема: хорошо работать невыгодно. И руководство считает работу по заявкам Jira. Мне пишут, что мало делаю (DevOps). Видимо надо тяп-ляп, потом новые заявки и новые исправления. Зато по статистике все Ок.
ofigenov
07.04.2023 06:43+1Когда-то уже давно я работал в одной, которая уже тогда была г..ном, компании, так вот там так и было - разработчики, которые писали быстро и без ошибок, оценивались как те, кто мало работает, т.к. якобы маленькие временные затраты и наоборот, те кто писали долго, в своем долгом коде допускали кучу ошибок, на которые потом получали кучу риквестов на исправление - те получали более высокие премии, т.к. по трудозатратам выходило, что они больше работают - вот такой бред. Я прям видел, как некоторые особенно хитропопые кодеры прям с наслаждением слушали мои к ним претензии, что они опять в очередной раз нагадили в уже в прошлый раз исправленном месте и довольно улыбались, предвкушая как они будут меееедленннно исправлять свои же ошибки, с постоянными перекурами и чаепитиями и потом за это получать деньги. А меня наоборот бесил этот подход, что это как гиря на ногах, когда ты хочешь сделать задачу и взять новую, но за это ты получишь меньше тех, кто мусолит одно и то же годами. Еще запомнился один момент, совещание, идет обсуждение будущего запуска приложения и необходимого для этого перерыва в работе заказчика, так вот коллега заявляет, что ему надо 16 часов на конвертацию данных, а я прекрасно зная, что он использует костыльный конвертер, который в свое время я тоже дорабатывал, он мне как раз не понравился, я от него отказался и написал все на PLSQL, используя фичи Оракла, чтобы максимально быстро загрузить данные в БД я мог этот объем данных, а там речь шла про данные всего 2000 клиентов, залить меньше, чем за минуту на то, что этому коллеге понадобилось 16 часов, так вот я озвучиваю эту информацию, что коллеге стоит взять мой уже готовый и много раз использованный конвертер, который решит его проблему и загрузит все за минуту, но для этого коллеге придется наконец-то познать PLSQL, т.к. мы работаем с Ораклом и это его обязянность, на что от манагеров, что присутствовали на совещании я услышал, что дескать не может быть, чтобы то, что работает 16 часов можно было сделать за минуту и самое убойное, что то что работает всего лишь минуту - это фигня какая-то, а вот то что работает 16 часов - это крутая вещь, которая пашет целых 16 часов и это в софтверной компании происходило)). И до сих пор, я уже сменил несколько компаний, но везде одно и то же, что пахать то ты можешь больше и быстрее других, быть умнее и производительнее других, знать больше и лучше других, принимать благодаря этому оптимальные архитектурные решения и делать изящные и мегапроизводительные вещи, но получать ты будешь столько же, а то и меньше самого медленного и специально имитирующего работу коллеги, т.к. для манагеров трудной задачей считается та, которую долго делали и наоборот, то что сделали быстро - это значит было легко и платить там не за что. А еще проблема в том, что манагерами и тимлидами над разработчиками становятся не лучшие из лучших разработчики, а худшие из худших, которым как раз вся эта тема малоинтересна, а им интересно свою попу примастить на чужой шее и получать деньги за чужие достижения.
Kolymbarii
07.04.2023 06:43+5Последние полтора года так и работают над своим проектом. Единственное, на что нужно обращать внимание - это ритм, медленно - не значит мало. По результатам работы - даже тот же объем проделанной работы оказался выше, чем обычно, только это заметно не через неделю, а через год.
Какие плюсы получил: поскольку работаю один, то приходится все автоматизировать и обвязывать кучей различных тестов, чтобы не тратить время на выискивание проблем. Каждый шаг приходится продумывать, чтобы не ошибиться и потом не переделывать
Минусы вдумчивого подхода: это продумывание необходимости использования того или иного тренда. Многие вещи упрощаются, даже при продумывании дальнейшего роста продукта - все равно стараешься сделать проще и понятнее, пропало много модных слов Spark, Kafka, Java 25 версии и Rust лучше всех и т.д. - используются только то, что действительно необходимо. Много трачу времени на продумывание схем данных и т.п.
По результатам было две DDoS атаки, два раза падала сеть, но я очень рад, что система выдержала рост запросов и вела себя достойно. Были шероховатости, но для меня результат - что не упала, с учетом что всего один домашний сервер (десктоп мини-пк).
В сухом остатке: я в таком ритме чувствую себя комфортно, даже не сбиваюсь с планов. Ожидаю в сентябре выйти в публичный доступ.
Rive
07.04.2023 06:43Как домашний провайдер отнёсся к DDoS-атаке, если не секрет?
MountainGoat
07.04.2023 06:43Вангую: тактично не заметил, потому что подумал, что человек порно качает по uTP.
john_samilin
07.04.2023 06:43+5Все так. Я тоже в какой-то момент решил поэкспериментировать и написать более-менее работающий продукт без внешних зависимостей (реакта там, сборок, вот этого всего). Кайфовое заняте
Plesser
07.04.2023 06:43+20ChatGPT скоро сможет заменить разработчиков. Достаточно будет лишь правильно поставить задание, и решение — раз и готово! Безо всяких сроков и затрат — полная противоположность медленному программированию.
аха, как показывает мой опыт правильно поставить задачу оказывается едва ли не сложней чем написать сам код. Зачастую у нас приходится интуитивно писать код, по ходу разбираясь как скрестить хотелки заказчика с тем что есть.
Boris3000
07.04.2023 06:43Зачастую у нас приходится интуитивно писать код
Так "нейросеть" -- это и есть модель интуиции. Как-то не обнадёживающе звучит...
engine9
07.04.2023 06:43+13Я трехмерщик и стараюсь не использовать в своих проектах чужие модели. В итоге у меня огромные локации километрового размера занимают десятки мегабайт в памяти (т.к. всё что можно оптимизировано), зато какая-нибудь сторонняя модель ёлки может весить двести мегабайт.
И меня очень удивило, что далеко не всем заказчикам нужен фотореализм, есть много людей кому нравится когда выглядит по-компьютерному, эскизно.
IvanSTV
07.04.2023 06:43+4бизнес нацелен на быстрое получение прибыли и опережение конкурентов;
То есть, проще говоря, коммерция убивает технологию в пользу сроков
увеличение трудозатрат снижает прибыль и конкурентоспособность решения;
измерение конкурентоспособностью качества работает в среднем на ухудшение качества. Потому что при определенном соотношении цена\качество цена играет первичную роль, есть достаточно небольшое поле, где качество перебьет цену.
игра не стоит свеч — идеальный сферический продукт в вакууме, на разработку которого потрачен год, устаревает через месяц после выпуска;
концептуально продуманный продукт не устаревает, как правило. Как, например, может устареть продуманная на хорошем концептуальном уровне программа для распознавания печатного текста из изображения? Никак. К ней можно прикручивать словарики и алгоритмы проверки и установки, но определять, где буковки, а где фигня - это никогда не устареет, разве что в электронку переведется весь текст в мире. Для софта основной фактор концептуального устаревания - развитие "железа". Например, гипертерминал устарел для массового использования, так как появились массовые дешевые и быстрые железные решения связи между девайсами мимо кабеля. Но таких продуктов меньшинство, и грамотно продуманное ядро использоваться может годами, и там не требуется ничего трогать, особенно если там легко модульно накручивать новый функционал.
все хотят знать, когда получат прибыль — бесконечные проекты с невозможностью прогнозирования сроков и результатов никому не нужны;
вообще-то социально значимая задача должна решаться до момента РЕШЕНИЯ задачи, и столько. сколько требуется для РЕШЕНИЯ ЗАДАЧИ, а получение прибыли вообще к решению задач не относится никак. Если прибыль никто не получит, но социальная проблема будет решена, получается, решать ничего не надо? Вот по такому принципу и не решается огромное количество проблем.
шедевры никому не нужны, рекорды продаж — у однодневных поделок.
ориентация на рекорды продаж - путь к технологической деградации. Вместо вдумчивого переписывания и структурирования ранее написанных программ миллионы программистов занимаются прикручиванием пустопорожних свистоперделок побыстрей в продакшн, чтобы опередить конкурентов. Результат немного предсказуем.
Вообще, имхо, технологии в IT развиваются в основном не благодаря рыночной гонке за прибылью, а вопреки. Коммерсанты наклепают в продакшн, а потом люди годами сидят и правят баги. Буквально вчера наткнулся на микрософтовскую ошибку - на мелкософтовском форумчике висит уведомление, что они-де знают об этом, но решений не дали (прошло 9 месяцев), патчем не закрыли, обратной связи нет, какой-то испаноязычный парниша дал скрипт на PowerShell, как принудительно закрыть кривой процесс, но и это решение работает через раз. А "десятка" уже несколько лет с этой ошибкой живет, уже 11-ю версию выпустили, потом будет еще, но дописывать не будут. Потому что им затратно - прибыль берут себе, а затраты раскладывают на пользователя,на исправление ошибок кладут болт.
rdo
07.04.2023 06:43+1Вообще, в последние годы все стали бредить disruptive technologies, никому уже не нужно медленно выгрызать долю рынка качеством, все хотят перевернуть стол.
0xd34df00d
07.04.2023 06:43+1То есть, проще говоря, коммерция убивает технологию в пользу сроков
Вы слышали что-то о Bell Labs или хотя бы о всяких Microsoft Research?
Ну а сайтики штамповать — да, там в пользу сроков. Но сорян, внутренняя сложность штамповки сайтиков ниже.
Как, например, может устареть продуманная на хорошем концептуальном уровне программа для распознавания печатного текста из изображения?
Модель будет давать все больше ошибок по сравнению с топовыми.
Если прибыль никто не получит, но социальная проблема будет решена, получается, решать ничего не надо? Вот по такому принципу и не решается огромное количество проблем.
И не решаете её лично вы с единомышленниками за бесплатно потому, что… Почему?
Вот и другие потому же не решают.
Iustinianus
07.04.2023 06:43+15Кстати, что это вообще значит — работать быстро?
Первые наставления по этому, казалось бы, очевидному вопросу я получил от инструктора парашютного спорта Виноградова, выпускавшего меня много лет назад в первый прыжок с самолёта.
Сейчас парашютистов-перворазников вывозят на больших транспортных самолётах, покидать которые в воздухе довольно просто: парашютист подходит к открытой двери или люку, делает шаг наружу — и все! Для этого надо, конечно, преодолеть некое внутреннее психологическое сопротивление: много миллионов лет назад наш обезьяноподобный предок, свалившись с какой-нибудь скалы, положил начало формированию во всем роде человеческом прочного инстинкта, так сказать, уважения к высоте.
Но никаких специальных навыков, никакого особого умения для того, чтобы покинуть самолёт через дверь, не требуется. Другое дело — У-2, с которого когда-то прыгали мы. На нем парашютисту приходилось, преодолевая сопротивление встречного потока воздуха (все-таки сто километров в час), встать со своего места, а затем, перехватываясь руками за стойка центроплана, вылезти на крыло и устроиться одной ногой на его задней кромке, а другой — на подножке, укреплённой снизу фюзеляжа. Ко всем этим операциям надо было приспособиться.
Виноградов учил нас этому, держа секундомер в руках. Увидев, с какими отвратительно суетливыми, конвульсивными движениями, принимая последовательно самые нелепые позы, какие только можно себе представить, мы выполняем эту операцию, он поморщился и изрёк:
— Вы понимаете, что значит — быстро вылезти из кабины на крыло? Это значит: делать медленные движения, без перерывов между ними…
Впоследствии я оценил всю универсальность этого рецепта, пригодного далеко не для одного лишь парашютизма. Мне кажется, трудно дать лучшую формулировку различия между быстротой и суетливостью.
М.Л. Галлай, "Испытано в небе"
TrydoKnight
07.04.2023 06:43+1Именно так работают в Японии. Одну работу могут делать вечно доводя до совершенства. Но многие думают, что они просто делают вид, что стараются)).
nio-kun
07.04.2023 06:43+3Работал в Японии программистом и могу подтвердить, что часто они именно делают вид. Имитация деятельности до тех пор, пока не уйдёт начальник, бесконечные совещания потому что никто не желает взять на себя ответственность за провал и многое другое - всё правда. Старательных - единицы, и да, именно на них всё и держится.
Krouler7
07.04.2023 06:43+3Количество деятельности, что в быстрой разработке и что в медленной, одинаково, кмк.
Просто в быстрой разработка идет в "ширину", когда как в медленной разработке в "глубину". Менеджменту также сложно объяснить резонность такого подхода, ибо им сложно без технической базы смотреть и сравнивать эффективность. Их особо не волнует как и что там работает и как нагружается система, лишь бы эффективно все продавалось.
Могу конечно ошибаться, но считаю, что медленный подход лучше для той части разработки, которая не попадается на глаза, например - серверная часть. Менеджменту там в принципе сложно что то показывать из бэкенда, для них это нечто неизмеримое. Тогда как тот же самый фронтенд проще дебажить и тестировать ввиду бОльшего количества отзывов, как минимум, потому что это "на виду".
18741878
07.04.2023 06:43+8"Быстро - это медленно. Но без перерывов" (японская пословица).
"Запомни: лучше день потерять, потом за пять минут долететь" (м/ф "Крылья, ноги и хвосты")
Dovgaluk
07.04.2023 06:43+2„Если бы у меня было восемь часов на то, чтобы срубить дерево, я потратил бы шесть часов на то, чтобы наточить топор.“ — Авраам Линкольн
JuryPol
07.04.2023 06:43+1Остановись, мгновенье… не остановится, слишком многие с этого кормятся. Между реальными разработчиками и реальным бизнесом давно уже сформировался мощный слой «специалистов» с невнятными обязанностями, громкими должностями и огромаднейшим самомнением.
Думаете, сгущаю? Набольший начальник городской услышал, что без цифровизации нынче никуда. На второй странице букваря для менедженеров, чуть ниже знаменитого «Требуй невозможного, получишь желаемое», есть еще одна «мысля»: «нельзя управлять тем, что не измерено». Вот и меряется уже третий год «уровень цифровизации муниципальных предприятий». Родили список из ста с лишним показателей. К каждому показателю долго обсуждали веса. Сурьезное ведь дело, с кондачка негоже решать. Курсируют во всех направлениях анкеты, заполняются показатели. Опять же, все знают, что показатели должны только расти год от года, это же первая заповедь. Потому, меняют методику, заполняют анкеты заново, добиваются того, что нужная цифирь начинает выглядеть прилично. А уж какой простор для «онолитиков», графики с точками, кружочками, треугольничками и квадратиками… Большая наука!!! Вот и год прошел… Подключились «быстрые» разработчики, дашборды, мобильное приложение. Все - как у взрослых, спринты, ревью, бэклог…
Это еще хорошо, что у нас так и не завелся департамент методологии с отделом методологии. Несколько месяцев назад тут статеечка была про то, как большой туз из этого методологического цирка спас проект, который без знания прежними руководителями методологии был обречен. Сначала были по головам пересчитаны все исполнители проекта, цифра была не ах, то есть без размаха, потому у руководства были вытребованы дополнительно десять голов разработчиков. Ну, понятно, чем ближе к сдаче, тем начальство податливее, посему были истребованы дополнительные нехилые деньги, грех не воспользоваться. Справились. Частично, остальное в рабочем порядке.
Что показательно, детки не очень большого начальства, если в АйТи взять, у нас пристроены все на позиции как раз не программистские. А что, анализ рынков, наблюдение за конкурентами, аналитические отчеты, раздача ценных указаний, почту разобрал - хорошо поработал.
Давно уже скачал «Тиранию показателей» Мюллера, втюкиваю ее всем, кому можно. Ничего не меняется…
MVS366
07.04.2023 06:43+1Стремление к совершенству
Это всё демагогия.
Стремление к совершенству, т.е. перфекционизм, является одним из психических расстройств. Вот первая случайная ссылка из поисковой выдачи:
Причиной обращения ко врачу-психиатру или психотерапевту является перфекционизм невротического типа. Чаще всего люди начинают обращать на него внимание тогда, когда накапливается усталость, возрастает недовольство собой и раздражительность, появляются признаки депрессивного расстройства.
Программный код нужен в первую очередь бизнесу, что бы получить максимальный доход и люди, стоящие во главе угла этого бизнеса, могли бы отдыхать с женщинами легкого и не очень поведения на забугорных морях и океанах, имели свой домик в Сочи и дорогую машину, кушали бы вкусные говяжьи шашлычки на своей даче.
Никого, кроме программистов не интересует красота кода. И не надо к этой красоте стремится. Код должен работать и выполнять свою функцию - приносить результат.
Все эти розовые айти-страдания по коду не нужны никому, кроме недавних джунов и ограниченного числа разработчиков, откровенно потерявшихся в жизни, кто воздвиг работу в рамки своей самоидентификации, смысла жизни. Опытные разрабы знают, что код в большинстве случаев везде плохой, что вся эта академическая теория про SOLID-ы и т.п. в подавляющем большинстве случаев не работает в реальных проектах, там работают костыли и заплатки. Код всегда переписывается по 150 раз и он не бывает статичным, он всегда модифицируется в зависимости от бизнес-требований.
Если вы хотите совершенства - нужно выбрать другую сферу, типа архитектуры или строительства, искусства или музыки.
vkomp
07.04.2023 06:43+4Есть возражения по терминологии. Перфекционизм имеет несколько значений. И в вашем применении скорее психология, психиатрия - это уже про неврозы и психозы со следствием в виде перфекционизма, но не причиной. А замечу, что перфекционизм также присутствует в философии, и там это не расстройство, а стремление улучшать там, где видишь потенциал и есть идеи. Позитивчик в общем.
Далее также выбираете очень узкое значение слов. Бизнес - это не только спекуляция. А большая часть общественной жизни с кучей всего и вся. Ну и код также - это не только текст, но и инженерная мысль. У нее есть жизненный цикл как у всего, но это не просто набор символов точно.
pilot114
07.04.2023 06:43+3А что такое реальный проект?
Очень наивно полагать, что всё IT - это галеры, стартапы и бешеная гонка только за быстрой прибылью.
Представьте, что нет nginx, postgres, linux, да и ЯП самих (их вообще пишут больные ублюдки оторванные от реальности). Много ваш бизнес денег заработает?MVS366
07.04.2023 06:43Очень наивно полагать, что всё IT - это галеры, стартапы и бешеная гонка только за быстрой прибылью.
В подавляющем числе случаев, конечная цель всего того, где есть IT - именно заработать деньги, что бы с женщинами на океаны, дачку, квартиру и хороший автомобиль.
А что такое реальный проект?
Я говорю про бизнес-проекты, про работу на бизнес, где ИТ как просто дополнительная или основная инфраструктура для зарабатывания денег.
Всякие пет-проекты психов-одиночек и сами ЯП, развиваемые сообществами, не в счёт, там, наверно, действительно важна красота кода, ибо это как некая форма общественного наследия.
lgorSL
07.04.2023 06:43+4А вот и нет. В других сферах народ тоже заморачивается с перфекционизмом и это нормально.
Например, в книжке "дао Тойота" рассказывается, как много внимания японцы уделяли процессу улучшения производства и как в итоге смогли дешёво и гибко производить очень надёжные автомобили.
Или, например, в мастерской можно красиво разложить инструменты по шкафчикам/полкам. И никто не говорит "да это розовые страдания, лучше в одну кучу всё свалить"
Можно при обслуживании автомобиля ставить оригинальные запчасти, а можно чинить как попало и чем дешевле с применением изоленты. В итоге лет через десять первый автомобиль будет как новенький, а второй превратится в разваливающееся ведро с болтами, которое проще выкинуть.
Можно сесть играть в факторио и построить лапшу из конвейеров. Добавление каждой новой лапшинки на первый взгляд проще, чем "красивая" организация, но через какое-то время макаронную фабрику станет проще снести и заново построить, чем расширять. Спидраннеры, как ни странно, почему-то строят довольно красивые фабрики.
Аналогично в дата-центрах почему-то всякие провода и т.п. стараются красиво проложить, а не как попало. Наверно, от безделья.И не надо к этой красоте стремится. Код должен работать и выполнять свою функцию - приносить результат.
Красота и перфекционизм - это способ упрощения и борьбы со сложностью. Чем сложнее система, тем больше внимания надо им уделять. Иначе станет только хуже.
9982th
07.04.2023 06:43через какое-то время макаронную фабрику станет проще снести и заново построить, чем расширять. Спидраннеры, как ни странно, почему-то строят довольно красивые фабрики.
На определенном этапе развития стартовый билд станет проще снести или бросить, чем использовать, независимо от того, насколько хорошо он спроектирован. Когда стартовая база произвела достаточно материалов для новой базы на более совершенных технологиях — абсолютно неважно, превратилась ли она в нерасширяемое спагетти полностью или только наполовину.
Нет никакой необходимости держать сложность максимально возможно низкой все время игры. Если вы в состоянии справляться с высоким уровнем сложности и балансировать ресурсы в уме — вы построите эффективное на данном этапе спагетти, если нет — придется уменьшать сложность и делать красиво, жертвуя скоростью. И уж спидраннеры умеют справляться со сложностью просто замечательно.
В типичном спидране после запуска ракеты база вполне вероятно будет просто нефункциональной, и ни о какой легкости расширения речь, разумеется, уже не идет.
104u
07.04.2023 06:43Спидраннеров не смотрел, но полностью согласен, что по итогу, скорее всего, придётся всё старье сносить, неважно, как красиво это могло быть в самом начале. Либо это всё займёт много места, что приведёт к необходимости защищать большие территории
Но при этом я все равно везде, где берусь, стараюсь сделать как можно идеальнее (бывало, разбирал почти собранные ТВ, если казалось, что забыл какой-нибудь винт или защёлку под рассеиватель поставить, снимал заново ШРУС, когда показалось, что не защелкнулся стопор и т.д.). С другой стороны, я также собирал всякие платы 3д монтажом (всякие самоделки), поскольку это всё равно только для проверки. По итогу я бы сказал, что it depends. В качестве временной меры сойдёт любая лапша и любая изолента, кто-то гонял с бутылкой бензина, когда крякнул бензонасос по дороге (карбюраторное авто), я лепил провода к фарам, когда одному человеку нужно было срочно уезжать, а была почти ночь
janvarev
07.04.2023 06:43+5Никого, кроме программистов не интересует красота кода.
Верно. Но программист-то вы! Если кого-то не интересует красота вашего кода - это его дело; возможно, для вас она составляет элемент самоуважения - т.е. скорее психического здоровья, а не расстройства.
Для программиста скорее путь "сделать все под бизнес, сию секунду" ведет к уменьшению самоуважения себя как профессионала и к расстройствам.
Gorthauer87
07.04.2023 06:43+2При хорошем умении говорить, очень даже легко можно продать бизнесу идею, что качество кода напрямую влияет на успехи бизнеса, как и качество архитектуры.
Все эти параметры влияют на прибыль бизнеса, а ещё они влияют на стабильность, ну грубо говоря, всегда есть вероятность, что команда разработчиков разбежится просто, если у нее будет низкая мораль, а их мораль активно падает, если разработчиков заставляют перерабатывать и вообще не дают времени исправить проблемы. А нижняя мораль повышает вероятность наступления полярного лиса, который просто обрушит весь бизнес нафиг, или принесёт большие убытки.
Myclass
07.04.2023 06:43+4Стремление к совершенству, т.е. перфекционизм, является одним из психических расстройств.
Если вам не нравится восхищаться тем, что выходит из под ваших рук - ваше дело. А мне доставляет удовольствие как результат, так и процесс. И не только в программировании, но и при приготовлении пищи, работы в огороде, создавании и распайки плат, постройки всяких строений как в доме, так и вне итд. Помню даже когда как 21-летрий переехал в Германию и первое, что делал - мыл машины в автосалоне, то мыл их припевая песнями. У психиатров вроде не числюсь на учёте :)
Можно работать ради денег, а можно получать удовольствие и при том за это получать деньги.
MVS366
07.04.2023 06:43Если вам не нравится восхищаться тем, что выходит из под ваших рук - ваше дело.
Мене тоже это нравилось (писать вылизанный идеальный код), когда мне был 20-25 лет.
Сейчас, в 40 лет, мне это не нужно и не интересно, особенно в рабочих проектах, которые в режиме нон-стоп переписываются. А на последнем месте работы вообще идёт речь о сокращении и о том, что проект, на который было потрачено 3 года работы команды, просто отправится в мусорную корзину.
skhida
07.04.2023 06:43+1Если вы хотите совершенства - нужно выбрать другую сферу, типа архитектуры или строительства, искусства или музыки.
Боюсь, что от сферы это не зависит. В архитектуре и строительстве абсолютно то же самое - заплатка на заплатке и костылем погоняет. А в последнее время еще контроль со стороны госорганов постоянно под мораторием.
С искусством и музыкой изнутри не сталкивался, но не думаю, что там какие-то другие цели у бизнеса.
KongEnGe
07.04.2023 06:43+4"Эффективный манагемент" нонче предпочитает загнать техдолг к потолку, а затем перейти к новым инвесторам, к сожалению.
pyrk2142
07.04.2023 06:43+4Люди хотят, чтобы их наконец оставили в покое и дали пожить в своё удовольствие.
Статья в целом интересная, но вот это предложение очень сильно смутило. А кто должен оставить людей в покое? Кто заставляет бегать между кучей городов, делать гору фотографий, есть фастфуд на бегу, пролистывать клипы или быстро что-то рисовать? Очень часто оказывается, что этих злодеев в реальности не существует, а человек почему-то думает, что так нужно делать, или кто-то его заставляет.
Даже в том же злом коммерческом ИТ я редко видел, чтобы кого-то реально заставляли работать очень быстро или перерабатывать. Часто ситуации выглядели так:
- Сколько времени нужно на то, чтобы сделать Х?
- Две недели, ну или неделя, но тогда все плохо будет сделано
- А что значит плохо? К чем это приведёт в будущем?
- Ну, это, техдолг, сложно писать будет дальше, ээмммаээээмммм, плохо будет, короче говоря
- А конкретно что будет плохо, давайте обсудим и поймем
- Аааа, ээээ, пофиг, через неделю будет готово
А через полчаса этот разработчик жалуется коллеге, что его заставляют говнокодить.
Очень часто оказывается, что нет никакого влияния злых людей или общества, а есть странные установки, возникшие по какой-то причине. И в этом есть определённая проблема «медленной» деятельности: человек может начать стремиться к получению удовольствия и счастливой жизни не через понимание проблем и их причин, а через противостояние каким-то, часто несуществующим, внешним воздействиям. И это может привести к гораздо большим проблемам в будущем.
TooBigBigs
07.04.2023 06:43+6Какой прекрасный материал! Вот именно поэтому я и ушёл из классического коммерческого IT, оставив себе один любимый проект, который делаю так, столько и тогда, как сколько и когда я хочу. И вот тут вернулся кайф.
А когда вернулся кайф, все вокруг почему-то начали меня слушать. Видимо потому, что чувствуют этот кайфовый вайп, и хотят также. Так меня нашли три новых проекта, в которых я не делаю почти ничего, кроме размышления о том, как правильно их сделать. И самое удивительное, как оказалось, люди ценят этот навык и готовы брать в бизнес просто за это.
MiraclePtr
07.04.2023 06:43+2Так меня нашли три новых проекта, в которых я не делаю почти ничего, кроме размышления о том, как правильно их сделать. И самое удивительное, как оказалось, люди ценят этот навык и готовы брать в бизнес просто за это.
Так ведь это же именно и задача тех-лида/архитектора - размышлять о том, как и что надо правильно делать. И говорить другим, пусть делают.
stackjava
07.04.2023 06:43+1В мире "эффективок", всех тянут в эффективность... От этого слова уже тошнит, когда менеджеры или инфоцыгане начинают произносить.
Но молодежь рада быть эффективной и быстрее влиться в работу, что идет в разрез с теми, кому за 30 (((
Но приходится держать планку... Иначе окажешься на обочине "эффективной" магистрали (((
0xC0CAC01A
07.04.2023 06:43+2Не окажешься. Это эффективные менеджеры изо всех сил стараются напугать обочиной. А умение аргументировано говорить нет - это даже более важный навык, чем писание кода.
vvbob
07.04.2023 06:43+3игра не стоит свеч — идеальный сферический продукт в вакууме, на разработку которого потрачен год, устаревает через месяц после выпуска;
Это какое-то когнитивное искажение, есть, конечно, категория мусорного софта - всякие там программы однодневки с кликбейтными названиями, чье главное предназначение это привлечь внимание пользователя, быть установленными на компьютер (телефон), показать ему пару-тройку проплаченных рекламок и быть навсегда удаленными. Но далеко не все программы сейчас такие, к счастью.
johnfound
07.04.2023 06:43+6Горячо одобряю и рекомендую!
Я именно поэтому и пишу все на ассемблере. Пока получается прекрасно!
sovaz1997
07.04.2023 06:43Зачастую, чтобы написать быстро, нужно писать медленно. Быстрое клёпанье может замедлить разработку в целом на дистанции.
far-rainbow
07.04.2023 06:43+2Законы природы не обмануть. Для ремесленного формошлёпства вполне годятся потогонные схемы, особенно, если гребцы молодые и мускулистые. Их можно бить кнутом, выдавать повышенное содержание и литры кофейной жижи. Для всего чуть более серьёзного нужны вдохновения (хотя бы у одного элемента из всей системы в один момент времени), озарения, превентивные меры защиты от выгорания (которое является вполне себе перегрузкой с выходом в органическую депрессию). Поэтому автора поддерживаю -- медленному программированию было место 30 лет назад, будет место и через 30 лет (но это уже будет другое программирование других систем, скорее всего биологических, скорее всего будут заново переосмыслены воспитательные методики)
MinimumLaw
На поверку оказывается, что "медленное" программирование не "медленее" быстрого, а вот затрат на него надо в разы меньше. Что технических, что эмоциональных.
Впрочем, пусть расцветают сто цветов, пусть соперничают сто школ (с). В идеальном мире должны быть и спринтеры и марафонцы. В конце концов людям с разным темпераментом и в разное время оказывается комфортнее в разных концепциях.