Работал и в небольших компаниях и в московском системном интеграторе на 1000 чел. Самые лучшие процессы были вот как раз в интеграторе. Ни до, ни после я лучше не встречал. Как ни странно - мне очень зашел внешний waterfall (то есть у нас реально были объемные ТЗ, которые подписывались клиентами), но внутри шли по канбану или скраму.
С 2015 года я работаю удаленно в основном на зарубежные, продуктовые, компании, размеры до 100 человек. Ни в одной не было нормальных полноценных процессов. Обязательно были только программисты (куда уж без них, где-то больше, где-то меньше, бывало даже 2 программиста на 10 проектов по началу), где-то худо-бедно пытались наладить постановку задач, с тестированием вообще была беда, документация? А что это?
Еще есть разделение на заказную разработку и продуктовую.
Плюсы заказной - каждый раз новый проект и можно начать с чистого листа, набив шишки на предыдущем. Минусы - сделал проект и забыл, чаще всего ты не знаешь насколько хорошо сработала выбранная архитектура и технологии.
Продуктовая - если заговнокодил (а это неизбежно, потому что куда ветер дунул - туда и кодим), то и живи с этим следующие лет 10-15. Никто не будет в продуктовой компании переписывать продукт каждыe 2-3 года. Но зато получаешь громадный опыт поддержки того, что ты заложил. Когда оно начинает развалиться под весом недо-аджаила и новых противоречивых фич. Понимаешь цену минимализма, наличия авто тестов, поддерживаемости и расширямости.
Не могу согласиться, этот подход тоже не работает.
У меня был и есть проект, который был собран на коленке для менее чем 10 клиентов и до 1000 документов в месяц на всех. Не было никакого анализа, архитектура тоже на коленке, лишь бы работало. Это был придаток к другому продукту, который просто принимал json и перекладывал их в БД или отправлял дальше.
Сначала он был моим вторым проектом, где меня просили что-нибудь доработать по мелочи, поправить багу, или добавить какую-нибудь фичу. Я на протяжении двух лет не делал ничего лишнего. Вот как в статье написано. Каждая фича по отдельности была простой.
Через два года бахнуло. Его начали продавать, повалили клиенты, крупные клиенты (сотня-другая тысяч документов на одного клиента в месяц, а сейчас речь уже идет о 500 тыс - миллионе) и начались проблемы. И это оказался франкенштейн, который делает не то, что нужно, не выдерживает никакой нагрузки и в обработке фоновых задач клиенты мешают друг другу.
Ну и пришлось его переписывать на живую примерно год. И то не хватило времени. Не все было исправлено и сделано как надо. И все это время я выслушивал претензии, типа а как так вышло.
Так что нет, и еще раз нет. Сначала предварительный анализ, вот типа как на собесах по системному дизайну:
Вопрос: сколько потенциальных клиентов, ответ: ну как минимум все те, кто уже есть у компании и пользуются существующими продуктами компании
Вопрос: а какая нагрузка? Ответ: ну если посмотреть наши другие продукты, то вот тут например 500 000 документов (не запросов, один документ - это десятки-сотни запросов в базы данных и другие системы, пока он проходит весь воркфлоу) в день
Потом архитектура на основе этого (там тоже можно заложить точки роста, была даже книга Эволюционная архитектура).
И вот уже потом можно сколько угодно говорить о том, как писать простой код в рамках заданной архитектуры. Потому что менять архитектуру и подходы - это долго и сложно.
И в противовес есть два других продукта, которые были сделаны не тяп-ляп, а с анализом, архитектурой (подходящей архитектурой, второй из них был гораздо более простым и его не надо было интегрировать в ESB). И там, на удивление, и код получился более простым и понятным, не пришлось костылить.
ЗЫ: и в первую очередь надо закладывать логирование и телеметрию запросов (чтобы потом не гадать на кофейной гуще) и авто-тестирование (чтобы потом не было мучительно больно дорабатывать фичи).
Из личного опыта - в далеком 2012 году я устроился на новую работу, в один из московских системных интеграторов с обещанием дать мне возможность стать ведущим программистом. Руководитель обещание сдержал и в конце 2012 - начале 2013 назначил меня тех лидом. Команда на каждом проекте была от 2-4 до 5-7 человек. Я успел поучаствовать в двух проектах.
Кстати мне было 27-28 лет. Почти што 23 летний сениор 😅. Было ссыкотно. Интегратор работал в банковской сфере и я все ждал когда из банков наших клиентов ко мне придут матерые и лютые энтерпрайз архитекторы с вопросами "а почему ты выбрал такую архитектуру?" или "как ты собираешься интегрировать свои сервисы с нашей IBM Service Bus" и все вскроется, а меня уволят 😁
Я не настраивал процессы, не лез в душу к людям, не нанимал и не увольнял. Я делал каркас солюшена, выбирал технологии, закладывал подходы. И потом программисты пилили бизнес-логику уже без меня. Один из проектов был основным, где я участвовал в роли программиста и проводил код ревью. Изумительное время тогда было. Процессы были самые лучшие из всех, когда я либо видел до и после. Я работал с людьми, кто впоследствии стали лидами/сениорами во всяких Швециях, Испаниях, Германиях и Канадах.
Но приходилось распределять задачи, и было пару моментов с людьми..., без конфликтов. Типа чел не любил делать отчеты (UI часть), а я пытался показать ему другую точку зрения. Я понимал, что это обязанности тим-лида. И у меня довольно долго в резюме был указан опыт тим-лидерства. И однажды мне стали писать с вакансиями именно тим-лидов, без кодинга, без технологий. Вот именно тогда я понял, что тим-лид это совершенно другая роль. В тех вакансиях были усложненные требования и обязанности, которых я не приобрел. И я убрал тим-лидерство из своего резюме.
Как всегда - каждая компания под лычкой лида понимает что-то свое. Но я не ожидал такого от Альфа-Банка. В описании мешанина тим-лида и тех-лида + вешают обязанности продукт овнера. А это значит вы, автор, работаете за двоих или даже троих, а зарплату получаете за одного.
Тех лид - это
Техническое виденье продуктов, технологии, технические подходы в решении задач. Примерами могут являться - курирование разработки единой платформы для всех продуктов, R&D для оценки внедрения очередной технологии (колоночная БД, какой-нибудь новый брокер, тарантул, замена джунов внедрение ИИ и тому подобное)
Я бы сказал, что он делит обязанности улучшения процессов (наравне с тим-лидом, руководителем отдела, CTO). Например внедрение метрик качества архитектуры, ревью кода и тому подобное
Тех-лид НЕ решает межличностные конфликты. Не является единственным или главным ЛПР при найме в команду или увольнении. Тех-лид не распределяет задачи и не является ведущим дейликов
Тех-лид обязан работать с кодом и технологиями, иначе со временем его знания и кругозор устареет. Поэтому, если на него вешать еще и пункты 2 и 3 в полной мере - у такого человека не будет времени поддерживать техническую экспертизу
Тех-лид обязан читать техническую литературу
Тим-лид - а вот этот чувак перформит команду:
Решает конфликты, строит планы обучения и развития карьеры
Принимает на работу с (совместно руководителем отдела, CTO), проводит ежегодную оценку, увольняет
Больше участвует в улучшении процессов. Потому что процессы - это в основном для людей. С командой доброжелательных сениоров можно местами и подзабить на процессы. А вот джунов и зуммеров надо регулярно пинать, чтобы они нормально работали
Тим-лид читает литературу по управлению людьми, психологии.
И если пройтись по этим пунктам
Разработчик 1: «О чёрт, все пропало! Помнишь, я вливал в релиз свою доработку? Кажется, она сломала нам прод».
Ну так иди и чини ее. Но на самом деле это больше к руководителю отдела / CTO, потому что проблема в отсутствии тестирования / сбой в процессах. Тех-лид может посоветовать какую технологию или подход использовать для тестирования. Или посоветовать с настройкой человеческих процессов.
Разработчик 2: «Блин, да этот разработчик N вечно придирается ко мне на ревью, так и хочется пойти поругаться с ним»
Это чисто работа тим-лида.
Продукт овнер: «У нас тут такая интересная идея: хотим пользователю после негативного отзыва на наше приложение блокировать использование телефона. Чтобы ему неповадно было нам плохие отзывы оставлять. Крутая идея?»
Почему продукт овнер перекладывает свою работу на тех-лида? Оценка идей - это не работа тех-лида. У него можно спросить "а можно ли в телефоне заблокировать звонки" и только.
Дизайнер: «Прикинь, что придумали для нашего Android-приложения: сделаем градиентный экран, который начнет проигрывать популярные хиты 90-х годов и главное, чтобы экран выглядел точь-в-точь как на iOS»
Аналогично - с такими вопросами и предложениями к продукт овнеру, пускай сами там разбираются.
Специалист сопровождения: «У нас тут критичный баг, неизвестно какая команда, нужно срочно починить».
Пожалуй единственный более-менее подходящий пример. Если много компонентов и много команд. Тут как раз нужна оценка технических глубин, чтобы примерно понять - баг это или фича и где он примерно может быть.
Только работники уровня Senior пока могут чиллить — динамика роста у них такая же, но со значения 0,7 до 1,7 (на каждую вакансию не приходится и двух резюме).
Никогда не понимал фриланс - куча работы по заявкам, общению и все за копейки, с риском кидалова, с неадекватными заказчиками, типа сделай мне полную копию одноклассников за 10000 рублей.
Даже когда я работал в регионе за местную зарплату и ставил цену по своей зарплате (25-30 тыс рублей в месяц в те далекие времена), то не получал никаких заказов.
Да и заказы в целом были полной хренью. Нормальные заказы (по первому взгляду - похожее на то, чем я занимался на обычной работе) были на одной из бирж под про аккаунтом, но за него надо было платить. Серьезно? Платить за то, чтобы не получать заказов?
На веблансерее.нэт попался один адекватный заказ, даже созвонились с клиентом. Но то ли они вообще отказались от затеи, то ли просто меня не выбрали.
Один заказ за все время! Где мне удалось хотя бы в живую пообщаться с клиентом.
Хорошо, что после этих попыток я нашел просто удаленку, был это 2010 год. Полная загрузка всегда, без нервов, кидалова, почасовая ставка. Можно было брать больше часов и задач. Можно было работать на двух работах и тем самым повышать доход. Потом настало время зарубежной удаленки. Короче забыл этот фриланс как страшный сон, и хрен с ним.
Зы: кстати одна из зарубежных удаленок платила через upwork. То есть у меня там образовался профиль с 4 летним опытом работы, порядка 7-8 тысяч отработанных часов. Думаете помогло это получить там хотя бы один заказ? Да щас прям…!
Точно!! Увидел фотку электроники вм-12 и накрыло эффектом Манделы. Он же был черным и на ощупь как бы с выступом. У тети был такой, с тв тюнером и она мне записывала мультики с ОРТ в 15.20, пока я был в школе во вторую смену…
Но Гугл все расставил по местам - это не электроника, это был Panasonic NV-2000! Оригинал против копии.
На котолампу похоже. Вообще опенспейс с гнетущей тишиной - это фантастика. Больше 5 человек в комнате и начинается галдеж. Чем больше людей - тем сильнее.
Я встречал токсичных людей, есть куча компаний без документации и процессов, с bus factor = 1, когда народ постоянно занят и зашивается и т.п. Но чтоб такой безысходностью веяло - слишком уж.
Сложилось ощущение, что джун зуммер попал в коллектив сеньористых бейби бумеров и просто не вписался.
Ощущение причастности, потому что сам 15-20 лет назад учился в аналогичном вузе с аналогичной атмосферой / аурой / вайбом.
Тот самый win forms в региональной госухе начала тысячелетия, где из-за скукоты и однообразия придумываешь справочник справочников.
Делфи 7 и firebase, застрявшие в пространственно-временном континууме.
Сферический программист 16 летней выдержки из НИИ им. Ленина Государственного Университета им. Ленина города Н-ска (лучше не выходить в современный несущийся на всех парах мир с его сберами, яндаксами и озонами, ИИ-шками, современными технологиями и подходами, алго-собесами в стиле фаанга, удаленки, зарубежной удаленки, больших и сложных проектах меняющие отрасль или даже мир - можно получить удар по психике 😧 )
Запредельная наивность (ведь не с чем сравнить свои 750 таблиц и 2000 хранимок) и ламповость (как будто привет из давно забытого прошлого).
Нетленка и пусть весь мир катится ко всем чертям 🙂. Как вы смогли все это сохранить?
Чтобы декомпозировать задачу - надо знать, что нужно сделать
Чтобы знать, что нужно сделать - надо добиться внятных требований и провести анализ
На выходе получим некое техническое решение
(на эти первые пункты уже надо потратить время и оценить его в SP / часах)
(тут начинается статья)
Техническое решение уже можно разбить на мелкие задачи
Конкретный программист кодит, по нему считают индивидуальный коэффициент конвертации SP > часы
(тут статья заканчивается)
Теперь это все надо протестировать - функциональное, регрессионное, нагрузочное и т.п. Если продолжать аналогию - как только яму раскопали, должен прийти отдельный человек и оценить качество - а достигнута ли нужна глубина?
(где учитываются стори поинты на тестирование и где формула конвертации в часы?)
Каким образом программист и тестировщик может оценить свою часть работы в SP, если у него нет анализа, тест кейсов? В итоге все равно приходим к формуле "что сказал программист" умножить на 'пи' и на 'е' ?
Ребус мне понравился. Было две проблемы - retry policy, но она решилась. И приоритет очередей - в те времена автор писал в GitHub issues, что он рассматривает очереди чисто как тупой транспорт. Поэтому блокировками и приоритетами должны управлять консюмеры.
В этом плане hangfire с его мьютаксами, семафорами и тп, оказался более функциональным. Но это кстати у него тоже платная часть.
Как же тяжко живется зуммерам и насколько терпеливый оказался работодатель - два собеса терпеть проблемы с интернетом.
Работал и в небольших компаниях и в московском системном интеграторе на 1000 чел. Самые лучшие процессы были вот как раз в интеграторе. Ни до, ни после я лучше не встречал. Как ни странно - мне очень зашел внешний waterfall (то есть у нас реально были объемные ТЗ, которые подписывались клиентами), но внутри шли по канбану или скраму.
С 2015 года я работаю удаленно в основном на зарубежные, продуктовые, компании, размеры до 100 человек. Ни в одной не было нормальных полноценных процессов. Обязательно были только программисты (куда уж без них, где-то больше, где-то меньше, бывало даже 2 программиста на 10 проектов по началу), где-то худо-бедно пытались наладить постановку задач, с тестированием вообще была беда, документация? А что это?
Еще есть разделение на заказную разработку и продуктовую.
Плюсы заказной - каждый раз новый проект и можно начать с чистого листа, набив шишки на предыдущем. Минусы - сделал проект и забыл, чаще всего ты не знаешь насколько хорошо сработала выбранная архитектура и технологии.
Продуктовая - если заговнокодил (а это неизбежно, потому что куда ветер дунул - туда и кодим), то и живи с этим следующие лет 10-15. Никто не будет в продуктовой компании переписывать продукт каждыe 2-3 года. Но зато получаешь громадный опыт поддержки того, что ты заложил. Когда оно начинает развалиться под весом недо-аджаила и новых противоречивых фич. Понимаешь цену минимализма, наличия авто тестов, поддерживаемости и расширямости.
Не могу согласиться, этот подход тоже не работает.
У меня был и есть проект, который был собран на коленке для менее чем 10 клиентов и до 1000 документов в месяц на всех. Не было никакого анализа, архитектура тоже на коленке, лишь бы работало. Это был придаток к другому продукту, который просто принимал json и перекладывал их в БД или отправлял дальше.
Сначала он был моим вторым проектом, где меня просили что-нибудь доработать по мелочи, поправить багу, или добавить какую-нибудь фичу. Я на протяжении двух лет не делал ничего лишнего. Вот как в статье написано. Каждая фича по отдельности была простой.
Через два года бахнуло. Его начали продавать, повалили клиенты, крупные клиенты (сотня-другая тысяч документов на одного клиента в месяц, а сейчас речь уже идет о 500 тыс - миллионе) и начались проблемы. И это оказался франкенштейн, который делает не то, что нужно, не выдерживает никакой нагрузки и в обработке фоновых задач клиенты мешают друг другу.
Ну и пришлось его переписывать на живую примерно год. И то не хватило времени. Не все было исправлено и сделано как надо. И все это время я выслушивал претензии, типа а как так вышло.
Так что нет, и еще раз нет. Сначала предварительный анализ, вот типа как на собесах по системному дизайну:
Вопрос: сколько потенциальных клиентов, ответ: ну как минимум все те, кто уже есть у компании и пользуются существующими продуктами компании
Вопрос: а какая нагрузка? Ответ: ну если посмотреть наши другие продукты, то вот тут например 500 000 документов (не запросов, один документ - это десятки-сотни запросов в базы данных и другие системы, пока он проходит весь воркфлоу) в день
Потом архитектура на основе этого (там тоже можно заложить точки роста, была даже книга Эволюционная архитектура).
И вот уже потом можно сколько угодно говорить о том, как писать простой код в рамках заданной архитектуры. Потому что менять архитектуру и подходы - это долго и сложно.
И в противовес есть два других продукта, которые были сделаны не тяп-ляп, а с анализом, архитектурой (подходящей архитектурой, второй из них был гораздо более простым и его не надо было интегрировать в ESB). И там, на удивление, и код получился более простым и понятным, не пришлось костылить.
ЗЫ: и в первую очередь надо закладывать логирование и телеметрию запросов (чтобы потом не гадать на кофейной гуще) и авто-тестирование (чтобы потом не было мучительно больно дорабатывать фичи).
Да, надоело.
Поэтому купил красную машину, и летом ношу ярко оранжевую, салатную или бордовую рубашку.
Да, мир не идеален.
Из личного опыта - в далеком 2012 году я устроился на новую работу, в один из московских системных интеграторов с обещанием дать мне возможность стать ведущим программистом. Руководитель обещание сдержал и в конце 2012 - начале 2013 назначил меня тех лидом. Команда на каждом проекте была от 2-4 до 5-7 человек. Я успел поучаствовать в двух проектах.
Кстати мне было 27-28 лет. Почти што 23 летний сениор 😅. Было ссыкотно. Интегратор работал в банковской сфере и я все ждал когда из банков наших клиентов ко мне придут матерые и лютые энтерпрайз архитекторы с вопросами "а почему ты выбрал такую архитектуру?" или "как ты собираешься интегрировать свои сервисы с нашей IBM Service Bus" и все вскроется, а меня уволят 😁
Я не настраивал процессы, не лез в душу к людям, не нанимал и не увольнял. Я делал каркас солюшена, выбирал технологии, закладывал подходы. И потом программисты пилили бизнес-логику уже без меня. Один из проектов был основным, где я участвовал в роли программиста и проводил код ревью. Изумительное время тогда было. Процессы были самые лучшие из всех, когда я либо видел до и после. Я работал с людьми, кто впоследствии стали лидами/сениорами во всяких Швециях, Испаниях, Германиях и Канадах.
Но приходилось распределять задачи, и было пару моментов с людьми..., без конфликтов. Типа чел не любил делать отчеты (UI часть), а я пытался показать ему другую точку зрения. Я понимал, что это обязанности тим-лида. И у меня довольно долго в резюме был указан опыт тим-лидерства. И однажды мне стали писать с вакансиями именно тим-лидов, без кодинга, без технологий. Вот именно тогда я понял, что тим-лид это совершенно другая роль. В тех вакансиях были усложненные требования и обязанности, которых я не приобрел. И я убрал тим-лидерство из своего резюме.
Тут можно писать в отчет что-то типа
10:00-10:01 запустил комп и открыл отчет за день
10:01-10:02 писал в отчет что делал в предыдущую минуту с 10:00 по 10:01
10:02-10:03 писал в отчет что делал в предыдущую минуту с 10:01 по 10:02
Как всегда - каждая компания под лычкой лида понимает что-то свое. Но я не ожидал такого от Альфа-Банка. В описании мешанина тим-лида и тех-лида + вешают обязанности продукт овнера. А это значит вы, автор, работаете за двоих или даже троих, а зарплату получаете за одного.
Тех лид - это
Техническое виденье продуктов, технологии, технические подходы в решении задач. Примерами могут являться - курирование разработки единой платформы для всех продуктов, R&D для оценки внедрения очередной технологии (колоночная БД, какой-нибудь новый брокер, тарантул,
замена джуноввнедрение ИИ и тому подобное)Я бы сказал, что он делит обязанности улучшения процессов (наравне с тим-лидом, руководителем отдела, CTO). Например внедрение метрик качества архитектуры, ревью кода и тому подобное
Тех-лид НЕ решает межличностные конфликты. Не является единственным или главным ЛПР при найме в команду или увольнении. Тех-лид не распределяет задачи и не является ведущим дейликов
Тех-лид обязан работать с кодом и технологиями, иначе со временем его знания и кругозор устареет. Поэтому, если на него вешать еще и пункты 2 и 3 в полной мере - у такого человека не будет времени поддерживать техническую экспертизу
Тех-лид обязан читать техническую литературу
Тим-лид - а вот этот чувак перформит команду:
Решает конфликты, строит планы обучения и развития карьеры
Принимает на работу с (совместно руководителем отдела, CTO), проводит ежегодную оценку, увольняет
Больше участвует в улучшении процессов. Потому что процессы - это в основном для людей. С командой доброжелательных сениоров можно местами и подзабить на процессы. А вот джунов и зуммеров надо регулярно пинать, чтобы они нормально работали
Тим-лид читает литературу по управлению людьми, психологии.
И если пройтись по этим пунктам
Ну так иди и чини ее. Но на самом деле это больше к руководителю отдела / CTO, потому что проблема в отсутствии тестирования / сбой в процессах. Тех-лид может посоветовать какую технологию или подход использовать для тестирования. Или посоветовать с настройкой человеческих процессов.
Это чисто работа тим-лида.
Почему продукт овнер перекладывает свою работу на тех-лида? Оценка идей - это не работа тех-лида. У него можно спросить "а можно ли в телефоне заблокировать звонки" и только.
Аналогично - с такими вопросами и предложениями к продукт овнеру, пускай сами там разбираются.
Пожалуй единственный более-менее подходящий пример. Если много компонентов и много команд. Тут как раз нужна оценка технических глубин, чтобы примерно понять - баг это или фича и где он примерно может быть.
@R_Zhukov1да, вот где этот текст
О, я недавно тоже обновил видеокарту на 4080 super в компе 2017 года (i7-8700k)
Никогда не понимал фриланс - куча работы по заявкам, общению и все за копейки, с риском кидалова, с неадекватными заказчиками, типа сделай мне полную копию одноклассников за 10000 рублей.
Даже когда я работал в регионе за местную зарплату и ставил цену по своей зарплате (25-30 тыс рублей в месяц в те далекие времена), то не получал никаких заказов.
Да и заказы в целом были полной хренью. Нормальные заказы (по первому взгляду - похожее на то, чем я занимался на обычной работе) были на одной из бирж под про аккаунтом, но за него надо было платить. Серьезно? Платить за то, чтобы не получать заказов?
На веблансерее.нэт попался один адекватный заказ, даже созвонились с клиентом. Но то ли они вообще отказались от затеи, то ли просто меня не выбрали.
Один заказ за все время! Где мне удалось хотя бы в живую пообщаться с клиентом.
Хорошо, что после этих попыток я нашел просто удаленку, был это 2010 год. Полная загрузка всегда, без нервов, кидалова, почасовая ставка. Можно было брать больше часов и задач. Можно было работать на двух работах и тем самым повышать доход. Потом настало время зарубежной удаленки. Короче забыл этот фриланс как страшный сон, и хрен с ним.
Зы: кстати одна из зарубежных удаленок платила через upwork. То есть у меня там образовался профиль с 4 летним опытом работы, порядка 7-8 тысяч отработанных часов. Думаете помогло это получить там хотя бы один заказ? Да щас прям…!
Точно!! Увидел фотку электроники вм-12 и накрыло эффектом Манделы. Он же был черным и на ощупь как бы с выступом. У тети был такой, с тв тюнером и она мне записывала мультики с ОРТ в 15.20, пока я был в школе во вторую смену…
Но Гугл все расставил по местам - это не электроника, это был Panasonic NV-2000! Оригинал против копии.
Смотрел в детстве, а потом пересмотрел полностью в осознанном возрасте - и там оказался вполне ничего такой сюжет.
@R_Zhukov1
А не подскажите - какой коэффициент в первые три месяца 2025 года для сениоров?
На котолампу похоже. Вообще опенспейс с гнетущей тишиной - это фантастика. Больше 5 человек в комнате и начинается галдеж. Чем больше людей - тем сильнее.
Я встречал токсичных людей, есть куча компаний без документации и процессов, с bus factor = 1, когда народ постоянно занят и зашивается и т.п. Но чтоб такой безысходностью веяло - слишком уж.
Сложилось ощущение, что джун зуммер попал в коллектив сеньористых бейби бумеров и просто не вписался.
Тут прекрасно чуть более чем все 🙂
Ощущение причастности, потому что сам 15-20 лет назад учился в аналогичном вузе с аналогичной атмосферой / аурой / вайбом.
Тот самый win forms в региональной госухе начала тысячелетия, где из-за скукоты и однообразия придумываешь справочник справочников.
Делфи 7 и firebase, застрявшие в пространственно-временном континууме.
Сферический программист 16 летней выдержки из
НИИ им. ЛенинаГосударственного Университета им. Ленина города Н-ска (лучше не выходить в современный несущийся на всех парах мир с его сберами, яндаксами и озонами, ИИ-шками, современными технологиями и подходами, алго-собесами в стиле фаанга, удаленки, зарубежной удаленки, больших и сложных проектах меняющие отрасль или даже мир - можно получить удар по психике 😧 )Запредельная наивность (ведь не с чем сравнить свои 750 таблиц и 2000 хранимок) и ламповость (как будто привет из давно забытого прошлого).
Нетленка и пусть весь мир катится ко всем чертям 🙂. Как вы смогли все это сохранить?
А я на 11 уровне (где за шариком несутся куча ножниц) мечтал замкнуть их сами на себя по кругу и спокойно собирать ягодки, да все никак не выходило
Скрытый текст
Регулярно играю в старые игры - в последнее время больше UFO из статьи и Master of Orion 1.
Грузятся мгновенно, а не по полчаса как RDR2 (вот прям вообще лень его включать, уйма времени на запуск уходит).
В реальности много неизвестных:
Чтобы декомпозировать задачу - надо знать, что нужно сделать
Чтобы знать, что нужно сделать - надо добиться внятных требований и провести анализ
На выходе получим некое техническое решение
(на эти первые пункты уже надо потратить время и оценить его в SP / часах)
(тут начинается статья)
Техническое решение уже можно разбить на мелкие задачи
Конкретный программист кодит, по нему считают индивидуальный коэффициент конвертации SP > часы
(тут статья заканчивается)
Теперь это все надо протестировать - функциональное, регрессионное, нагрузочное и т.п. Если продолжать аналогию - как только яму раскопали, должен прийти отдельный человек и оценить качество - а достигнута ли нужна глубина?
(где учитываются стори поинты на тестирование и где формула конвертации в часы?)
Каким образом программист и тестировщик может оценить свою часть работы в SP, если у него нет анализа, тест кейсов? В итоге все равно приходим к формуле "что сказал программист" умножить на 'пи' и на 'е' ?
Ребус мне понравился. Было две проблемы - retry policy, но она решилась. И приоритет очередей - в те времена автор писал в GitHub issues, что он рассматривает очереди чисто как тупой транспорт. Поэтому блокировками и приоритетами должны управлять консюмеры.
В этом плане hangfire с его мьютаксами, семафорами и тп, оказался более функциональным. Но это кстати у него тоже платная часть.