Проблема в том, что вы не планируете написание текстов. Договориться и реально запланировать в ближайший спринт — совершенно разные вещи) Вы не стоите на своем и не тыкаете бизнес в то, о чем с ним договаривались и о то, чего он не выполняет. Вы же написали код в срок? Написали, выполнив таким образом договор с бизнесом. А бизнес свою часть договора не выполнил, потому что должен вам тесты.
Я бы посмотрел в сторону zero downtime deployment. Конечно, многое зависит от конкретных условий/технологий и проекта и может быть не везде применим, но подход очень полезный и позволяет деплоить даже под нагрузкой. Вот тут хорошо описано https://uwsgi-docs.readthedocs.io/en/latest/articles/TheArtOfGracefulReloading.html касательно питона, но в общем применимо и для других языков и технологий
Я бы перефразировал этот пункт так: "Получите наиболее исчерпывающую спецификацию ..". Естественно, все предусмотреть на раннем этапе невозможно, но попытаться покрыть риски по максимуму — вполне.
Опять же зависит от конкретной ситуации. Вы же код не ради тестов и самого кода пишите (если конечно не свой проект). Обычно за это платят деньги и ожидают, что эти расходы как минимум окупятся. Если бизнесу надо как можно быстрее выпустить продукт/фичу и он в краткосрочной перспективе готов идти на риски из-за отсутствия тестов, но с условием, что в ближайшем спринте/итерации нас эти тесты выделят время, то почему бы и нет. В итоге все в выигрыше — и бизнес, который получил профит, и разработчики, потому что работа принесла максимум прибыли и в итоге покрыли все тестами.
Зависит от. Рефакторинг же тоже разный бывает. Серьезный обычно проводят, если есть очевидные проблемы при поддержке кода. А мелкий конечно можно и в процессе сделать. Главное — не искать идеальную архитектуру, тем более на ранцами это раннем этапе разработки, потому что в большинстве это пустая трата времени. Этим и опасно.
Вам следовало планировать день так, чтобы работы делать с учётом отвлеканий. Отвлекания и помощь коллегам — это тоже работа и она не должна идти как свободное время)
)) вот представляю уже, как ребенок бегает по музею со словами "Папа, папа, смотри какая картина! Что это, расскажи?" А папа, уткнувшись а телефон: "Не сейчас, у меня важное сообщение, на которое надо ответить". С вашего позволения, это не отдых, а ерунда. Лучше сделать полноценный выходной, чем ни то, ни се. Выше правильно написали, что это не 4-х дневная неделя, а только название от нее. Просто компания захотела попиариться
Мне кажется, чем попытаться выражаться критериями, значение которых не до конца понимаешь, лучше написать человеческим языком, чтобы всем понятно было) К примеру, эксперимент проходили 100 человек в течение года.
Не видел, значит не бывает?) Ну а у меня было) Ну и опять же, это ни о чем не говорит. На моём опыте так же было, что раз можно написать комментарии к каждому блоку, чё не запихнуть все эти блоки в одну большую функцию. Зато всё ясно и понятно, да и в одни месте. Так что в некоторых случаях вместо декомпозиции и рефакторинга предпочитают комментарии
Я об этом и написал, это как раз 1 случай, когда код нуждается в рефакторинге.
> как пример, комментарий нужен для предостережения следующего инженера от упрощения какого-то куска кода — с детальным описанием, почему не сделано просто.
Такие случаи конечно имеют место быть и там комментарии необходимы. Но если ваш код сплошь и рядом состоит из таких кусков кода, то это либо какой-то специфический проект, в котором иначе никак, и без комментариев вообще непонятно, как оно работает, либо вы реально что-то делаете не так, если ваш код сплошь настолько сложный, что без комментариев в нем не разобраться.
> кодбэйз гугла, например, полон комментариев. разумеется, нужна дисциплина, поддерживать комментарии в актуальном состоянии.
Кодбейз гугла разрабатывается уже не первый десяток лет, разрабатывают его инженеры с разным уровнем опыта и скорее всего там достаточно легаси, закладок на обратную совместимость, нестандартную оптимизацию и прочее. Никто не спорит, что если такие вещи явно не описать комментариями, то там все легко сломать.
Но мы ж про простой код говорим) И про среднестатистические проекты, где таких мест, как правило, не очень много. Я хочу быть понятым правильно, я не против комментариев там, где без них реально не обойтись. Я против комментариев, которые представляются, как возможность описать код, который нужно переписать. Если код нельзя переписать, конечно пишите комментарий. Но, повторюсь, в моей практике таких случаев было не так уж и много, хотя они и были.
Есть красивая теория, о том, что хорошо написанный код в комментариях не нуждается.
Есть не менее замечательная теория о том, что комментарии — всемогущее средство, если код непонятен. Увы, по опыту, это только теория. Комментарии обычно живут в отрыве от кода и при его изменении их часто просто забывают поправить. В итоге комментарий описывает не то, что уже представляет код, и является, скорее, вредным, чем полезным. Хорошо написанный код и правда не нуждается в комментариях. На моей практике было очень мало реальных случаев, когда без комментариев прям совсем не обойтись. А если хочется написать комментарий к коду, который непонятен, то тут 2 варианта. Первый — код просто нуждается в рефакторинге и тут комментарий, ИТ как мёртвому припарка. Второй — сложная бизнес-логика, которую иначе не описать, кроме как снабдив сопровождающими описаниями. Заметьте, я сейчас не про докстринги, описывающие сигнатуры методов, а именно про комментарии в непонятном коде.
Питон — внезапно, язык с изначальной обязательной типизацией) Просто она динамическая, а не статическая. Ну и никто не мешает вам объявить тип с помощью аннотации. Да, оно не будет работать в рантайме, но подразумевается, что если вы используете тайпчекер и аннотации, до рантайма такие ошибки не дойдут.
Если же вам нужна именно статическая типизация, то тут просто нужно использовать другой язык, а не жаловаться, что в питон не завезли статику. Ну не будет ее там, поймите уже, это как раз одно из преимуществ языка. Он так спроектирован.
Я бы посмотрел в сторону zero downtime deployment. Конечно, многое зависит от конкретных условий/технологий и проекта и может быть не везде применим, но подход очень полезный и позволяет деплоить даже под нагрузкой. Вот тут хорошо описано https://uwsgi-docs.readthedocs.io/en/latest/articles/TheArtOfGracefulReloading.html касательно питона, но в общем применимо и для других языков и технологий
Я бы перефразировал этот пункт так: "Получите наиболее исчерпывающую спецификацию ..". Естественно, все предусмотреть на раннем этапе невозможно, но попытаться покрыть риски по максимуму — вполне.
Опять же зависит от конкретной ситуации. Вы же код не ради тестов и самого кода пишите (если конечно не свой проект). Обычно за это платят деньги и ожидают, что эти расходы как минимум окупятся. Если бизнесу надо как можно быстрее выпустить продукт/фичу и он в краткосрочной перспективе готов идти на риски из-за отсутствия тестов, но с условием, что в ближайшем спринте/итерации нас эти тесты выделят время, то почему бы и нет. В итоге все в выигрыше — и бизнес, который получил профит, и разработчики, потому что работа принесла максимум прибыли и в итоге покрыли все тестами.
Зависит от. Рефакторинг же тоже разный бывает. Серьезный обычно проводят, если есть очевидные проблемы при поддержке кода. А мелкий конечно можно и в процессе сделать. Главное — не искать идеальную архитектуру, тем более на ранцами это раннем этапе разработки, потому что в большинстве это пустая трата времени. Этим и опасно.
Я думаю, там такие же "полдня", как тут "4-х дневная" рабочая неделя) Вот и ответ на ваш вопрос)
Очевидно, что это самопиар и ничего более. Какая уж тут 4х дневная рабочая неделя
А, так вы про работу дома? Тогда, согласен полностью. Та же проблема была)
Вам следовало планировать день так, чтобы работы делать с учётом отвлеканий. Отвлекания и помощь коллегам — это тоже работа и она не должна идти как свободное время)
Мне больше интересно, что будет, если в эти 10 дней случится ЧП ))
Долгожданный отпуск вероятно))
)) вот представляю уже, как ребенок бегает по музею со словами "Папа, папа, смотри какая картина! Что это, расскажи?" А папа, уткнувшись а телефон: "Не сейчас, у меня важное сообщение, на которое надо ответить". С вашего позволения, это не отдых, а ерунда. Лучше сделать полноценный выходной, чем ни то, ни се. Выше правильно написали, что это не 4-х дневная неделя, а только название от нее. Просто компания захотела попиариться
Мне кажется, чем попытаться выражаться критериями, значение которых не до конца понимаешь, лучше написать человеческим языком, чтобы всем понятно было) К примеру, эксперимент проходили 100 человек в течение года.
Лучше для этого развивать дисциплину и чистоплотность) А то ведь, не ровен час, и на все остальные папки и устройства такой подход расползется
Не видел, значит не бывает?) Ну а у меня было) Ну и опять же, это ни о чем не говорит. На моём опыте так же было, что раз можно написать комментарии к каждому блоку, чё не запихнуть все эти блоки в одну большую функцию. Зато всё ясно и понятно, да и в одни месте. Так что в некоторых случаях вместо декомпозиции и рефакторинга предпочитают комментарии
Я об этом и написал, это как раз 1 случай, когда код нуждается в рефакторинге.
> как пример, комментарий нужен для предостережения следующего инженера от упрощения какого-то куска кода — с детальным описанием, почему не сделано просто.
Такие случаи конечно имеют место быть и там комментарии необходимы. Но если ваш код сплошь и рядом состоит из таких кусков кода, то это либо какой-то специфический проект, в котором иначе никак, и без комментариев вообще непонятно, как оно работает, либо вы реально что-то делаете не так, если ваш код сплошь настолько сложный, что без комментариев в нем не разобраться.
> кодбэйз гугла, например, полон комментариев. разумеется, нужна дисциплина, поддерживать комментарии в актуальном состоянии.
Кодбейз гугла разрабатывается уже не первый десяток лет, разрабатывают его инженеры с разным уровнем опыта и скорее всего там достаточно легаси, закладок на обратную совместимость, нестандартную оптимизацию и прочее. Никто не спорит, что если такие вещи явно не описать комментариями, то там все легко сломать.
Но мы ж про простой код говорим) И про среднестатистические проекты, где таких мест, как правило, не очень много. Я хочу быть понятым правильно, я не против комментариев там, где без них реально не обойтись. Я против комментариев, которые представляются, как возможность описать код, который нужно переписать. Если код нельзя переписать, конечно пишите комментарий. Но, повторюсь, в моей практике таких случаев было не так уж и много, хотя они и были.
Есть не менее замечательная теория о том, что комментарии — всемогущее средство, если код непонятен. Увы, по опыту, это только теория. Комментарии обычно живут в отрыве от кода и при его изменении их часто просто забывают поправить. В итоге комментарий описывает не то, что уже представляет код, и является, скорее, вредным, чем полезным. Хорошо написанный код и правда не нуждается в комментариях. На моей практике было очень мало реальных случаев, когда без комментариев прям совсем не обойтись. А если хочется написать комментарий к коду, который непонятен, то тут 2 варианта. Первый — код просто нуждается в рефакторинге и тут комментарий, ИТ как мёртвому припарка. Второй — сложная бизнес-логика, которую иначе не описать, кроме как снабдив сопровождающими описаниями. Заметьте, я сейчас не про докстринги, описывающие сигнатуры методов, а именно про комментарии в непонятном коде.
Ну конечно, вы ещё сомневаетесь?))
Питон — внезапно, язык с изначальной обязательной типизацией) Просто она динамическая, а не статическая. Ну и никто не мешает вам объявить тип с помощью аннотации. Да, оно не будет работать в рантайме, но подразумевается, что если вы используете тайпчекер и аннотации, до рантайма такие ошибки не дойдут.
Если же вам нужна именно статическая типизация, то тут просто нужно использовать другой язык, а не жаловаться, что в питон не завезли статику. Ну не будет ее там, поймите уже, это как раз одно из преимуществ языка. Он так спроектирован.