Comments 44
5. Сам уронил — сам поднял.
Снес половину базы? Восстанавливай!
6. Никаких микрооптимизаций и рефакторинга ДО окончании этапа основной разработки.
Или сразу пиши оптимальный код или выделяй время после окончания.
7. Новичок в проекте никогда и не при каких обстоятельствах не разобравшись во всей истории не должен произносить слов «А давайте это перепишем заново/на GO/ на Ruby/ на Java».
Я слышал, что Python/Go/Rust быстрее C#/Java/Python, давайте перепишем все!
8. Никогда не критикуй не разобравшись.
Может оказаться так, что стыдно будет тебе.
9. Никогда и не при каких обстоятельствах, не критикуй чужой стэк.
Только в курилке и только в формате уличной драки. Исключение — одинэсников можно.
Снес половину базы? Восстанавливай!
6. Никаких микрооптимизаций и рефакторинга ДО окончании этапа основной разработки.
Или сразу пиши оптимальный код или выделяй время после окончания.
7. Новичок в проекте никогда и не при каких обстоятельствах не разобравшись во всей истории не должен произносить слов «А давайте это перепишем заново/на GO/ на Ruby/ на Java».
Я слышал, что Python/Go/Rust быстрее C#/Java/Python, давайте перепишем все!
8. Никогда не критикуй не разобравшись.
Может оказаться так, что стыдно будет тебе.
9. Никогда и не при каких обстоятельствах, не критикуй чужой стэк.
Только в курилке и только в формате уличной драки. Исключение — одинэсников можно.
5. И… чем это должно помочь?)
…
7. Почему не должен? Деструктива это не несёт само по себе и непроизнесение этого ни от чего не защитит.
…
7. Почему не должен? Деструктива это не несёт само по себе и непроизнесение этого ни от чего не защитит.
Снес половину базы? Восстанавливай!
Дать ему доступы к бекапам? Приостановить бизнес, пока он со всем разберётся? А вы рисковый.
- Никогда не критикуй не разобравшись.
Может оказаться так, что стыдно будет тебе.- Никогда и не при каких обстоятельствах, не критикуй чужой стэк.
А вы на любите критику, это заметно )
пэхапэшников тоже можно!
Позвольте не согласиться по некоторым пунктам.
Число людей, у которых вообще есть доступ к тому, чтобы уронить БД, должен быть минимальным. А все sql update скрипты должны быть проверены перед исполнением на тест-среде.
Пусть подчеркивает очевидные проблемы, пока глаз не замылился. Бывает, что так долго варишься в своем проекте, что перестаешь обращать внимание на что-то. Но, конечно, большую часть предложений новичка придется отклонить по тем или иным причинам.
При ревью кода коллег не всегда есть время прям полностью вникать во все мелочи. Если не уверен, лучше прокомментировать/спросить. В худшем случае, тебе скажут, что не прав. В лучшем — поможет найти проблему. Даже если код корректен и ты сам неправильно что-то понял, такие замечания могут выявить места, которые лучше закомментировать или переписать более явно.
Но это все, конечно, варьируется от команде к команде.
Снес половину базы? Восстанавливай!
Число людей, у которых вообще есть доступ к тому, чтобы уронить БД, должен быть минимальным. А все sql update скрипты должны быть проверены перед исполнением на тест-среде.
Новичок… не должен произносить слов
Пусть подчеркивает очевидные проблемы, пока глаз не замылился. Бывает, что так долго варишься в своем проекте, что перестаешь обращать внимание на что-то. Но, конечно, большую часть предложений новичка придется отклонить по тем или иным причинам.
Никогда не критикуй не разобравшись.
При ревью кода коллег не всегда есть время прям полностью вникать во все мелочи. Если не уверен, лучше прокомментировать/спросить. В худшем случае, тебе скажут, что не прав. В лучшем — поможет найти проблему. Даже если код корректен и ты сам неправильно что-то понял, такие замечания могут выявить места, которые лучше закомментировать или переписать более явно.
Но это все, конечно, варьируется от команде к команде.
Снес половину базы? Восстанавливай!Зачем?
Никаких микрооптимизаций и рефакторинга ДО окончании этапа основной разработки.Микрооптимизации — может быть. Рефакторинг — почему бы и нет?
Никогда не критикуй не разобравшись.Это не только для разработки актуально.
Новичок в проекте никогда и не при каких обстоятельствах не разобравшись во всей истории не должен произносить слов «А давайте это перепишем заново/на GO/ на Ruby/ на Java».Да пусть произносит, какой вред-то от этого?
Рефакторинг — почему бы и нет?
Зависит от. Рефакторинг же тоже разный бывает. Серьезный обычно проводят, если есть очевидные проблемы при поддержке кода. А мелкий конечно можно и в процессе сделать. Главное — не искать идеальную архитектуру, тем более на ранцами это раннем этапе разработки, потому что в большинстве это пустая трата времени. Этим и опасно.
Python/Go/Rust быстрее C#/Java/Python
Это не опечатка?) Не думаю, что Python быстрее C#. Мб на его место можно поставить C/C++ или тот же Rust
— Мне сказали, что Python быстрее C#. — Это слова, мне на полном серьезе сказала новый руководитель ИТ-отдела очень крупной компании, я возразил и меня быстро перевели в другой отдел. Она еще была очень удивлена, после покупки кластера hadoop, что он не онлайн, она думала это что-то типа распределенной БД.
Кстати, вместо Python-а, она выбрала erlang.
Кстати, вместо Python-а, она выбрала erlang.
Смотря для какой задачи. Вполне может быть ситуация, когда решение из библиотечки python будет намного быстрее самописного решения на C#. За счёт того что сама библиотечка написана на C/C++/Cython
Быстрее для чего?
Разработки, развертывания или выбрасывания в мусор?
Разработки, развертывания или выбрасывания в мусор?
10. Нет тестов — нет фичи. Пока нет внятного покрытия тестами, фича в прод не уйдет.
Опять же зависит от конкретной ситуации. Вы же код не ради тестов и самого кода пишите (если конечно не свой проект). Обычно за это платят деньги и ожидают, что эти расходы как минимум окупятся. Если бизнесу надо как можно быстрее выпустить продукт/фичу и он в краткосрочной перспективе готов идти на риски из-за отсутствия тестов, но с условием, что в ближайшем спринте/итерации нас эти тесты выделят время, то почему бы и нет. В итоге все в выигрыше — и бизнес, который получил профит, и разработчики, потому что работа принесла максимум прибыли и в итоге покрыли все тестами.
Обычно так и делаем. Если надо «вот прям щас к демке», то выпускается и показывается с минимальными тестами. Но руководство знает, что при таком раскладе следующий спринт будет про тесты. У меня болезненный опыт в прошлом, когда тесты 5 лет подряд откладывалиссь на потом. Теперь я выторговываю точный срок, когда код будет покрыт тестами, если фича покажется полезной и пойдет в прод, после этого пилим фичу.
Проблема в том, что вы не планируете написание текстов. Договориться и реально запланировать в ближайший спринт — совершенно разные вещи) Вы не стоите на своем и не тыкаете бизнес в то, о чем с ним договаривались и о то, чего он не выполняет. Вы же написали код в срок? Написали, выполнив таким образом договор с бизнесом. А бизнес свою часть договора не выполнил, потому что должен вам тесты.
Но, в вашем случае, если бизнес не соблюдает своим же собственные обещания, лучше сразу писать код с тестами и оценку давать с учётом этого.
Что-то я не понял) А чего минусуем? Лучше пусть меньше заработаем, но зато сразу с тестами? Ну ок
3. Получите полную спецификацию перед началом разработки
Если бы это еще работало. Ни разу не сталкивался с ситуацией, чтобы к моменту начала разработки было полное и окончательное ТЗ. Даже если аналитик и/или заказчик считает, что всё продумано и описано, обязательно в процессе реализации всплывёт что-нибудь еще.
Я бы перефразировал этот пункт так: "Получите наиболее исчерпывающую спецификацию ..". Естественно, все предусмотреть на раннем этапе невозможно, но попытаться покрыть риски по максимуму — вполне.
Отвечу вам как аналитик.
Хотел подробно, но после третьей стёртой простыни понял что такое лучше в личку :)
1. Если требования готовить заранее, они устаревают или замыливается глаз. Поэтому детализацию необходимо повышать итерационно.
2. Можно проводить ревью требований, но к такому не готов ни один участник процесса: у заказчика нет времени, разработчикам необходимо отдельно сесть подумать, ПМ/другой аналитик имеет ещё достаточно много дел. В нашей команде если грядёт большая фича мы после выявления достаточно полного набора требований садимся и обсуждаем реализацию.
3. Если готовить требования по мере востребованности (вечером на митинге обсудили что будет сделано завтра), обеспечивая актуальность, получится очень много TBD пунктов.
Краткий вывод: полное и окончательное ТЗ физически невозможно на сложную систему. Даже одноатомные молекулы и те с допусками. Метрологией, ITIL, процессами управления разработки или иной борьбой со сложностью можно найти нужный баланс между полнотой и оперативностью уточнения.
Вывод: требованиями необходимо управлять так же, как бэклогом, баглистом, сроками и прочим. Команда может прожить без компетентного архитектора/аналитика/тестера/etc. Но зачем?
Хотел подробно, но после третьей стёртой простыни понял что такое лучше в личку :)
1. Если требования готовить заранее, они устаревают или замыливается глаз. Поэтому детализацию необходимо повышать итерационно.
2. Можно проводить ревью требований, но к такому не готов ни один участник процесса: у заказчика нет времени, разработчикам необходимо отдельно сесть подумать, ПМ/другой аналитик имеет ещё достаточно много дел. В нашей команде если грядёт большая фича мы после выявления достаточно полного набора требований садимся и обсуждаем реализацию.
3. Если готовить требования по мере востребованности (вечером на митинге обсудили что будет сделано завтра), обеспечивая актуальность, получится очень много TBD пунктов.
Краткий вывод: полное и окончательное ТЗ физически невозможно на сложную систему. Даже одноатомные молекулы и те с допусками. Метрологией, ITIL, процессами управления разработки или иной борьбой со сложностью можно найти нужный баланс между полнотой и оперативностью уточнения.
Вывод: требованиями необходимо управлять так же, как бэклогом, баглистом, сроками и прочим. Команда может прожить без компетентного архитектора/аналитика/тестера/etc. Но зачем?
Менеджер проекта обычно. Но можем и силами команды спокойно всё организовать. Главное отделить встречу про техническую реализацию (проводимую без заказчика) от встречи про потребности и видение (такие встречи и с командой, и с заказчиком иногда проводятся для обеспечения взаимопонимания, контроля работы аналитика и успокоения заказчика).
Совместная оценка трудозатрат с разработчиками на основании выявленных требований и известном техдолге. Например, у текущей фичи оценки были в 2-4 месяца, пока укладываемся и, похоже, уложимся. Могу разработчика призвать, прокомментирует :)
Решил ПМ. Почему — в идеале надо у него спрашивать.
Как видится мне: нам необходимо добавить новый функционал, предполагающий новый подход работы с системой. Для того, чтобы это сделать, необходимо его аккуратно положить на старые рельсы и архитектуру как минимум ничего не сломав, как максимум по пути разгрести частично имеющийся техдолг (система осталась в наследство от другой группы разработки и создавалась как прототип). Я не знаю имеющихся архитектурных ограничений и не в моей компетенции определять детали реализации, этим занимаются разработчики, и сроки или глубину декомпозиции задач, этим занимается ПМ. Таким образом, на момент до обсуждения (в котором оценка трудозатрат лишь малая часть), информация и экспертиза размазана по отдельным лицам в команде, после — имеется у всей команды.
Наверное, в практике или теории проектного управления есть рекомендации когда необходимо проводить такие обсуждения, что на них должно быть и т.д. Я же могу оттолкнуться только от своей оценки по количеству затрагиваемых пользовательских сценариев и практики работы команды. С этой точки зрения фича достаточно большая, т.к. затрагивает минимум 5 сценариев (это так, с ходу) и на реализацию сравнимого функционала у команды (два разработчика, тестировщик и аналитик) ушло два месяца в прошлый раз.
Как видится мне: нам необходимо добавить новый функционал, предполагающий новый подход работы с системой. Для того, чтобы это сделать, необходимо его аккуратно положить на старые рельсы и архитектуру как минимум ничего не сломав, как максимум по пути разгрести частично имеющийся техдолг (система осталась в наследство от другой группы разработки и создавалась как прототип). Я не знаю имеющихся архитектурных ограничений и не в моей компетенции определять детали реализации, этим занимаются разработчики, и сроки или глубину декомпозиции задач, этим занимается ПМ. Таким образом, на момент до обсуждения (в котором оценка трудозатрат лишь малая часть), информация и экспертиза размазана по отдельным лицам в команде, после — имеется у всей команды.
Наверное, в практике или теории проектного управления есть рекомендации когда необходимо проводить такие обсуждения, что на них должно быть и т.д. Я же могу оттолкнуться только от своей оценки по количеству затрагиваемых пользовательских сценариев и практики работы команды. С этой точки зрения фича достаточно большая, т.к. затрагивает минимум 5 сценариев (это так, с ходу) и на реализацию сравнимого функционала у команды (два разработчика, тестировщик и аналитик) ушло два месяца в прошлый раз.
Как раз выкатили обновление в прод, открыл хабр и тут эта статья. Думаю, тут таких много.
Но в целом, согласен, что это не лучшая дата для обновлений.
Но в целом, согласен, что это не лучшая дата для обновлений.
Я бы посмотрел в сторону zero downtime deployment. Конечно, многое зависит от конкретных условий/технологий и проекта и может быть не везде применим, но подход очень полезный и позволяет деплоить даже под нагрузкой. Вот тут хорошо описано https://uwsgi-docs.readthedocs.io/en/latest/articles/TheArtOfGracefulReloading.html касательно питона, но в общем применимо и для других языков и технологий
Наше время… почти так же ценно как те 3-8 часов, которые мы проводим без сознания каждую ночь...Как можно не догадаться что не стоит ожидать под таким заголовком увидеть реально полезный текст. Да еще каменты эти читать потом…
Вобщем «Ты Сам Себе Делаешь Свой Недосып»
Но однажды, как я сегодня, вы захотите вернуться в прошлое и выяснить, когда именно мы сделали эту незаметную, но совершенно убийственную ошибку, которую никто до сих пор не замечал?!
И выяснится что бэкап умер, по-этому есть пункт 2.2 — регулярно проверять эти самые регулярно сделанные бэкапы.
=) У нас, как то, при разворачивании бэкапа выяснилось, что он битый. И прошлый битый. И все битые. И бой бит.
Откатились на тестовый сервер, где программисты три недели делали что хотели и как хотели…
И бурно имитировали деятельность за три недели в течении всех выходных.
Ваша правда, короче… бэкапы надо проверять.
Откатились на тестовый сервер, где программисты три недели делали что хотели и как хотели…
И бурно имитировали деятельность за три недели в течении всех выходных.
Ваша правда, короче… бэкапы надо проверять.
Прочитал как
Вся наша индустрия построена на абстрактной системе прогрессивного факапаи прослезился…
del
> см. также «Дзен и искусство обслуживания мотоциклов»
Сижу читаю… Эта штука посильнееФауста Гёте Гарри Поттера и методов рационального мышления.
Сижу читаю… Эта штука посильнее
Расскажу сказочку про деплои в пятницу:
В прошлую пятницу разработчики из Google решили, что фильтры для поиска на YouTube не нужны. Во вторник они сообщили, что в курсе проблемы и пофиксят ее… Прошла неделя, весь бизнес завязанный на ютуб, занимающихся аналитикой — встал. Спасибо гугл ¯\_(ツ)_/¯
В прошлую пятницу разработчики из Google решили, что фильтры для поиска на YouTube не нужны. Во вторник они сообщили, что в курсе проблемы и пофиксят ее… Прошла неделя, весь бизнес завязанный на ютуб, занимающихся аналитикой — встал. Спасибо гугл ¯\_(ツ)_/¯
Т.е. если бы они выкатили обновление в понедельник, такого бы не случилось?
Можно много говорить, про то, какие мы все ответственные и профессионалы, но про пятницу, это из системного администрирования, потому что, если что то пойдет не так, придется сидеть и исправлять все выходные, причем за бесплатно, руководство не оценит и есть вероятность еще и штраф получить, а вот если что то пойдет не так на рабочей неделе, то скорее всего будет премия за героическое преодолевание трудностей и возвращение работоспособности системы.
Можно много говорить, про то, какие мы все ответственные и профессионалы, но про пятницу, это из системного администрирования, потому что, если что то пойдет не так, придется сидеть и исправлять все выходные, причем за бесплатно, руководство не оценит и есть вероятность еще и штраф получить, а вот если что то пойдет не так на рабочей неделе, то скорее всего будет премия за героическое преодолевание трудностей и возвращение работоспособности системы.
Sign up to leave a comment.
«Никаких деплоев в пятницу» и ещё три негласных правила разработки