Меня зовут Кирилл Мокевнин, я CEO и сооснователь онлайн-школы программирования Хекслет. Мы помогаем людям с самым разным бэкграундом стать разработчиками уже 10 лет. За это время я не раз замечал, что зачастую студенты плохо представляют себе профессию. Вещи, не относящиеся напрямую к технической составляющей программирования, но имеющие огромное значение для успеха в будущей специальности, становятся для них сюрпризами еще во время обучения.
В этой статье я поделюсь открытиями, которые ожидают студентов и начинающих программистов, решивших посвятить себя разработке.
Все продумано заранее
Студенты представляют себе разработку так: существует заказчик, который приходит к программисту и дает техническое задание, где описано все, что нужно сделать, и как нужно сделать. От программиста требуется только написать код. В действительности же, техническое задание даже если и есть, то далеко не полное. И это нормально: никто не может заранее сказать, окажется ли новая возможность удобной, пока пользователи не начнут жаловаться: «Дуров верни стену!».
Не существует человека, который точно знает, как нужно делать. Любая заранее продуманная логика разбивается о реальность. Именно поэтому в разработке так популярны гибкие методологии, когда продукт делается не по ТЗ от начала до конца. С их помощью продукт разрабатывается небольшими порциями, которые постоянно отдают пользователям, чтобы убедиться в верности принятых решениях и направлении развития. Программный продукт — живой организм, который постоянно развивается на основе экспериментов и обратной связи. Все продукты, которые вы знаете, разрабатываются непрерывно.
Иногда программирование сравнивают со строительством, но это сравнение не очень корректно. В случае со стройкой все планируется заранее, а разработчик всегда находится в состоянии неопределенности — он не знает, куда точно будет развиваться проект.
Программисты постоянно пишут код
Задачи, которые ставят программистам, обычно описываются с точки зрения поведения обычных пользователей: «Добавить подтверждение входа по смс». В целом — все понятно, но возникает множество вопросов по условиям работы и технической реализации. В каких ситуациях нужно подтверждение? Можно ли его отключить? А если это абонент другой страны? А если человек потерял телефон? А через какой сервис отправить смс?
Часть этих вопросов будет раскрыта в техническом задании, но далеко не все. И это делается не специально. Только программист понимает всю сложность, которая скрыта за такими задачами. Это его прямая обязанность — указать на моменты, про которые забыли или которые будут сложны в реализации. В результате задача может значительно измениться в сторону упрощения, так как исходный вариант займет значительное время на разработку, которое стоит дорого.
Все это требует переговоров, копания в документации, взаимодействия с людьми из внешних продуктов и других частей системы. Чем опытнее разработчик, тем чаще он этим занимается. А код? Код пишется в конце, когда выясняются все нужные детали. Написание 20 строчек кода может сопровождаться днями обсуждений.
Заказчик тот, кто платит
Настоящий заказчик разработки — пользователь продукта, именно о его удобстве должен думать в первую очередь программист, приступая к задаче. Задача появляется у разработчика потому, что у клиента есть какая-то проблема, которую нужно решить. Поэтому, в идеальной ситуации, разработчик либо общается с пользователем, либо, с теми, кто общается с пользователями.
В любом случае у разработчика должно быть четкое понимание, как клиент взаимодействует с продуктом. Именно поэтому во многих компаниях использование сотрудниками продуктов бренда — обязательное условие при приеме на работу. В других компаниях, разработчики время от времени переходят в отдел поддержки, чтобы знать потребности и боли клиентов. Если программист этого не знает, он может легко заняться строительством воздушных замков там, где нужны простые и понятные решения.
Программисты не ошибаются
Начинающие разработчики боятся совершать ошибки и пытаются сразу все сделать правильно. Однако если вы решили стать программистом, о перфекционизме придется забыть. Хотите с первого раза написать рабочий код? Увы, не выйдет. В процессе выяснится множество деталей, о которых забыли подумать, либо они проявляются в рабочем коде только у части пользователей. В разработке ошибки — неотъемлемая часть жизни приложения. Более того, значительную часть своего времени разработчики тратят именно на исправление чужих и собственных ошибок.
Опытные разработчики делают ошибок немногим меньше, чем начинающие, но они быстрее их исправляют. В этом им помогают насмотренность и автоматизированные тесты, которые постоянно проверяют код.
Хороший код учитывает все
Распространенная проблема в разработке — «овер-инжиниринг», когда создаются решения, которые учитывают все возможные сценарии, даже те, которые еще не используются. Или многие любят делать код быстрым, в надежде на большую нагрузку, которая наступает лишь у некоторых проектов.
В действительности же начинать следует с самого простого, «деревянного» ответа на проблему пользователя — с решения, которое можно осуществить в короткий срок. При этом неважно, насколько это решение хорошее или плохое. Дальше анализируются преимущества и недостатки выбранного подхода, к решению добавляется что-то, усложняющее его и одновременно делающее лучше. И так шаг за шагом.
На выходе мы получаем не одно решение, а несколько, каждое со своими плюсами и минусами. И только после этого стоит принимать решение, что из этого реализовывать. Если же программист видит только один способ реализовать свою задачу, то он ее не понимает.
Программист должен программировать
Кажется, самый парадоксальный факт из всех описанных: хороший разработчик — не тот, который больше всех кодит. Опытный разработчик может решать задачи, не написав ни строчки кода.
Любой код приходится поддерживать, за ним надо следить. В разработке каждое решение тебя связывает: код ограничивает в выборе последующих решений, потому что в программировании все последующие решения зависят от предыдущих. За годы работы продукта накапливается огромное количество архитектурных решений, от которых невозможно отойти ни вправо, ни влево. И чем больше кода пишется, тем шире эта ловушка.
Если можно не писать код — его не надо писать. При появлении задачи опытный программист всегда выяснит, на что способна уже существующая система, и не будет ее усложнять, если в этом нет необходимости. Например, иногда решить задачу можно удалив код, а не создавая его.
Пример. На сайте школы Хекслет есть рейтинг учеников. Он считался динамически, поэтому через определенное время все начинало тормозить на 20 странице. Мы пришли с проблемой к разработчикам. Что сделает в этом случае неопытный программист? Вероятно, предложит добавить кеширование или периодический расчет рейтинга. Что сделали наши программисты? Предложили обрезать рейтинг до сотого номера, справедливо предположив, что никто не будет листать до 20-й страницы в принципе. Теперь у нас сайте есть рейтинг топ-100. Проблема была решена через продуктовое решение и удаление кода.
Кстати, как бы удивительно это ни звучало, благодаря такому решению у студентов появилось больше стимула к успешной учебе: им интересно попасть в список лучших. Многие начали бороться за попадание в этот рейтинг.
Комментарии (65)
vesper-bot
28.04.2022 11:59+4Пример. На сайте школы Хекслет есть рейтинг учеников. Он считался динамически, поэтому через определенное время все начинало тормозить на 20 странице. Мы пришли с проблемой к разработчикам. Что сделает в этом случае неопытный программист? Вероятно, предложит добавить кеширование или периодический расчет рейтинга. Что сделали наши программисты? Предложили обрезать рейтинг до сотого номера, справедливо предположив, что никто не будет листать до 20-й страницы в принципе.
То есть программисты изменили исходное ТЗ. Насколько корректно оно было сформировано изначально? Был ли ответственный за сайт в курсе, и было ли ему "не пофиг"? А то вот я, например, прекрасно листаю некоторые рейтинги на более чем 100 позиций, и я бы сделал как кэширование, так и периодический перерасчет. Плохой пример, хуже было бы если в примере был бы случай, когда подобный рейтинг или ещё какую-то свистелку просто оторвали за нерентабельностью, или по хотению левой пятки какого-то "программиста". Иной раз не самые простые вещи от отрыва фишек могут сломаться, например, некий довольно критичный для хотя бы юзабилити код третьей стороны.
PS: я постараюсь в следующий раз обновлять вначале комментарии.
dopusteam
28.04.2022 12:02+2Ну судя по статье, Вы и есть тот самый "неопытный программист" :)
vesper-bot
28.04.2022 12:05+5Ну, я всегда исхожу из того, что если в ТЗ нечто есть, запилено оно должно быть так как задано, и если ТЗ стоит как "оптимизировать работу рейтинга по скорости" — кэширование+пересчет по времени будет близко к оптимальному решению. А тут задали ТЗ в форме "рейтинг тормозит", интерпретировали как "а давайте рассчитывать меньше?" и обрезали функционал в результате.
dopusteam
28.04.2022 12:09Я согласен полностью, в статье даже пункт отдельный есть про то, что нужно учитывать удобство пользователя и прорабатывать решение) да и последний пункт имеет место быть (про выпил кода), разве что пример неудачный
siarheiblr
28.04.2022 12:29+3Ну так это нормально. Если функционалом никто (или почти никто) не пользовался, то зачем его поддерживать? Плюс ещё вместо многостраничного непонятно чего получили список лидеров. Win-win.
Вопрос «а оно точно надо?» один из самых важных, пожалуй. Продакт оунер вовсе не бог, ему нужно вопросы задавать, чтобы не делать дурную работу.
vesper-bot
28.04.2022 12:46Дело в том, что в примере обсуждаемый рейтинг уже был, значит, "по умолчанию" после оптимизации должен был не потерять функционала. Если его сократили до топ-100, значит, был запрос на изменение и он прошел того же продакт оунера. Само по себе изменение функционала как задача не хуже и не лучше других, и решить проблему производительности, урезав выдаваемую часть, тоже проходит со своими плюсами и минусами. Вот только разница между "никто" и "почти никто" едва ли не такая же, как между "нигде" и "почти нигде", каковую я бы поостерегся нивелировать подобным образом.
Lexicon
28.04.2022 19:39+3Когда приводят такие примеры оптимизации, почему-то считают разработку кеша вместо обрезания - непомерно ресурсоемкой задачей, а решение, которое затрагивает компетенции QA, дизайна и лида, попутно порождая встречи/созвоны - затратой ресурсов не считают.
MTyrz
28.04.2022 14:08+2Для начала, судя по статье, автора зовут Кирилл Мокевнин — а судя по нику, Олег Сабитов.
На этом месте мой личный парсер уже выбрасывает ошибку изменения значения константы.
FanatPHP
28.04.2022 22:37+2Вы так серьёзно набросились на эту, немного высосанную из пальца, иллюстрацию одного из тезисов, как будто вся статья посвящена одной только теме, "если функционал плохо работает, то его надо выпилить". Поверьте, никто таких утверждений не делал.
haldagan
28.04.2022 13:51+2Насчет рейтинга возникает вопрос - а почему он не кэшировался, ведь изначально должно было быть очевидно, что расчет ресурсоемкий? А если "Оверинжиниринг, нинада нам этого", то почему сразу десяткой-сотней не ограничили в таком случае?
Мне аж интересно стало, как это у вас рассчитывается рейтинг: в вашем случае, судя по рассказу, вычисление следующей позиции рейтинга каким-то образом зависит от вычисления предыдущей, ведь, если бы рейтинг вычислялся линейно, то тормозило бы и на первой странице тоже.
Не поделитесь алгоритмом хотя бы в общих чертах?
Я почти не работал с рейтингами, так что единственное, что приходит в голову, так это какой-нибудь элоподобный алгоритм, но вы не храните очки, а вычисляете их из истории матчей. Но даже этот вариант не подходит: в таком случае все равно сначала нужно будет просчитать все позиции, чтобы узнать топ-100.
toxicmt
28.04.2022 14:24а почему он не кэшировался, ведь изначально должно было быть очевидно, что расчет ресурсоемкий?
Очевидно, но и в той ситуации было очевидно, что есть множество других по настоящему важных вещей, когда делался рейтинг, мы были стартапом с 4 людьми без достаточной прибыли чтобы выживать, рейтинг был проектом выходного дня можно сказать. Никто даже не знал, будет он существовать или нет. А вопрос возник спустя годы после того как его запустили.
По реализации все просто. В базе есть табличка активностей за которые начисляются баллы, соответственно мы просто делали группировку и суммирование баллов.
haldagan
28.04.2022 14:38+1стартапом с 4 людьми без достаточной прибыли
Понятно.
В базе есть табличка активностей за которые начисляются баллы
Непонятно.
Возможно что-то неверно описано в тексте статьи и тормозит, скажем, клиент при рендере, а не сам алгоритм? Если это просто группировка и суммирование, то разница в выдаче скриптом топ-100 и топ-1000 даже без пагинации должна быть минимальна, т.к. в обоих случаях алгоритм сначала должен вычислить баллы для всех пользователей (по моему разумению).
toxicmt
28.04.2022 14:47Там было 200 000 пользователей ;)
haldagan
28.04.2022 15:14+1Сто пользователей или двести тысяч, тысяча активностей или миллион, топ-100 или топ-10000: тормозить должно либо И на первой странице И на двадцатой, либо ни на первой ни на двадцатой в вашем случае, т.к. для вычисления рейтинга вы все равно суммируете всю таблицу с действиями (если у вас нет хитрого способа вычислить, каких пользователей можно игнорировать при расчете топ-Х).
Он считался динамически, поэтому через определенное время все начинало тормозить на 20 странице
Я полагаю, что для 20й страницы вы передаете/показываете/обрабатываете данные по всем 20*х пользователям, а для первой только по 1*x пользователям.
Т.е. виноват не алгоритм расчета и не то, что он динамический, а способ передачи или показа/обработки данных на стороне клиента. Либо какие-то траблы с железом/СУБД.
toxicmt
28.04.2022 15:57+2А понял ваш вопрос. Это конкретная проблема постгри до 13 версии вроде. Из за мультиверсионности каунты работали очень медленно из за необходимости лезть внутрь страниц
randomsimplenumber
29.04.2022 08:47+1Зачем считать рейтинг динамически в момент запроса? Если я правильно понимаю, что такое рейтинг - он обновляется либо в конце периода времени (дня, недели, семестра), либо по моменту сдачи очередной работы. И не нужны хитрые способы кеширования.
haldagan
30.04.2022 11:49Зачем считать рейтинг динамически в момент запроса?
Вы, вероятно ошиблись комментарием: я примерно это и спрашивал.
Ответ: у них не было времени/ресурсов заморачиваться созданием отдельной таблички.
(дня, недели, семестра)
Чисто теоретически у вас могут быть следующие условия:
изменения в БД ресурсоемки, а чтение нет
изменения в рейтинге происходят в разы чаще, чем запросы рейтинга
при каждом запросе рейтинга необходимо отдавать актуальную информацию
В этом случае пересчитывать рейтинг периодически не получится, а при каждом изменении сохранять в таблицу будет дорого, так что без кэша не обойдешься.
vep
28.04.2022 14:40+15Пример. На сайте школы Хекслет есть рейтинг учеников. Он считался динамически, поэтому через определенное время все начинало тормозить на 20 странице. Мы пришли с проблемой к разработчикам. Что сделает в этом случае неопытный программист? Вероятно, предложит добавить кеширование или периодический расчет рейтинга. Что сделали наши программисты? Предложили обрезать рейтинг до сотого номера, справедливо предположив, что никто не будет листать до 20-й страницы в принципе. Теперь у нас сайте есть рейтинг топ-100. Проблема была решена через продуктовое решение и удаление кода.
Что бы сделал я - сказал бы, что сравнивать себя с другими людьми - греховно, и выпилил бы весь функционал рейтинга. :D
DrinkFromTheCup
28.04.2022 14:49Не существует человека, который точно знает, как нужно делать. Любая заранее продуманная логика разбивается о реальность. Именно поэтому в разработке так популярны гибкие методологии, когда продукт делается не по ТЗ от начала до конца.
И именно поэтому что витрины игровых магазинов, что подборки профильного софта, что сами перечни средств разработки забиты до отказа крайне удивительными метисами и креолами, которые вроде бы выполняют свою задачу - но как-то не так...
А если это ещё помножить на тенденцию к feature bloat, ммммм...
В любом случае у разработчика должно быть четкое понимание, как клиент взаимодействует с продуктом.
Вообще-то, у группы заказчиков, проектировавших функционал. Даже если это "Блокнот". Даже если это форк "Блокнота".
А то будет как с Notepadqq vs Notepad++ - редкий пример, когда версия софта под Windows на голову превосходит по удобству версию для Linux. Хотя, казалось бы, одно - клон другого.
Распространенная проблема в разработке — «овер-инжиниринг», когда создаются решения, которые учитывают все возможные сценарии, даже те, которые еще не используются.
...и когда продукт перерастает фазу "теперь это не MVP" и начинает обрастать фичами - это многократно кусает весь связанный с разработкой коллектив за зады при каждой попытке обогатить приложение чем-то полезным...
На сайте школы Хекслет есть рейтинг учеников. Он считался динамически, поэтому через определенное время все начинало тормозить на 20 странице. Мы пришли с проблемой к разработчикам. Что сделает в этом случае неопытный программист? Вероятно, предложит добавить кеширование или периодический расчет рейтинга. Что сделали наши программисты? Предложили обрезать рейтинг до сотого номера, справедливо предположив, что никто не будет листать до 20-й страницы в принципе. Теперь у нас сайте есть рейтинг топ-100. Проблема была решена через продуктовое решение и удаление кода.
Проблема была решена через обрезание релизного (!!!) функционала.
Такой метод решения проблем очень плохо вяжется с указанным ранее тезисом:
Настоящий заказчик разработки — пользователь продукта, именно о его удобстве должен думать в первую очередь программист, приступая к задаче.
Я понимаю, что я нифига не CEO и от моего мнения на самом деле мало что зависит, но я бы очень поостерёгся повышать свои навыки у вас после прочтения этой статьи. В этих "подходах" слишком много hot takes, которые могут вылиться в конечном итоге в обострение уже имеющихся проблем индустрии. Которой и так... не очень хорошо.
FanatPHP
28.04.2022 15:22+9В целом неплохо, но почему-то все поголовно основатели онлайн курсов по программированию не в курсе про отладку. И потом такому свеженькому выпускнику с отличием начинаешь объяснять элементарные вещи:
- Что программист действительно не всё время занимается программированием. Но при этом болтовня с заказчиком не является единственной альтернативой, а у джуна так и вовсе отсутствует. А вот отладкой-то как раз приходится заниматься в полный рост. Потому что, как сказал Фредерик Брукс, "сидеть выдумывать гениальные идеи — это так, расслабуха. А вот когда надо найти одну мелкую гаденькую ошибку — вот тут начинается настоящая работа".
- Что для отлаживания кода на него не надо смотреть. И просить кого-то другого посмотреть тоже не надо. А что код надо запускать. И пошагово трассировать, проверяя корректность работы на каждом этапе
- Что после того как написал код, всё только начинается. И кроме создания программных шедевров программисту ещё надо заниматься их поддержкой. Которая в том числе включает и исправление багов
staticY
28.04.2022 15:29+1Все эти советы для джунов подходят. Они зеленые и не понимают как void main() { ... } в итоге превращается в огромный колл-центр с 150ю операторами, у половины из которых вылазят рандомные баги.
Опытному серверному сеньору с 10+ лет опыта предлагать улучшения и тем более с клиентами общаться? Не надо это ему. Он работает уже в таких командах, в которых есть ПМ, РП, аналитики, которые сами знают что и кому нужно.
Конечно, если просят сделать откровенную дичь, заведомо плохо/сложно реализуемую в техническом плане - я буду протестовать. Но не из-за того, что сильно переживаю за конечных пользователей, а скорее из-за того, что уверен, что потом меня этой дичью по ночам будут доставать: то медленно, то падает, то давай-ка переделаем вот так и так и тп.
saipr
28.04.2022 15:40-3Программист должен программировать
А вот что по поводу программистов думал один из пионеров теоретического и системного программирования академик Андрей Петровичу Ершову (статья «О человеческом и эстетическом факторах в программировании», 1972):
Программист должен обладать способностью первоклассного математика к абстракции и логическому мышлению в сочетании с эдисоновским талантом сооружать все, что угодно, из нуля и единиц. Он должен сочетать аккуратность бухгалтера с проницательностью разведчика, фантазию автора детективных романов с трезвой практичностью экономиста.
Caraul
28.04.2022 16:20+8Огонь тоже считался божественным, пока Прометей не выкрал его. Теперь мы кипятим на нём воду. (с)
dprotopopov
28.04.2022 18:25+1Заказчик тот, кто платит - и никаких гвоздей. И только ему надо объяснять за что он платит.
Le0Wolf
30.04.2022 17:12Все продуманно заранее .
Именно так и должно быть. Что нужно заказчику - знает только заказчик, а если не знает - то есть аналитики и руководители проектов, у которых есть соответствующие хард и софт скилы и опыт реализации подобных проектов, со знанием всех нюансов, которые могут вылезти. Разработчик отвечает за техническую реализацию, а не за то, какие бизнес фитчи будут (хотя и может участвовать в процессе их обсуждения указывая на их трудоёмкость). То, что некоторые экономят на команде и видят в программисте человека-оркестр - это проблема отрасли, а не нормальная практика.
Задачи, которые ставят программистам, обычно описываются с точки зрения поведения обычных пользователей: «Добавить подтверждение входа по смс»
Нет, в таком виде оно приходит как одна из хотелок, которую вместе с заказчиком прорабатывает аналитик. К разработчику должны попадать, как минимум, User Story ну или хотя бы внятное описание (см. далее)
Можно ли его отключить? А если это абонент другой страны? А если человек потерял телефон? А через какой сервис отправить смс?
Задавать такие вопросы - задача аналитика, а не разработчика. От разработчика скорее вопросы вида "как часто нужно отправлять смс" (хотя такие вопросы опытный аналитик и сам задаст)
Это его прямая обязанность — указать на моменты, про которые забыл
Вообще то это задача аналитика. Разработчик такое если делает, то только с точки зрения технической реализации
Все это требует переговоров, копания в документации, взаимодействия с людьми из внешних продуктов и других частей системы. Чем опытнее разработчик, тем чаще он этим зазанимается.
Этим занимается бизнес-аналитик или РП. Время разработчика слишком дорого стоит, чтобы тратить его на пустой треп.
Написание 20 строчек кода может сопровождаться днями обсуждений.
Только если плохо выстроены процессы в компании. Для всех остальных есть аджаил и A/B тестирование. А если даже какие то длительные обсуждения ведутся, то разработчики в них не участвуют - иначе некому будет фичи пилить.
должно быть четкое понимание, как клиент взаимодействует с продуктом
Для этого должна быть документация и чёткие постановки (вклбчая UML диаграммы). Чаще всего программист ни фига не понимает в той сфере, для которой предназначен продукт
Именно поэтому во многих компаниях использование сотрудниками продуктов бренда — обязательное условие при приеме на работу.
Вот прям сразу представил программиста, который является опытным пользователем систем управления бизнесом, инженерного проектирования, архитектурной визуализации и систем поддержки принятия решений уровня государства ))
В действительности же начинать следует с самого простого, «деревянного» ответа на проблему пользователя — с решения, которое можно осуществить в короткий срок. При этом неважно, насколько это решение хорошее или плохое
Для этого есть программы, типа фигмы, а так же low и no code. В остальных случаях плохое решение или нет - важно, если в руководстве конечно не сидят самодуры ибо переделывать плохое решение всегда дороже, чем сразу написать правильно.
На выходе мы получаем не одно решение, а несколько
Мы получаем одно решение ибо время=деньги. Некоторые олько решений можно делать только когда заняться больше нечем и деньги потратить некуда
За годы работы продукта накапливается огромное количество архитектурных решений, от которых невозможно отойти ни вправо, ни влево. И чем больше кода пишется, тем шире эта ловушка.
Только если писать код как левая нога решит. В остальных случаях у продукта есть архитектура и тот, кто за неё отвечает
Например, иногда решить задачу можно удалив код
Удалять код можно только когда того требует бизнес задача. Разработчик лишь может донести до бизнеса (в этой роли могут и аналитики выступать в данном случае), что дешевле фичу выпилить нафиг, чем её переделывать.
dopusteam
Так себе пример. "справедливо предположив" - а у пользователей кто то спрашивал? Может кто то там себя ищет в списке. Так можно и дальше пойти, "Я вот никогда эту кнопку не нажимаю, давайте её удалим, слишком сложно всё там".
Подозрительно)
numezmat19
Кмк можно оставить топ 100 и отображать рейтинг в личном кабинете. И не надо будет выгружать постоянно 20 страниц и каждый ученик будет знать свой рейтинг.
cdmnk
Тогда придётся добавлять кеширование или периодический расчёт рейтинга. А ведь можно удалить личный кабинет
Gorn69
не "может кто-то ищет", а точно кто-то ищет. Если я в рейтинге 1000+, то соревнуюсь с теми кто рядом со-мной выше и ниже, а не с теми, кто в топ100. Верните рейтинг как было!
klounader
и стену!
DrPass
… и как вишенка на торте — «мы не будем заниматься исправлением откровенной лажи, кода, который не мог переварить несчастную тысячу записей, давайте просто сделаем, чтобы современные компьютеры выводили не более сотни». Быстро — да. Но профессионально ли? Нет, ни капли. Непрофессионально поступили ещё на этапе разработки архитектуры этого решения, непрофессионально слепили и костыль.
syfim
Ну, пример, возможно, и не самый удачный, но концепция-то понятна)
Как-то раз делал медицинскую прилагу, одна из фич - при открытии календаря видно, в какой день какую таблетку надо не забыть выпить. Условия для создания расписания очень гибкие - можно создать не только классические "принимать таблетки в 10 утра", но и бесконечное цикличное правило вроде "принимать каждые 6 часов в течении каждой третьей недели месяца на протяжении полугода, потом месяц перерыв, и по новой".
Так вот, пользователь вполне мог открыть календерь хоть следующего столетия, и нужно было подсветить ему, в какие дни есть приём лекарств. Реализовывать подобные рассчёты налету очень геморно, но, будем честны - как часто нам нужно узнать, во сколько потребуется приём таблетки 10 июля 2073 года?
Лучшим решением было пойти к бизнесу и сказать - ребят, на календаре будем показывать расписание только на ближайший год. Потому что мы можем нагенерить событий на год вперёд и отдавать их без рассчётов.
P.S. ох, а сколько там было сложностей с кейсами о поддержании расписания, когда юзер меняет часовые пояса... Вспомнить страшно)
Daemonis
А чего прямо геморного? Нагенерить событий на интервал в год или на неделю - код один и тот же.
Ну да, но еще не забывать их подчищать при каких-то изменениях, плюс догенерить, когда год прошел. Дополнительный геморрой, вообще-то.
syfim
"Нагенерить событий на интервал в год или на неделю" - конечно. А вот "неделя" и "столетие" - уже ощутимие) По 100 000 записей на человека хранить и переделывать при изменении - явно не круто
Sergey_zx
Тут, имхо, две разные параллельно работающие задачи.
Одна, это показ нагенеренных событий из буфера. Вторая, это генерация в буфер актуальных данных. Соответственно, при глобальных изменениях, или просмотрах на 300 лет вперед ждемс пока сгенерится искомое. Зато при остальных 99% обращений все делается мгновенно.
По большей части сам генератор может работать (обновлять данные) когда ему удобнее и когда меньше затрат.
Ну и программить и отлаживать две независимые сущности всяко проще, чем одну гибридную.
xcono
Если курс не хаотичен, то существует правило цикличного исполнения и дата точки отсчёта, то этих данных будет достаточно, чтобы сгенерировать на клиенте результат на любую дату. Возможно, я ошибаюсь и медики способны без Пенроуза создавать бесконечно асиметричные курсы.
syfim
Всё верно, нерешаемых задач в целом почти не встречается в рутинной работе. Тут вопрос о том, сколько времени будет потрачено на реализацию этих рассчётов на клиенте, и соотношение этих затрат с выгодой для проекта/пользователей
DrinkFromTheCup
Большое человеческое "спасибо" за кастрацию функционала, чо.
В вашу целевую аудиторию не входят люди, сидящие на таблетках пожизненно/долгосрочно?
Мне ещё повезло, раз в три месяца месячный курс нольпазы пропил - и порядок, если пропустил недельку (лажанул с закупом) - можно подождать завоза.
А более "хроническим" хроникам что делать, которым условия позволяют закупаться больше, чем на год?
syfim
Эвенты стабльно будут приходить и отрисовываться хоть всю жизнь, они догенерируются по мере движения времени. Единственное, что убрано - возможность заглянуть дальше, чем на год вперёд. Да, рассчитать закупки на десятилетие вперёд не получится, но это и не функционал для закупок - это календарь с напоминалками, у него другая задача.
toxicmt
Тут два момента. Для опроса пользователей сначала нужно выдвинуть гипотезу, а предположение это как раз оно и есть. Второе, далеко не все надо спрашивать пользователей, есть аналитика, есть эксперименты, есть метрики. Так вот в результате оказалось что у этой фичи нулевое влияние на бизнес, поэтому мы выбрали то решение, которое упрощает систему, а не усложняет.
dopusteam
Но, ведь "Настоящий заказчик разработки — пользователь продукта, именно о его удобстве должен думать в первую очередь программист, приступая к задаче. Поэтому, в идеальной ситуации, разработчик либо общается с пользователем, либо, с теми, кто общается с пользователями". Тут что то про бизнес ничего нет
toxicmt
Угу, а кто остался таким же как был 10 лет назад? Хекслет запустился в 2012 году и мы с тех пор все немного стали мудрее
toxicmt
Еще добавлю. Нулевое влияние на бизнес это буквально "если мы уберем эту фичу, не станем зарабатывать меньше". Но не все фичи должны приносить деньги напрямую, всегда есть другие элементы, даже банальный фан, когда например гугл на какой-нибудь праздник красит логотип.
dopusteam
Ну так как это вяжется с тем, что "делаем все для пользователя"?
toxicmt
Рейтинг нравится пользователям да, поэтому он у нас есть, хотя иногда были мысли его вообще убрать, но на деньги он не влияет. Более того, мы однажды его убрали случайно, и нас засыпали письмами чтобы мы его вернули.
Daemonis
Хм...
То есть, стимулы к учебе никак не влияют на бизнес? Интересно.
toxicmt
На получение профессии влияют совсем другие факторы. Достаточно посмотреть на компании которые торгуют курсами. Понятие рейтинга там есть буквально в одном двух проектах
DrinkFromTheCup
Ещё веселее.
То есть, сначала фича с нулевым влиянием на бизнес попала в релиз.
toxicmt
Угу, 9 лет назад, когда мы про бизнес не знали ничего
DrinkFromTheCup
Ваш комментарий порождает очень много интересных вопросов.
Один из самых примечательных: почему тогда этот старый недосмотр выставляется в статье как подвиг и пример для подражания?
toxicmt
То что сделали какую-то фичу и она не сильно повлияла на бизнес показатели, это не недосмотр, а постоянная история во всех проектах. Продуктовая разработка это череда неуспехов к редким победам. Рейтинг и сейчас на сайте есть, только в виде топ-100. В итоге мы довольно быстро, буквально за одну итерацию сделали хорошее решение. А изначальный рейтинг вообще за пару часов запилили.
Потому что это прекрасный пример того, как программисты задают вопросы и включают критическое мышление. Вместо того чтобы решать следствие, они копнули в причину.
GlucK115
С последним абзацев я конечно соглашусь, но...
Всегда есть "но". Свой текущий рейтинг пользователь в общем фоне видит? А тех кто выше и/или ниже него?
Пример: Вот я сейчас 1002, но мне не хватает 1 балла до выше стоящего и двух, чтобы перейти в первую 1000!
Вот это - действительно стимулирующий вариант.
toxicmt
Да это интересная история для экспериментов, но "но" тут в другом. В проекте так много вещей которые по настоящему большие, что вот до такой штуки просто не доходят никогда руки. Задач всегда больше чем людей. Именно поэтому нам проще урезать, чем тратить время на нее.
GlucK115
Фокус в том, что концентрируясь на больших вещах и игнорируя мелочи, как раз и ухудшается восприятие целого проекта.
Обычного пользователя не интересует то, из каких глобальных частей он построен и как круто они там работают, его больше интересуют мелочи которые он видит или не видит. Из десятка другого мелочей и создаётся для "обывателя" общая картина проекта.
С другой стороны, согласен что довольно часто случаются ситуации когда приходится урезать, а то и избавляться от какого-то функционала в угоду разработки. Но данный пример у меня вызвал сразу же один вопрос - что за криворукий создал изначальный рейтинг, если он не может сделать постраничную выборку данных из базы на основании индекса построенного на баллах рейтинга?
FanatPHP
Добро пожаловать в мир реальной разработки. В котором, в отличие от фантазий диванных архитекторов, не возникают из пены морской законченные идеальные шедевры. А всё происходит именно так — сначала кто-то криворукий делает не слишком удачно, потом, по результатам эксплуатации, функционал переосмысливается.
Я смотрю в этом топике прям собрались специалисты по созданию любого функционала, которые всегда заранее знают, как правильно.
Вот только практика, опять же, говорит нам о том что при создании MVP есть только два пути — сделать быстро, но рабочее, или делать идеально, но никогда не взлететь.
DrinkFromTheCup
Поправка.
Сделать быстро, но влететь на стоимости поддержки с высокой вероятностью, - или сделать медленно, по уму, но без вечно опухшего бэклога.
DrinkFromTheCup
И мы вернулись на исходную.
Нужно ли учить подрастающее поколение программистов тому, что такая дикая ситуация - это норма?
Ну. Клёво. Но этому ли нужно учить подрастающее поколение программистов?
А может, это не задача программистов, всё-таки? Ведь код пишется для пользователя, а не для того, чтобы удобно этот код писать было.
toxicmt
Чтож, уровень душности перешел красную черту, пожалуй я умываю руки. Убежал в закат...
FanatPHP
С одной стороны да, я бы даже раньше это сделал. Мужчина сидит на очень высокой лошади и перед очень большим зеркалом.
С другой стороны, это весьма показательный диалог, между практической разработкой и теоретическими представлениями о ней.