Если бы меня спросили несколько лет назад, на какую позицию такие вопросы можно задавать, я бы выше мидла бы не назвал. А сейчас сениору задают - очевидно, сениор девальвировался.
1. Онбординг: не бояться спрашивать и просить помощи.
Да, но есть вещи, понимание которых предполагается по умолчанию. Как минимум, это всё то, что можно подчерпнуть из документации, как из публичной, так и внутреннего пространства проекта и компании.
2. Не стесняться дергать того, кто дал задачу.
Задача должна быть поставлена так, чтоб исполнитель, с учетом уровня вовлеченности и компетентности, мог решить ее самостоятельно. Конечно, это в зоне ответственности руководителя, но и доля ответственности исполнителя тут есть. Нужно или в моменте проанализировать задачу, и если показалось, что есть невнятные моменты, то взять время на более углубленное знакомство с последующей запланированной встречей, где исполнитель сможет провалидировать понимание. А "дергать" лишний раз не надо, про это тут уже много написано.
3. Код-ревью. Защищаться и получать выгоду.
А тут всё верно. "Не нравится" - это плохое замечание, нужна конкретика. Но бвает и так, что "не нравится" потому, что проще с нуля переписать, чем объективно критиковать PR, каждая строчка которого вызывает нервный тик и кровоточение глаз.
4. Сразу уделять большое внимание чистоте кода и архитектуры(уровень классов, сервисов и тд).
Чтоб принимать правильные архитектурные решения, нужно обладать достаточной компетентностью, иметь качественные требования и полную информацию о прочих разных аспектах окружения. Если чего-то из этого нет - лучше сделать максимально просто и покрыть тестами, скорее всего интеграционными, чтоб потом можно было отрефакторить, и обязательно заложить этот рефакторинг в план. Да, придется следить за техдолгом, придется продать рефакторинг менеджменту, но это все равно проще, чем прыгнуть выше своей компетентности и значительно проще, чем предсказать будущее.
Иными слрвами, код должен быть максимально прост, и он не должен опираться на неподтвержденную информацию.
5. Писать больше тестов сразу.
Тестов нужно писать столько, сколько нужно. ) Серьезно. Я видел ситуации, в которых одна и та же функциональность с разной реализацией имела количество тестов, отличающееся на порядок. Мидл наколбасил реализацию и более 100 тестов, сениор отрефакторил, задекомпозил, получил 4е класса вместо одного, для 3х написал простейшие юниты, для 4го, который зависел от предыдущих 3х, написал юнит на моках. Тестов стало около 15.
На моем последнем проекте именно так оно и было - процессы в BPMN отдельно, матрица принятия решений (не матрица, на самом деле это был движок правил, но суть та же), и что вы таки думаете? В конечном итоге всё стало неподъемно сложным.
Самая большая проблема программиста - это сложность. Все программисты в той или иной степени умеют с ней бороться. У них есть годы практики и инструментарий. Они понимают, какие действия могут привести к многократному росту сложности и как этого избежать или хотя бы минимизировать.
У аналитиков с визуальными редакторами с этим всё очень плохо. Поэтому да, можно выиграть на старте, но в перспективе тупик ближе, чем у программистов с кодом. Поэтому с рассуждениями типа "Сейчас мы дадим аналитику визуальный инструментарий и всё тут же завертится." нужно быть очень осторожным.
Говоря о программистах с кодом я не призывают, например, отказываться от BPMN движков или каких то других средств визуального проектирования. Я скорее за то, чтоб визуальное представление использовалось для контроля, а для разработки все таки код, например, в виде специализированного DSL.
Достаточно ли только питания на контроллере, или часть мероприятий выполняется по тычку со стороны материнской платы? У меня есть внешний SSD, он подключен по USB постоянно. Интересно, в той же самой степени он подвержен проблеме или там все ещё хуже?
Неверная аналогия. С кодом как раз наоборот - читать сложнее. Писать гораздо проще. Широко известен феномен, когда погромист не может прочитать свою собственную писанину.
За последние несколько лет я запилил десятки контроллеров. По итогу пришел как раз к примерно такой схеме - сервис, который обслуживает контроллер, всегда возвращает Either. Может, конечно и исключение бросить, но это всегда 500.
Сначала были исключения на все случаи, но потом оказалось, что нет надежного способа заставить в юнит тестах контроллеров из моков сервиса кидать те же исключения, что кидаются из настоящих.
Неудобно на этапе прототипа процесса пытаться писать покрывающие тесты.
Смотря как процесс тестирования организован. В моем мире с пони и бабочками процесс как маршрут тестируется отдельно, задачи - отдельно.
Проверять полноту тестов тоже не просто и не быстро.
Я даже не знаю, что ответить. А что быстро?
Может у вас другой опыт...
Мой опыт таков, что если тест можно написать - я пишу. Дешевле выйдет.
...но удобен способ обмена информацией между людьми, а не только между роботами
Вы так говорите, будто тест человек не сможет прочитать. Конечно, такие тесты бывают, но тут дело не в тесте, а в том, кто его написал. ИМХО, критерии качества кода теста не должны быть ниже, чем у продкода.
На моем текущем проекте пишем бизнес-процессы на DSL (Kotlin), правда, только для тестов. Мне нравится.
Для прода процессы пишут аналитики в своем отдельном приложении.
Предложение писать процессы на том же DSL и для прода у менеджмента восторга не вызвало. Это ж надо программистов нанимать, а они дорогие. А то, что аналитик, не будучи разработчиком, все равно делает работу разработчика, но хуже - это никого не волнует.
Чистый код — красивая архитектура. А работает ли это?
Да, работает, если на проекте трудятся люди, которые знают, что это такое и зачем оно нужно.
Если на проекте есть и другие люди - то их зону ответственности нужно изолировать таким образом, чтоб у них не было шансов нарушить общую архитектуру, чтоб их нечистый код был только их проблемой.
Хочется верить, дедлайны - это основная причина говнокода, но у меня на проекте это точно не так.
Проект начинался в режиме стартапа с очень ограниченными временными и трудовыми ресурсами. Мы работали быстро и делали много. Оценка задачам давалась с квантованием в 30 минут. Как уж тут без говнокода...
Прошло 11 лет. Народу на проекте стало больше. Начальство сменилось на разных уровнях более чем по 3 раза. Никто уже не требует былых темпов, да и не осталось никого из тех, кто помнит, как тут было принято работать раньше. Квантование оценки задачи - день. Ничего с нуля придумывать почти никогда не надо. Еще одна кнопка, еще одна форма, еще один HTTP API. Работа - не бей лежачего. Думаете, стало говнокода меньше? Нет. Только через code review и спасаемся.
79% респондентов указали, что основным барьером является нехватка времени из-за жёстких дедлайнов
Если бы опрос провели на моем проекте, я бы таким результатам не поверил. Люди пишут говнокод потому что или не могут отрефлексировать, или надеются, что code review будет выполнять не очень бдительный коллега.
С тех пор, как я стал зарабатывать больше, чем трачу, моя система такова: я знаю, какой у меня регулярный доход, знаю, сколько мне нужно денег на "обычную жизнь", т.е. на траты, которые у меня случаются каждый месяц, знаю, сколько у меня денег на счёте, что позволяет мне довольно точно прогнозировать состояние моего счета на месяцы вперёд.
Если подразумевалось, что тестировать стали не каждую функцию, а набор функций вместе, которые скрываются за той или иной формой интерфейса.
Наоборот. Декомпозировали, протестировали каждый новый компонент, плюс исходный компонент, который превратился в композицию из новых компонентов со радикально меньшей цикломатической и комбинаторной сложностью.
А вот были бы тест на контракт (рест эндпоинта, интерфейс, модуль), можно внутри сколь угодно менять модель.
Да, но чем дальше тестируемая абстракция от компонента, давшего сбой, тем больше шанс ввалить кучу времени на поиск причины сбоя.
Конечно, если само приложение компактное, условно - пара тысяч строк кода - оно и запустится быстро, и тестов много не будет - тогда можно вообще без юнит тестов обойтись, пока приложение не распухнет выше некого порога.
Еще бывает и так, что модель хорошая была и с хорошими тестами, но требования так поменялись, что большую часть переписывать нужно. И тут много маленьких тестов опять мешать будут.
Если колбасить нужно быстро, а требования нестабильны - то это совсем другое дело. Нужен не кристальный код, а одноразовое дендрофекальное поделие, единственное назначение которого - валидация требований, проверка гипотез, получение обратной связи и т.д.
Если бы меня спросили несколько лет назад, на какую позицию такие вопросы можно задавать, я бы выше мидла бы не назвал. А сейчас сениору задают - очевидно, сениор девальвировался.
Да, но есть вещи, понимание которых предполагается по умолчанию. Как минимум, это всё то, что можно подчерпнуть из документации, как из публичной, так и внутреннего пространства проекта и компании.
Задача должна быть поставлена так, чтоб исполнитель, с учетом уровня вовлеченности и компетентности, мог решить ее самостоятельно. Конечно, это в зоне ответственности руководителя, но и доля ответственности исполнителя тут есть. Нужно или в моменте проанализировать задачу, и если показалось, что есть невнятные моменты, то взять время на более углубленное знакомство с последующей запланированной встречей, где исполнитель сможет провалидировать понимание. А "дергать" лишний раз не надо, про это тут уже много написано.
А тут всё верно. "Не нравится" - это плохое замечание, нужна конкретика. Но бвает и так, что "не нравится" потому, что проще с нуля переписать, чем объективно критиковать PR, каждая строчка которого вызывает нервный тик и кровоточение глаз.
Чтоб принимать правильные архитектурные решения, нужно обладать достаточной компетентностью, иметь качественные требования и полную информацию о прочих разных аспектах окружения. Если чего-то из этого нет - лучше сделать максимально просто и покрыть тестами, скорее всего интеграционными, чтоб потом можно было отрефакторить, и обязательно заложить этот рефакторинг в план. Да, придется следить за техдолгом, придется продать рефакторинг менеджменту, но это все равно проще, чем прыгнуть выше своей компетентности и значительно проще, чем предсказать будущее.
Иными слрвами, код должен быть максимально прост, и он не должен опираться на неподтвержденную информацию.
Тестов нужно писать столько, сколько нужно. ) Серьезно. Я видел ситуации, в которых одна и та же функциональность с разной реализацией имела количество тестов, отличающееся на порядок. Мидл наколбасил реализацию и более 100 тестов, сениор отрефакторил, задекомпозил, получил 4е класса вместо одного, для 3х написал простейшие юниты, для 4го, который зависел от предыдущих 3х, написал юнит на моках. Тестов стало около 15.
Тесты - тоже код, а кода чем меньше - тем лучше.
На моем последнем проекте именно так оно и было - процессы в BPMN отдельно, матрица принятия решений (не матрица, на самом деле это был движок правил, но суть та же), и что вы таки думаете? В конечном итоге всё стало неподъемно сложным.
Самая большая проблема программиста - это сложность. Все программисты в той или иной степени умеют с ней бороться. У них есть годы практики и инструментарий. Они понимают, какие действия могут привести к многократному росту сложности и как этого избежать или хотя бы минимизировать.
У аналитиков с визуальными редакторами с этим всё очень плохо. Поэтому да, можно выиграть на старте, но в перспективе тупик ближе, чем у программистов с кодом. Поэтому с рассуждениями типа "Сейчас мы дадим аналитику визуальный инструментарий и всё тут же завертится." нужно быть очень осторожным.
Говоря о программистах с кодом я не призывают, например, отказываться от BPMN движков или каких то других средств визуального проектирования. Я скорее за то, чтоб визуальное представление использовалось для контроля, а для разработки все таки код, например, в виде специализированного DSL.
Оба сдохнут - и эмир, и ишак. Это мощный распил, не иначе.
Достаточно ли только питания на контроллере, или часть мероприятий выполняется по тычку со стороны материнской платы? У меня есть внешний SSD, он подключен по USB постоянно. Интересно, в той же самой степени он подвержен проблеме или там все ещё хуже?
Неверная аналогия. С кодом как раз наоборот - читать сложнее. Писать гораздо проще. Широко известен феномен, когда погромист не может прочитать свою собственную писанину.
А фиолетовым становится, если стукнуть?
И фендеров, фендеров еще накупите!
Занесло меня недавно почитать свои старые отзывы на товары в Яндекс Маркете, а там товары перепутаны. Ни на что не намекаю.
За последние несколько лет я запилил десятки контроллеров. По итогу пришел как раз к примерно такой схеме - сервис, который обслуживает контроллер, всегда возвращает Either. Может, конечно и исключение бросить, но это всегда 500.
Сначала были исключения на все случаи, но потом оказалось, что нет надежного способа заставить в юнит тестах контроллеров из моков сервиса кидать те же исключения, что кидаются из настоящих.
Слышал, что Россия продала много нефти Индии, причем за рупии. Индийская рупия не является СКВ. То есть потратить ее можно только в Индии.
Если это правда, то другого объяснения и не нужно.
Рабство отменили. Люди увольняются потому что могут.
инвестиция в слабое звено
Смотря как процесс тестирования организован. В моем мире с пони и бабочками процесс как маршрут тестируется отдельно, задачи - отдельно.
Я даже не знаю, что ответить. А что быстро?
Мой опыт таков, что если тест можно написать - я пишу. Дешевле выйдет.
Вы так говорите, будто тест человек не сможет прочитать. Конечно, такие тесты бывают, но тут дело не в тесте, а в том, кто его написал. ИМХО, критерии качества кода теста не должны быть ниже, чем у продкода.
Это должно отлавливаться тестами.
На моем текущем проекте пишем бизнес-процессы на DSL (Kotlin), правда, только для тестов. Мне нравится.
Для прода процессы пишут аналитики в своем отдельном приложении.
Предложение писать процессы на том же DSL и для прода у менеджмента восторга не вызвало. Это ж надо программистов нанимать, а они дорогие. А то, что аналитик, не будучи разработчиком, все равно делает работу разработчика, но хуже - это никого не волнует.
Да, работает, если на проекте трудятся люди, которые знают, что это такое и зачем оно нужно.
Если на проекте есть и другие люди - то их зону ответственности нужно изолировать таким образом, чтоб у них не было шансов нарушить общую архитектуру, чтоб их нечистый код был только их проблемой.
Хочется верить, дедлайны - это основная причина говнокода, но у меня на проекте это точно не так.
Проект начинался в режиме стартапа с очень ограниченными временными и трудовыми ресурсами. Мы работали быстро и делали много. Оценка задачам давалась с квантованием в 30 минут. Как уж тут без говнокода...
Прошло 11 лет. Народу на проекте стало больше. Начальство сменилось на разных уровнях более чем по 3 раза. Никто уже не требует былых темпов, да и не осталось никого из тех, кто помнит, как тут было принято работать раньше. Квантование оценки задачи - день. Ничего с нуля придумывать почти никогда не надо. Еще одна кнопка, еще одна форма, еще один HTTP API. Работа - не бей лежачего. Думаете, стало говнокода меньше? Нет. Только через code review и спасаемся.
Если бы опрос провели на моем проекте, я бы таким результатам не поверил. Люди пишут говнокод потому что или не могут отрефлексировать, или надеются, что code review будет выполнять не очень бдительный коллега.
С тех пор, как я стал зарабатывать больше, чем трачу, моя система такова: я знаю, какой у меня регулярный доход, знаю, сколько мне нужно денег на "обычную жизнь", т.е. на траты, которые у меня случаются каждый месяц, знаю, сколько у меня денег на счёте, что позволяет мне довольно точно прогнозировать состояние моего счета на месяцы вперёд.
Наоборот. Декомпозировали, протестировали каждый новый компонент, плюс исходный компонент, который превратился в композицию из новых компонентов со радикально меньшей цикломатической и комбинаторной сложностью.
Да, но чем дальше тестируемая абстракция от компонента, давшего сбой, тем больше шанс ввалить кучу времени на поиск причины сбоя.
Конечно, если само приложение компактное, условно - пара тысяч строк кода - оно и запустится быстро, и тестов много не будет - тогда можно вообще без юнит тестов обойтись, пока приложение не распухнет выше некого порога.
Если колбасить нужно быстро, а требования нестабильны - то это совсем другое дело. Нужен не кристальный код, а одноразовое дендрофекальное поделие, единственное назначение которого - валидация требований, проверка гипотез, получение обратной связи и т.д.