Комментарии 32
Я не знаю, что хочет услышать человек, задающий этот вопрос, но у меня есть ответ на его техническую составляющую и бэклог на несколько месяцев вперед.
Я правильно понимаю, что ничего ещё не узнав про проект, его нужды и проблемы, вы предлагает руководству оплатить несколько месяцев вашей работы для того, чтобы почесать ваше ЧСВ?
Нет, тулчейн и инструкции, без сомнения, достойны внимания, но вот посыл во вступлении странный.
В самом начале я упомянул, что бэклога хватит на несколько месяцев вперед. Это не значит, что на всех проектах всё займет одинаковое количество времени. Это, скорее, в среднем по больнице, учитывая, что большую часть рабочего времени мы решаем проблемы бизнеса.
Нет, Вы не правильно понимаете. Разработчик должен уделять вниманию качеству кодовой базы и ЧСВ тут не при чем. Вы же дома убираетесь? Вот так же нужно убираться и у себя в проекте. В крупных компаниях под техническую квоту закладывают время и дают возможность разработчикам исправить или улучшить кодовую базу. И ни кто не говорит что вы должны только этим заниматься, рефакторинг можно делать постепенно.
Знаю, что статья по большей части техническая и хотелось бы узнать больше про то, как это все внедрить и донести необходимость этих действий до начальства и других разработчиков.
Занимаемся проектной деятельностью. На одном проекте добавил проверку linter-ом и форматирование prettier-ом на pre-commit, чтобы никто не мог плохого закоммитить. Но после моего ухода с проекта, команда «забила» на такую штуку и не стала переносить его дальше на другие проекты, даже не смотря на то, что ощущали плюсы данных настроек и перенос конфигов с одного проекта на другой занял бы максимум 20 минут.
Занимаемся проектной деятельностью. На одном проекте добавил проверку linter-ом и форматирование prettier-ом на pre-commit, чтобы никто не мог плохого закоммитить. Но после моего ухода с проекта, команда «забила» на такую штуку и не стала переносить его дальше на другие проекты, даже не смотря на то, что ощущали плюсы данных настроек и перенос конфигов с одного проекта на другой занял бы максимум 20 минут.
Данный вопрос довольно тяжелый, так как к каждому человеку нужен свой подход. Но вот подходы которыми я пользуюсь с бизнесом.
Сроки
Вы можете оперировать сроками решения задач. Скажем так, если уделить время на рефакторинг конкретного куса кода — то реализация любой задачи в этой области будет стоить куда меньше чем без рефакторинга.
Баги
Вы можете оперировать тем, что без рефакторинга качество вашего продукта падает с каждой новой фичей. И если вы не уделите этому время, то в скором будущем — возможно вы не сможете реализовать фичу без полной переделки функциональности.
Пользователи
Можно попытаться продать рефакторинг улучшением UX. Ведь довольный пользователь — это меньше отказов и больше конверсия.
Если взять разработку, то все зависит от вашей позиции в команде и от ваших софт скилов. Можно провести конструктивную встречу с командой или тим-лидом. Если Вас не услышали — не отчаивайтесь, возможно на то были причины. Переварите беседу и попробуйте еще раз через месяц. За мою карьеру было и такое, что от желания сделать проект лучше, до выкатки в прод — проходило пол года.
Сроки
Вы можете оперировать сроками решения задач. Скажем так, если уделить время на рефакторинг конкретного куса кода — то реализация любой задачи в этой области будет стоить куда меньше чем без рефакторинга.
Баги
Вы можете оперировать тем, что без рефакторинга качество вашего продукта падает с каждой новой фичей. И если вы не уделите этому время, то в скором будущем — возможно вы не сможете реализовать фичу без полной переделки функциональности.
Пользователи
Можно попытаться продать рефакторинг улучшением UX. Ведь довольный пользователь — это меньше отказов и больше конверсия.
Если взять разработку, то все зависит от вашей позиции в команде и от ваших софт скилов. Можно провести конструктивную встречу с командой или тим-лидом. Если Вас не услышали — не отчаивайтесь, возможно на то были причины. Переварите беседу и попробуйте еще раз через месяц. За мою карьеру было и такое, что от желания сделать проект лучше, до выкатки в прод — проходило пол года.
Почему в новом проекте должны быть мусорные файлы, косой стиль, нет Sentry и отсутствовать CI?
В статье ни где не указано про новый проект.
Более того, это набор чеков, если они все успешно будут пройдены — то вопросов нет, но как показывает практика в каком-то объеме эти шаги Вам будут нужны.
Представьте ситуацию, вы первый день на новом для вас проекте, с чего будете начинать? Опишите свои шаги.
Более того, это набор чеков, если они все успешно будут пройдены — то вопросов нет, но как показывает практика в каком-то объеме эти шаги Вам будут нужны.
На незнакомом проекте поудалять файлы автоматической тулзой, сделать кучу правок во всех местах, где ругается линтер, обновить версии зависимостей и добавить сверху ещё одну либу… звучит надежно, как швейцарские часы!
Стоит потратить время на исправление ошибок, найденных Lighthouse
Лайтхаус может выдать сотню и на сайте, который заставляет ноутбуки лететь в стратосферу на вентиляторах. Лучше руками запустить приложение и потыкать в него, посмотреть, где что там тормозит, запустить профайлер… Но это ведь всё сложно, лучше довериться маяку!
Я с Вами согласен от части, руками тоже все можно делать и более того, если хочется пойти дальше то это будет необходимо. Но нет ничего плохого в автоматизации проверок, они экономят Вам время.
А пользователю они потребление ресурсов экономят? Простите, вы делаете проект для себя или для пользователя?
А пользователю они потребление ресурсов экономят?
Конечно экономят. Если следовать советам от Lighthouse — ваше приложение станет легче, загружаться оно будет быстрее (экономя время пользователя и трафик). Браузеру будет нужно тратить намного меньше ресурсов для парсинга файлов.
Простите, вы делаете проект для себя или для пользователя?
Мы делаем наши приложения для пользователей в первую очередь.
> вы первый день на новом для вас проекте, с чего будете начинать?
Точно не с «разнести своими улучшалками половину проекта, не попытавшись понять что привело проект в такое состояние, глубинных причин и настроений команды»
Вариантов «как закопать своим энхансментом проект» просто масса:
— Вы наделали суперулучшений вместо ценных фич, чем затормозили, возможно, горящую разработку. Кастомер посмотрел на это грустно и раззорился
— Вы наделали суперулучшений в проекте в той фазе, когда от проекта требуется стабильность, например, у вас был проект про рекламу, а вы перефигачили его прям в ночь перед черной пятницей и внесли один маленький фатальный баг. Клиент очень удивился, но тоже раззорился от греха подальше
— Вы наделали суперулучшений и теперь этот код можете прочитать только вы. Команда ничего не поняла и уволилась, а вы один, как ни крути, не можете заменить всю команду сразу
— Вы наделали суперулучшений, прямо перед тем, как другой разработчик собирался заливать свою фичу над которой работал две недели. Теперь весь его ПР — это один большой гит-конфликт. Фича была очень нужна в проде через три недели и теперь никто никуда не успеет
— Вы наделали суперулучшений, проект стал лучше и чище, все счастливы. Из-за выросшего перформанса, инфраструктура не выдержала и там, где раньше были чуть более высокие таймауты, прилег кластер. Никому не понравилось
Проолжать можно долго
Если бы у меня спросили «что вы будете делать в первый день на проекте», я бы предположил что буду ходить по людям и пытаться понять, кому этот проект нужен, зачем он существует и что сейчас важно команде. А трогать лапками код и оркестрировать ансиблами, далеко-далеко не сразу
Точно не с «разнести своими улучшалками половину проекта, не попытавшись понять что привело проект в такое состояние, глубинных причин и настроений команды»
Вариантов «как закопать своим энхансментом проект» просто масса:
— Вы наделали суперулучшений вместо ценных фич, чем затормозили, возможно, горящую разработку. Кастомер посмотрел на это грустно и раззорился
— Вы наделали суперулучшений в проекте в той фазе, когда от проекта требуется стабильность, например, у вас был проект про рекламу, а вы перефигачили его прям в ночь перед черной пятницей и внесли один маленький фатальный баг. Клиент очень удивился, но тоже раззорился от греха подальше
— Вы наделали суперулучшений и теперь этот код можете прочитать только вы. Команда ничего не поняла и уволилась, а вы один, как ни крути, не можете заменить всю команду сразу
— Вы наделали суперулучшений, прямо перед тем, как другой разработчик собирался заливать свою фичу над которой работал две недели. Теперь весь его ПР — это один большой гит-конфликт. Фича была очень нужна в проде через три недели и теперь никто никуда не успеет
— Вы наделали суперулучшений, проект стал лучше и чище, все счастливы. Из-за выросшего перформанса, инфраструктура не выдержала и там, где раньше были чуть более высокие таймауты, прилег кластер. Никому не понравилось
Проолжать можно долго
Если бы у меня спросили «что вы будете делать в первый день на проекте», я бы предположил что буду ходить по людям и пытаться понять, кому этот проект нужен, зачем он существует и что сейчас важно команде. А трогать лапками код и оркестрировать ансиблами, далеко-далеко не сразу
Действительно, продолжать можно долго, если прочитать только первый абзац статьи, мне очень жаль что Вы не поняли ее смысла и нашли в ней призывы положить прод в первый день и остановить разработку на пол года.
Статья про технический чек лист и чем себя занять кроме клепания фич, пять дней в неделю.
Статья про технический чек лист и чем себя занять кроме клепания фич, пять дней в неделю.
Извините, не соглашусь. Авто пишет «вы первый день на новом для вас проекте, с чего будете начинать» и далее описывает, как положить прод в первый день и остановить разработку на полгода
Пост был бы прекрасным техническим чеклистом, если бы в нем не было абзаца про «в первый день». Потому что, описанное автором, очень полезно и нужно, но делать это имхо, стоит после того как влился в команду и подхватил знамя культуры разработки
Пост был бы прекрасным техническим чеклистом, если бы в нем не было абзаца про «в первый день». Потому что, описанное автором, очень полезно и нужно, но делать это имхо, стоит после того как влился в команду и подхватил знамя культуры разработки
— Вы наделали суперулучшений вместо ценных фич, чем затормозили, возможно, горящую разработку. Кастомер посмотрел на это грустно и раззорился
Однажды я релизнул свое решение для отслеживание цен на ценные бумаги. И опубликовал об этом статью. Вечером того же дня (а это была пятница, ЧСХ), когда я опубликовал статью, релизнулась новая версия торговой платформы этого брокера, о чем сотрудник брокера сообщил в комментариях к моей статье. Причем так весело релизнулась, что обновление даже скачаться толком не могло.
…
Я сидел как на иголках, все думал, успею ли я за 60 часов форы стать миллионером, или нет. Не стал. Очень жаль, хотелось стать миллионером довольно сильно.
…
Серьёзно, кто-то еще верит, что фича, не доставленная в срок к конкретной дате, часу и минуте разорит кого-то?
Из-за одного опоздавшего релиза вряд ли, но если систематически продалбывать дедлайны, то полимеры просрать можно.
Фикс к торговой платформе, не доставленный в срок к конкретной дате, часу и минуте разорит кого-то. Например недавно были цены отрицательные на фьючерсы, многие торговые платформы не могли адекватно работать. Считать поддержку отрицательных цен фиксом или фичей еще вопрос.
Но и если сильно постараться можно и придумать про фичу. Например мы сейчас пилим торговую платформу, потому что та на которой работают наши трейдеры успешно загибается, а остальные не удовлетворяют условиям. У загибающеся платформы время от времени отваливаются фичи, и нам их нужно срочно добавить. Одно дело остановить торги по собственной воле когда на это есть время, а другое — если торги только у тебя остановились внезапно.
Но и если сильно постараться можно и придумать про фичу. Например мы сейчас пилим торговую платформу, потому что та на которой работают наши трейдеры успешно загибается, а остальные не удовлетворяют условиям. У загибающеся платформы время от времени отваливаются фичи, и нам их нужно срочно добавить. Одно дело остановить торги по собственной воле когда на это есть время, а другое — если торги только у тебя остановились внезапно.
О возможных отрицательных ценах было известно сильно заранее. То, что кто-то принял решение проигнорировать этот риск, это его решение и его ответственность. Не кодеров платформы.
Самое главное даже не про торговые платформы, а то, что ряд бирж (в т.ч. российские) тупо закрыл торговлю этими «отрицательно» стоящими активами, чем отправили всех прочих участников в убытки. Независимо от готовности платформ торговать производными по отрицательным ценам.
Самое главное даже не про торговые платформы, а то, что ряд бирж (в т.ч. российские) тупо закрыл торговлю этими «отрицательно» стоящими активами, чем отправили всех прочих участников в убытки. Независимо от готовности платформ торговать производными по отрицательным ценам.
О возможных отрицательных ценах было известно сильно заранее.А как вы храните цену в торговой платформе? У нас uint32_t в 1/1000 доллара. Но мы не торгуем фьючерсами и отрицательных цен все равно быть не может. При этом переполнение не так уж иллюзорно, не считая того что мелкие части цены мы все равно отбрасываем. Все в угоду производительности. (Я уже точно не помню, в некоторых местах минимальная цена 1/10 цента, а в некоторых еще меньше, но бизнес сказал что такая точность не нужна)
Но мой совет: если ваш проект не является npm-модулем, переведите сборку статики на webpack, так будет проще.
Все же мне кажется это довольно далеко от реальности. Т.е. это конечно подходит под ситуацию — «вы на новом проекте и вас там назначили главным», но в любой другой сутации вы просто наткнетесь на то, что народ уже работающий на проекте будет против.
Менять существующие процессы новому человеку никто в принципе не даст
Вы абсолютно правы от части, все будет проще если вы приходите на проект в качестве условного тим-лида. Но не забывайте, что всегда можно поговорить с коллегами и предложить им тот или иной инструмент. Согласятся — замечательно, нет — вы по крайней мере пытались.
«Условный тимлид» не человек с палкой власти, имхо
Это всего лишь координатор процесса разработки, который имеет достаточно экспертизы чтобы присматривать за проектом, его кодовой базой и работой людей в команде. Поэтому от того, кто предлагает супер-штуку, стажер или великий начальник, для самой команды мало что значит
Ну, кроме тех случаев, когда команда такая «ну, у нас есть начальство, будем работать как приказали». Имеет место быть, но это уже не про гибкость, плоскость и самоорганизацию, которые мне кажутся дефолтными вещами для здорового процесса разработки. Тут достаточно просто спустить сверху приказ использовать N и ничего не объянять
Люди разные, кому-то такая вертикаль власти как раз нравится
Это всего лишь координатор процесса разработки, который имеет достаточно экспертизы чтобы присматривать за проектом, его кодовой базой и работой людей в команде. Поэтому от того, кто предлагает супер-штуку, стажер или великий начальник, для самой команды мало что значит
Ну, кроме тех случаев, когда команда такая «ну, у нас есть начальство, будем работать как приказали». Имеет место быть, но это уже не про гибкость, плоскость и самоорганизацию, которые мне кажутся дефолтными вещами для здорового процесса разработки. Тут достаточно просто спустить сверху приказ использовать N и ничего не объянять
Люди разные, кому-то такая вертикаль власти как раз нравится
если вы приходите на проект в качестве условного тим-лида
Чисто личное наблюдение и личный опыт, но кажется прийдти в уже существующий и хоть сколько то здоровый проект сразу на позицию тимлида быть не должно. Тимлид — это про техническую экспертизу, понимание проекта, а также понимание команды — team в термине стоит не спроста. В первый день вы чисто физически не сможете понять, где баги, а где фичи. Что и почему сделано именно так, и как нужно это изменять. Да даже просто оценить, сколько времени нужно на эти изменения и насколько они приоритетны. Кроме того, вы ещё не знаете команду, не понимаете, как распределять задачи, кто в команде в чём силён, кому что стоит подтянуть. Поэтому в нормальной ситуации тимлиды растут из тех, кто пробыл в проекте какое-то время, а не нанимаются извне.
Не знаю почему все так недовольные вступлением — мне кажется вопрос отлично поставлен. Раз на собеседовании, значит теоретически, а значит можно и развернуться по полной.
Так что спасибо за отличный чеклист!
Что-то из-за неудачного вступления набросились на автора! Статья-то по содержанию явно полезная.
Представьте ситуацию, вы первый день на новом для вас проекте, с чего будете начинать? Опишите свои шаги.
Ответ на вопрос: прочитаю документацию.
Ответ на ситуацию: встану и уйду, потому что копаться в очередном желания нет. А постановка вопроса намекает.
Довольно хороший технический чек лист для стандартных проектов, которых конечно же большинство. Мне очень понравилось лирическое отступление, и я задумался как я бы ответил на такой вопрос, особенно после того как поработал над очень разными проектами. И пришел вот к чему, первым делом, я бы спросил насколько большой проект и сколько человек в нем учавствует, от этого бы строил дальнейшую схему. Например, в нашем проекте используется монорепо и в одну кодовую базу (около миллона строк кода) пушит одновременно 1000+ девелоперов из-за этого я в принципе не смог бы применить ваши рекоммендации, ибо пока я бы их только начинал продумывать все бы поменялось 10 раз в разных местах.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Как привести проект в чувство