Комментарии 69
Пример. На сайте школы Хекслет есть рейтинг учеников. Он считался динамически, поэтому через определенное время все начинало тормозить на 20 странице. Мы пришли с проблемой к разработчикам. Что сделает в этом случае неопытный программист? Вероятно, предложит добавить кеширование или периодический расчет рейтинга. Что сделали наши программисты? Предложили обрезать рейтинг до сотого номера, справедливо предположив, что никто не будет листать до 20-й страницы в принципе. Теперь у нас сайте есть рейтинг топ-100. Проблема была решена через продуктовое решение и удаление кода
Так себе пример. "справедливо предположив" - а у пользователей кто то спрашивал? Может кто то там себя ищет в списке. Так можно и дальше пойти, "Я вот никогда эту кнопку не нажимаю, давайте её удалим, слишком сложно всё там".
поэтому через определенное время все начинало тормозить на 20 странице
никто не будет листать до 20-й страницы в принципе
Подозрительно)
Кмк можно оставить топ 100 и отображать рейтинг в личном кабинете. И не надо будет выгружать постоянно 20 страниц и каждый ученик будет знать свой рейтинг.
не "может кто-то ищет", а точно кто-то ищет. Если я в рейтинге 1000+, то соревнуюсь с теми кто рядом со-мной выше и ниже, а не с теми, кто в топ100. Верните рейтинг как было!
Так себе пример. «справедливо предположив» — а у пользователей кто то спрашивал
… и как вишенка на торте — «мы не будем заниматься исправлением откровенной лажи, кода, который не мог переварить несчастную тысячу записей, давайте просто сделаем, чтобы современные компьютеры выводили не более сотни». Быстро — да. Но профессионально ли? Нет, ни капли. Непрофессионально поступили ещё на этапе разработки архитектуры этого решения, непрофессионально слепили и костыль.
Подозреваю, что дело было так.
Автор статьи главному программисту: - Я слышал что-то про то, что лучший код - это не написанный код. Это правда?
Главный программист: - Ага, я тоже такое слышал.
Автор: - А можешь пример привести, как вы похожим образом проблему решили, а то в сети не нашёл что-то, да и хочется своё.
Главный программист: - Ну-у-у-у-у-у... вон у нас недавно рейтинг тормозить начинал, где-то с 20-й страницы, а мы взяли и убрали расчёт дальше этой страницы. Тормоза пропали вместе со страницами.
Автор: - Вау! Так и напишем.
Ну, пример, возможно, и не самый удачный, но концепция-то понятна)
Как-то раз делал медицинскую прилагу, одна из фич - при открытии календаря видно, в какой день какую таблетку надо не забыть выпить. Условия для создания расписания очень гибкие - можно создать не только классические "принимать таблетки в 10 утра", но и бесконечное цикличное правило вроде "принимать каждые 6 часов в течении каждой третьей недели месяца на протяжении полугода, потом месяц перерыв, и по новой".
Так вот, пользователь вполне мог открыть календерь хоть следующего столетия, и нужно было подсветить ему, в какие дни есть приём лекарств. Реализовывать подобные рассчёты налету очень геморно, но, будем честны - как часто нам нужно узнать, во сколько потребуется приём таблетки 10 июля 2073 года?
Лучшим решением было пойти к бизнесу и сказать - ребят, на календаре будем показывать расписание только на ближайший год. Потому что мы можем нагенерить событий на год вперёд и отдавать их без рассчётов.
P.S. ох, а сколько там было сложностей с кейсами о поддержании расписания, когда юзер меняет часовые пояса... Вспомнить страшно)
Реализовывать подобные рассчёты налету очень геморно
А чего прямо геморного? Нагенерить событий на интервал в год или на неделю - код один и тот же.
Потому что мы можем нагенерить событий на год вперёд и отдавать их без рассчётов.
Ну да, но еще не забывать их подчищать при каких-то изменениях, плюс догенерить, когда год прошел. Дополнительный геморрой, вообще-то.
"Нагенерить событий на интервал в год или на неделю" - конечно. А вот "неделя" и "столетие" - уже ощутимие) По 100 000 записей на человека хранить и переделывать при изменении - явно не круто
Тут, имхо, две разные параллельно работающие задачи.
Одна, это показ нагенеренных событий из буфера. Вторая, это генерация в буфер актуальных данных. Соответственно, при глобальных изменениях, или просмотрах на 300 лет вперед ждемс пока сгенерится искомое. Зато при остальных 99% обращений все делается мгновенно.
По большей части сам генератор может работать (обновлять данные) когда ему удобнее и когда меньше затрат.
Ну и программить и отлаживать две независимые сущности всяко проще, чем одну гибридную.
Если курс не хаотичен, то существует правило цикличного исполнения и дата точки отсчёта, то этих данных будет достаточно, чтобы сгенерировать на клиенте результат на любую дату. Возможно, я ошибаюсь и медики способны без Пенроуза создавать бесконечно асиметричные курсы.
Большое человеческое "спасибо" за кастрацию функционала, чо.
В вашу целевую аудиторию не входят люди, сидящие на таблетках пожизненно/долгосрочно?
Мне ещё повезло, раз в три месяца месячный курс нольпазы пропил - и порядок, если пропустил недельку (лажанул с закупом) - можно подождать завоза.
А более "хроническим" хроникам что делать, которым условия позволяют закупаться больше, чем на год?
Эвенты стабльно будут приходить и отрисовываться хоть всю жизнь, они догенерируются по мере движения времени. Единственное, что убрано - возможность заглянуть дальше, чем на год вперёд. Да, рассчитать закупки на десятилетие вперёд не получится, но это и не функционал для закупок - это календарь с напоминалками, у него другая задача.
"справедливо предположив" - а у пользователей кто то спрашивал?
Тут два момента. Для опроса пользователей сначала нужно выдвинуть гипотезу, а предположение это как раз оно и есть. Второе, далеко не все надо спрашивать пользователей, есть аналитика, есть эксперименты, есть метрики. Так вот в результате оказалось что у этой фичи нулевое влияние на бизнес, поэтому мы выбрали то решение, которое упрощает систему, а не усложняет.
у этой фичи нулевое влияние на бизнес
Но, ведь "Настоящий заказчик разработки — пользователь продукта, именно о его удобстве должен думать в первую очередь программист, приступая к задаче. Поэтому, в идеальной ситуации, разработчик либо общается с пользователем, либо, с теми, кто общается с пользователями". Тут что то про бизнес ничего нет
Угу, а кто остался таким же как был 10 лет назад? Хекслет запустился в 2012 году и мы с тех пор все немного стали мудрее
Еще добавлю. Нулевое влияние на бизнес это буквально "если мы уберем эту фичу, не станем зарабатывать меньше". Но не все фичи должны приносить деньги напрямую, всегда есть другие элементы, даже банальный фан, когда например гугл на какой-нибудь праздник красит логотип.
Так вот в результате оказалось что у этой фичи нулевое влияние на бизнес
Хм...
Кстати, как бы удивительно это ни звучало, благодаря такому решению у студентов появилось больше стимула к успешной учебе: им интересно попасть в список лучших.
То есть, стимулы к учебе никак не влияют на бизнес? Интересно.
На получение профессии влияют совсем другие факторы. Достаточно посмотреть на компании которые торгуют курсами. Понятие рейтинга там есть буквально в одном двух проектах
Ещё веселее.
То есть, сначала фича с нулевым влиянием на бизнес попала в релиз.
Угу, 9 лет назад, когда мы про бизнес не знали ничего
Ваш комментарий порождает очень много интересных вопросов.
Один из самых примечательных: почему тогда этот старый недосмотр выставляется в статье как подвиг и пример для подражания?
То что сделали какую-то фичу и она не сильно повлияла на бизнес показатели, это не недосмотр, а постоянная история во всех проектах. Продуктовая разработка это череда неуспехов к редким победам. Рейтинг и сейчас на сайте есть, только в виде топ-100. В итоге мы довольно быстро, буквально за одну итерацию сделали хорошее решение. А изначальный рейтинг вообще за пару часов запилили.
пример для подражания?
Потому что это прекрасный пример того, как программисты задают вопросы и включают критическое мышление. Вместо того чтобы решать следствие, они копнули в причину.
С последним абзацев я конечно соглашусь, но...
Всегда есть "но". Свой текущий рейтинг пользователь в общем фоне видит? А тех кто выше и/или ниже него?
Пример: Вот я сейчас 1002, но мне не хватает 1 балла до выше стоящего и двух, чтобы перейти в первую 1000!
Вот это - действительно стимулирующий вариант.
Да это интересная история для экспериментов, но "но" тут в другом. В проекте так много вещей которые по настоящему большие, что вот до такой штуки просто не доходят никогда руки. Задач всегда больше чем людей. Именно поэтому нам проще урезать, чем тратить время на нее.
Фокус в том, что концентрируясь на больших вещах и игнорируя мелочи, как раз и ухудшается восприятие целого проекта.
Обычного пользователя не интересует то, из каких глобальных частей он построен и как круто они там работают, его больше интересуют мелочи которые он видит или не видит. Из десятка другого мелочей и создаётся для "обывателя" общая картина проекта.
С другой стороны, согласен что довольно часто случаются ситуации когда приходится урезать, а то и избавляться от какого-то функционала в угоду разработки. Но данный пример у меня вызвал сразу же один вопрос - что за криворукий создал изначальный рейтинг, если он не может сделать постраничную выборку данных из базы на основании индекса построенного на баллах рейтинга?
Добро пожаловать в мир реальной разработки. В котором, в отличие от фантазий диванных архитекторов, не возникают из пены морской законченные идеальные шедевры. А всё происходит именно так — сначала кто-то криворукий делает не слишком удачно, потом, по результатам эксплуатации, функционал переосмысливается.
Я смотрю в этом топике прям собрались специалисты по созданию любого функционала, которые всегда заранее знают, как правильно.
Вот только практика, опять же, говорит нам о том что при создании MVP есть только два пути — сделать быстро, но рабочее, или делать идеально, но никогда не взлететь.
То что сделали какую-то фичу и она не сильно повлияла на бизнес показатели, это не недосмотр, а постоянная история во всех проектах.
И мы вернулись на исходную.
Нужно ли учить подрастающее поколение программистов тому, что такая дикая ситуация - это норма?
А изначальный рейтинг вообще за пару часов запилили.
Ну. Клёво. Но этому ли нужно учить подрастающее поколение программистов?
Потому что это прекрасный пример того, как программисты задают вопросы и включают критическое мышление. Вместо того чтобы решать следствие, они копнули в причину.
А может, это не задача программистов, всё-таки? Ведь код пишется для пользователя, а не для того, чтобы удобно этот код писать было.
Пример. На сайте школы Хекслет есть рейтинг учеников. Он считался динамически, поэтому через определенное время все начинало тормозить на 20 странице. Мы пришли с проблемой к разработчикам. Что сделает в этом случае неопытный программист? Вероятно, предложит добавить кеширование или периодический расчет рейтинга. Что сделали наши программисты? Предложили обрезать рейтинг до сотого номера, справедливо предположив, что никто не будет листать до 20-й страницы в принципе.
То есть программисты изменили исходное ТЗ. Насколько корректно оно было сформировано изначально? Был ли ответственный за сайт в курсе, и было ли ему "не пофиг"? А то вот я, например, прекрасно листаю некоторые рейтинги на более чем 100 позиций, и я бы сделал как кэширование, так и периодический перерасчет. Плохой пример, хуже было бы если в примере был бы случай, когда подобный рейтинг или ещё какую-то свистелку просто оторвали за нерентабельностью, или по хотению левой пятки какого-то "программиста". Иной раз не самые простые вещи от отрыва фишек могут сломаться, например, некий довольно критичный для хотя бы юзабилити код третьей стороны.
PS: я постараюсь в следующий раз обновлять вначале комментарии.
Ну судя по статье, Вы и есть тот самый "неопытный программист" :)
Ну, я всегда исхожу из того, что если в ТЗ нечто есть, запилено оно должно быть так как задано, и если ТЗ стоит как "оптимизировать работу рейтинга по скорости" — кэширование+пересчет по времени будет близко к оптимальному решению. А тут задали ТЗ в форме "рейтинг тормозит", интерпретировали как "а давайте рассчитывать меньше?" и обрезали функционал в результате.
Я согласен полностью, в статье даже пункт отдельный есть про то, что нужно учитывать удобство пользователя и прорабатывать решение) да и последний пункт имеет место быть (про выпил кода), разве что пример неудачный
Ну так это нормально. Если функционалом никто (или почти никто) не пользовался, то зачем его поддерживать? Плюс ещё вместо многостраничного непонятно чего получили список лидеров. Win-win.
Вопрос «а оно точно надо?» один из самых важных, пожалуй. Продакт оунер вовсе не бог, ему нужно вопросы задавать, чтобы не делать дурную работу.
Дело в том, что в примере обсуждаемый рейтинг уже был, значит, "по умолчанию" после оптимизации должен был не потерять функционала. Если его сократили до топ-100, значит, был запрос на изменение и он прошел того же продакт оунера. Само по себе изменение функционала как задача не хуже и не лучше других, и решить проблему производительности, урезав выдаваемую часть, тоже проходит со своими плюсами и минусами. Вот только разница между "никто" и "почти никто" едва ли не такая же, как между "нигде" и "почти нигде", каковую я бы поостерегся нивелировать подобным образом.
точно, тот самый "неопытный" ))
На этом месте мой личный парсер уже выбрасывает ошибку изменения значения константы.
Вы так серьёзно набросились на эту, немного высосанную из пальца, иллюстрацию одного из тезисов, как будто вся статья посвящена одной только теме, "если функционал плохо работает, то его надо выпилить". Поверьте, никто таких утверждений не делал.
Реальность: работаешь с людьми.
Насчет рейтинга возникает вопрос - а почему он не кэшировался, ведь изначально должно было быть очевидно, что расчет ресурсоемкий? А если "Оверинжиниринг, нинада нам этого", то почему сразу десяткой-сотней не ограничили в таком случае?
Мне аж интересно стало, как это у вас рассчитывается рейтинг: в вашем случае, судя по рассказу, вычисление следующей позиции рейтинга каким-то образом зависит от вычисления предыдущей, ведь, если бы рейтинг вычислялся линейно, то тормозило бы и на первой странице тоже.
Не поделитесь алгоритмом хотя бы в общих чертах?
Я почти не работал с рейтингами, так что единственное, что приходит в голову, так это какой-нибудь элоподобный алгоритм, но вы не храните очки, а вычисляете их из истории матчей. Но даже этот вариант не подходит: в таком случае все равно сначала нужно будет просчитать все позиции, чтобы узнать топ-100.
а почему он не кэшировался, ведь изначально должно было быть очевидно, что расчет ресурсоемкий?
Очевидно, но и в той ситуации было очевидно, что есть множество других по настоящему важных вещей, когда делался рейтинг, мы были стартапом с 4 людьми без достаточной прибыли чтобы выживать, рейтинг был проектом выходного дня можно сказать. Никто даже не знал, будет он существовать или нет. А вопрос возник спустя годы после того как его запустили.
По реализации все просто. В базе есть табличка активностей за которые начисляются баллы, соответственно мы просто делали группировку и суммирование баллов.
стартапом с 4 людьми без достаточной прибыли
Понятно.
В базе есть табличка активностей за которые начисляются баллы
Непонятно.
Возможно что-то неверно описано в тексте статьи и тормозит, скажем, клиент при рендере, а не сам алгоритм? Если это просто группировка и суммирование, то разница в выдаче скриптом топ-100 и топ-1000 даже без пагинации должна быть минимальна, т.к. в обоих случаях алгоритм сначала должен вычислить баллы для всех пользователей (по моему разумению).
Там было 200 000 пользователей ;)
Сто пользователей или двести тысяч, тысяча активностей или миллион, топ-100 или топ-10000: тормозить должно либо И на первой странице И на двадцатой, либо ни на первой ни на двадцатой в вашем случае, т.к. для вычисления рейтинга вы все равно суммируете всю таблицу с действиями (если у вас нет хитрого способа вычислить, каких пользователей можно игнорировать при расчете топ-Х).
Он считался динамически, поэтому через определенное время все начинало тормозить на 20 странице
Я полагаю, что для 20й страницы вы передаете/показываете/обрабатываете данные по всем 20*х пользователям, а для первой только по 1*x пользователям.
Т.е. виноват не алгоритм расчета и не то, что он динамический, а способ передачи или показа/обработки данных на стороне клиента. Либо какие-то траблы с железом/СУБД.
Зачем считать рейтинг динамически в момент запроса? Если я правильно понимаю, что такое рейтинг - он обновляется либо в конце периода времени (дня, недели, семестра), либо по моменту сдачи очередной работы. И не нужны хитрые способы кеширования.
Зачем считать рейтинг динамически в момент запроса?
Вы, вероятно ошиблись комментарием: я примерно это и спрашивал.
Ответ: у них не было времени/ресурсов заморачиваться созданием отдельной таблички.
(дня, недели, семестра)
Чисто теоретически у вас могут быть следующие условия:
изменения в БД ресурсоемки, а чтение нет
изменения в рейтинге происходят в разы чаще, чем запросы рейтинга
при каждом запросе рейтинга необходимо отдавать актуальную информацию
В этом случае пересчитывать рейтинг периодически не получится, а при каждом изменении сохранять в таблицу будет дорого, так что без кэша не обойдешься.
Пример. На сайте школы Хекслет есть рейтинг учеников. Он считался динамически, поэтому через определенное время все начинало тормозить на 20 странице. Мы пришли с проблемой к разработчикам. Что сделает в этом случае неопытный программист? Вероятно, предложит добавить кеширование или периодический расчет рейтинга. Что сделали наши программисты? Предложили обрезать рейтинг до сотого номера, справедливо предположив, что никто не будет листать до 20-й страницы в принципе. Теперь у нас сайте есть рейтинг топ-100. Проблема была решена через продуктовое решение и удаление кода.
Что бы сделал я - сказал бы, что сравнивать себя с другими людьми - греховно, и выпилил бы весь функционал рейтинга. :D
Не существует человека, который точно знает, как нужно делать. Любая заранее продуманная логика разбивается о реальность. Именно поэтому в разработке так популярны гибкие методологии, когда продукт делается не по ТЗ от начала до конца.
И именно поэтому что витрины игровых магазинов, что подборки профильного софта, что сами перечни средств разработки забиты до отказа крайне удивительными метисами и креолами, которые вроде бы выполняют свою задачу - но как-то не так...
А если это ещё помножить на тенденцию к feature bloat, ммммм...
В любом случае у разработчика должно быть четкое понимание, как клиент взаимодействует с продуктом.
Вообще-то, у группы заказчиков, проектировавших функционал. Даже если это "Блокнот". Даже если это форк "Блокнота".
А то будет как с Notepadqq vs Notepad++ - редкий пример, когда версия софта под Windows на голову превосходит по удобству версию для Linux. Хотя, казалось бы, одно - клон другого.
Распространенная проблема в разработке — «овер-инжиниринг», когда создаются решения, которые учитывают все возможные сценарии, даже те, которые еще не используются.
...и когда продукт перерастает фазу "теперь это не MVP" и начинает обрастать фичами - это многократно кусает весь связанный с разработкой коллектив за зады при каждой попытке обогатить приложение чем-то полезным...
На сайте школы Хекслет есть рейтинг учеников. Он считался динамически, поэтому через определенное время все начинало тормозить на 20 странице. Мы пришли с проблемой к разработчикам. Что сделает в этом случае неопытный программист? Вероятно, предложит добавить кеширование или периодический расчет рейтинга. Что сделали наши программисты? Предложили обрезать рейтинг до сотого номера, справедливо предположив, что никто не будет листать до 20-й страницы в принципе. Теперь у нас сайте есть рейтинг топ-100. Проблема была решена через продуктовое решение и удаление кода.
Проблема была решена через обрезание релизного (!!!) функционала.
Такой метод решения проблем очень плохо вяжется с указанным ранее тезисом:
Настоящий заказчик разработки — пользователь продукта, именно о его удобстве должен думать в первую очередь программист, приступая к задаче.
Я понимаю, что я нифига не CEO и от моего мнения на самом деле мало что зависит, но я бы очень поостерёгся повышать свои навыки у вас после прочтения этой статьи. В этих "подходах" слишком много hot takes, которые могут вылиться в конечном итоге в обострение уже имеющихся проблем индустрии. Которой и так... не очень хорошо.
В целом неплохо, но почему-то все поголовно основатели онлайн курсов по программированию не в курсе про отладку. И потом такому свеженькому выпускнику с отличием начинаешь объяснять элементарные вещи:
- Что программист действительно не всё время занимается программированием. Но при этом болтовня с заказчиком не является единственной альтернативой, а у джуна так и вовсе отсутствует. А вот отладкой-то как раз приходится заниматься в полный рост. Потому что, как сказал Фредерик Брукс, "сидеть выдумывать гениальные идеи — это так, расслабуха. А вот когда надо найти одну мелкую гаденькую ошибку — вот тут начинается настоящая работа".
- Что для отлаживания кода на него не надо смотреть. И просить кого-то другого посмотреть тоже не надо. А что код надо запускать. И пошагово трассировать, проверяя корректность работы на каждом этапе
- Что после того как написал код, всё только начинается. И кроме создания программных шедевров программисту ещё надо заниматься их поддержкой. Которая в том числе включает и исправление багов
Все эти советы для джунов подходят. Они зеленые и не понимают как void main() { ... } в итоге превращается в огромный колл-центр с 150ю операторами, у половины из которых вылазят рандомные баги.
Опытному серверному сеньору с 10+ лет опыта предлагать улучшения и тем более с клиентами общаться? Не надо это ему. Он работает уже в таких командах, в которых есть ПМ, РП, аналитики, которые сами знают что и кому нужно.
Конечно, если просят сделать откровенную дичь, заведомо плохо/сложно реализуемую в техническом плане - я буду протестовать. Но не из-за того, что сильно переживаю за конечных пользователей, а скорее из-за того, что уверен, что потом меня этой дичью по ночам будут доставать: то медленно, то падает, то давай-ка переделаем вот так и так и тп.
Программист должен программировать
А вот что по поводу программистов думал один из пионеров теоретического и системного программирования академик Андрей Петровичу Ершову (статья «О человеческом и эстетическом факторах в программировании», 1972):
Программист должен обладать способностью первоклассного математика к абстракции и логическому мышлению в сочетании с эдисоновским талантом сооружать все, что угодно, из нуля и единиц. Он должен сочетать аккуратность бухгалтера с проницательностью разведчика, фантазию автора детективных романов с трезвой практичностью экономиста.
Заказчик тот, кто платит - и никаких гвоздей. И только ему надо объяснять за что он платит.
Ну для stackoerflow не то что 100 мало, даже 1000.
Все продуманно заранее .
Именно так и должно быть. Что нужно заказчику - знает только заказчик, а если не знает - то есть аналитики и руководители проектов, у которых есть соответствующие хард и софт скилы и опыт реализации подобных проектов, со знанием всех нюансов, которые могут вылезти. Разработчик отвечает за техническую реализацию, а не за то, какие бизнес фитчи будут (хотя и может участвовать в процессе их обсуждения указывая на их трудоёмкость). То, что некоторые экономят на команде и видят в программисте человека-оркестр - это проблема отрасли, а не нормальная практика.
Задачи, которые ставят программистам, обычно описываются с точки зрения поведения обычных пользователей: «Добавить подтверждение входа по смс»
Нет, в таком виде оно приходит как одна из хотелок, которую вместе с заказчиком прорабатывает аналитик. К разработчику должны попадать, как минимум, User Story ну или хотя бы внятное описание (см. далее)
Можно ли его отключить? А если это абонент другой страны? А если человек потерял телефон? А через какой сервис отправить смс?
Задавать такие вопросы - задача аналитика, а не разработчика. От разработчика скорее вопросы вида "как часто нужно отправлять смс" (хотя такие вопросы опытный аналитик и сам задаст)
Это его прямая обязанность — указать на моменты, про которые забыл
Вообще то это задача аналитика. Разработчик такое если делает, то только с точки зрения технической реализации
Все это требует переговоров, копания в документации, взаимодействия с людьми из внешних продуктов и других частей системы. Чем опытнее разработчик, тем чаще он этим зазанимается.
Этим занимается бизнес-аналитик или РП. Время разработчика слишком дорого стоит, чтобы тратить его на пустой треп.
Написание 20 строчек кода может сопровождаться днями обсуждений.
Только если плохо выстроены процессы в компании. Для всех остальных есть аджаил и A/B тестирование. А если даже какие то длительные обсуждения ведутся, то разработчики в них не участвуют - иначе некому будет фичи пилить.
должно быть четкое понимание, как клиент взаимодействует с продуктом
Для этого должна быть документация и чёткие постановки (вклбчая UML диаграммы). Чаще всего программист ни фига не понимает в той сфере, для которой предназначен продукт
Именно поэтому во многих компаниях использование сотрудниками продуктов бренда — обязательное условие при приеме на работу.
Вот прям сразу представил программиста, который является опытным пользователем систем управления бизнесом, инженерного проектирования, архитектурной визуализации и систем поддержки принятия решений уровня государства ))
В действительности же начинать следует с самого простого, «деревянного» ответа на проблему пользователя — с решения, которое можно осуществить в короткий срок. При этом неважно, насколько это решение хорошее или плохое
Для этого есть программы, типа фигмы, а так же low и no code. В остальных случаях плохое решение или нет - важно, если в руководстве конечно не сидят самодуры ибо переделывать плохое решение всегда дороже, чем сразу написать правильно.
На выходе мы получаем не одно решение, а несколько
Мы получаем одно решение ибо время=деньги. Некоторые олько решений можно делать только когда заняться больше нечем и деньги потратить некуда
За годы работы продукта накапливается огромное количество архитектурных решений, от которых невозможно отойти ни вправо, ни влево. И чем больше кода пишется, тем шире эта ловушка.
Только если писать код как левая нога решит. В остальных случаях у продукта есть архитектура и тот, кто за неё отвечает
Например, иногда решить задачу можно удалив код
Удалять код можно только когда того требует бизнес задача. Разработчик лишь может донести до бизнеса (в этой роли могут и аналитики выступать в данном случае), что дешевле фичу выпилить нафиг, чем её переделывать.
разработчики время от времени переходят в отдел поддержки
Я такого бреда в жизни не видывал. Серьезно, за свою достаточно долгую карьеру работы программистом (более 17 лет) - нигде, ни разу такого не видел и ни от кого не слышал. Хотя, надо признать, в целом, идея, конечно, не лишена смысла, но, как говорится, в реальном мире не выдерживает критики.
Описанное в статье - больше подходит к описанию мелкой канторы, в которой пишут небольшие сайты full-stack программисты уровня junior-middle.
Опытные разработчики делают ошибок немногим меньше, чем начинающие, но они быстрее их исправляют. В этом им помогают насмотренность и автоматизированные тесты, которые постоянно проверяют код.
Даже близко не так. Опытные разработчики могут писать целые программы/микросервисы почти без ошибок, в то время как начинающие делают миллион ошибок, а потом еще после код-ревью миллион исправлений (читай ошибок).
В действительности же начинать следует с самого простого, «деревянного» ответа на проблему пользователя — с решения, которое можно осуществить в короткий срок. При этом неважно, насколько это решение хорошее или плохое. Дальше анализируются преимущества и недостатки выбранного подхода, к решению добавляется что-то, усложняющее его и одновременно делающее лучше. И так шаг за шагом.
Такой подход годится, когда ваша небольшая noname-кантора делает первые шаги в мире разработки ПО, или чтоб по быстрее получить деньги и забыть о продукте, но такого подхода вам не простит ни одна серьезная организация. При проектировании нового продукта в нормальных организациях учитываются многие факторы, которые определяют спектр технологий, который может быть использован, и чаще всего выбор идет между одинаковыми по методу работы, конкурирующими технологиями.
О чем вы даже не подозреваете, решая стать программистом