Комментарии 17
Какое это имеет отношение к программированию? Половина из описанного — вообще забота сисадминов.
Что из этого забота сисадминов, как вам кажется?
Знаете ли вы, что именно нужно делать, когда система падает? Как добраться до бэкапов и восстановиться из них?. Извините, но это типовое админское развлечение.
Насчет конкретно бэкапов — ничего не могу возразить. Да, это больше по части админов. Но «что нужно делать, когда система падает» — этого лучше разработчиков уж точно никто знать не может. Все остальные пункты конкретно этого списка точно так же берут начало именно у разработчиков.
Разработчики не должны предусмотреть, что их систему еще нужно будет обновлять? Не должны были обеспечить простоту апгрейда и (в идеале) отсутствие даунтайма?
Разработчики не должны планировать релизы таким образом, чтобы обновления не ломали продакшн?
Не разработчики ли должны покрывать тестами то, что пишут? И не должны ли они обеспечивать удобство тестирования коллегам из QA?
Это я уже выше прокомментировал. Откуда админы должны знать, что нужно делать, если разработчики не знают?
Ну опять же, кто должен поддерживать окружение в консистентном состоянии, если не те люди, для которых это окружение, вообще создается?
Накат обновлений отнимает много времени и сил?
Разработчики не должны предусмотреть, что их систему еще нужно будет обновлять? Не должны были обеспечить простоту апгрейда и (в идеале) отсутствие даунтайма?
Система рушится даже от небольшого обновления?
Разработчики не должны планировать релизы таким образом, чтобы обновления не ломали продакшн?
Выкатывали ли вы когда-нибудь сломанный код на продакшн, причём это становилось известно только после жалоб пользователей?
Не разработчики ли должны покрывать тестами то, что пишут? И не должны ли они обеспечивать удобство тестирования коллегам из QA?
Знаете ли вы, что именно нужно делать, когда система падает? Как добраться до бэкапов и восстановиться из них?
Это я уже выше прокомментировал. Откуда админы должны знать, что нужно делать, если разработчики не знают?
Проводите ли вы больше времени за сменой окружений, повторных выполнений одних и тех же команд, запуска каких-то утилит – чем за самим написанием программ?
Ну опять же, кто должен поддерживать окружение в консистентном состоянии, если не те люди, для которых это окружение, вообще создается?
Программисты не выкатывают код в продакшен. Программисты не разбираются с упавшей системой. Точнее, разбираются, но post mortem. Первые меры принимают админы.
А вот историй, когда программисты не знали, что делать, а сисадмины знали я могу рассказать целый ворох. Начиная с внезапного «fd'шки закончились» (а что такое fd'шки?) и заканчивая весёлыми oom'ами, «странными тормозами» в районе свопа, кривой numa-топологией (привет монге) и т.д.
Мы сейчас плавно перейдём к теме девопса, но вот эти все задачи — они от админов, а дело программистов — писать код и миграции (фиксить баги и т.д.). Тестовые окружения, предпродакшены и т.д. — это уже админское.
А вот историй, когда программисты не знали, что делать, а сисадмины знали я могу рассказать целый ворох. Начиная с внезапного «fd'шки закончились» (а что такое fd'шки?) и заканчивая весёлыми oom'ами, «странными тормозами» в районе свопа, кривой numa-топологией (привет монге) и т.д.
Мы сейчас плавно перейдём к теме девопса, но вот эти все задачи — они от админов, а дело программистов — писать код и миграции (фиксить баги и т.д.). Тестовые окружения, предпродакшены и т.д. — это уже админское.
Выкатвают или не выкатывают программисты код в продакшн — вопрос достаточно многогранный. Равно как и вопрос, кто именно принимает первые меры на продакшоне. Все зависит желаемой скорости релизов. Достичь скорости хотя бы пары релизов в день без тесной интеграции работы админов/девелоперов — очень проблематично.
А за истории, когда программисты не знали что делать, а сисиадмины знали — пинка надо дать таким программистам. «fd-шки закончились» — из-за чего они закончились? Девелопер упорол косяк и решил, что файл можно и не закрывать? Или не поставил админов в известность о допустимых рамках нагрузки? Или админы были проинформированы, но внезапно на это забили? Или не забили, но не смогли в нужный момент предпринять какие-либо мероприятия, связанные со скейлингом, потому что программист пару недель назад (разрабатывая код) сказал: «Я же программист, я не хочу знать ни про какой скейлинг и fd-шки». Кто, вообще, тогда ему сказал, что он программист? Он не знает, что такое fd-шки и почему они заканчиваются. Он не знает, что такое OOM-killer и не понимает, к кому и когда тот приходит. Не знает как работает выделение памяти в linux'е и почему трещит swap… Это правда программист такой? Какую систему он может спроектировать, если не может даже обслужить уже готовую и запущенную систему?
А за истории, когда программисты не знали что делать, а сисиадмины знали — пинка надо дать таким программистам. «fd-шки закончились» — из-за чего они закончились? Девелопер упорол косяк и решил, что файл можно и не закрывать? Или не поставил админов в известность о допустимых рамках нагрузки? Или админы были проинформированы, но внезапно на это забили? Или не забили, но не смогли в нужный момент предпринять какие-либо мероприятия, связанные со скейлингом, потому что программист пару недель назад (разрабатывая код) сказал: «Я же программист, я не хочу знать ни про какой скейлинг и fd-шки». Кто, вообще, тогда ему сказал, что он программист? Он не знает, что такое fd-шки и почему они заканчиваются. Он не знает, что такое OOM-killer и не понимает, к кому и когда тот приходит. Не знает как работает выделение памяти в linux'е и почему трещит swap… Это правда программист такой? Какую систему он может спроектировать, если не может даже обслужить уже готовую и запущенную систему?
Да. Это крутейший программист-математик в вопросах многофакторной оптимизации с кучей слов, от малейшего приближения к которым у меня начинает сводить зубы статистикой. Это не мешает ему мучительно страдать над конфигом nginx'а на собственном маке при малейшей нужде отдать статику для веб-морды аналитической программы.
Я уверен, что 99% программистов, которые способны будут разобраться с нехваткой памяти, инод и тем, кто там за шестым сокетом четвёртый слушает, не поймут из его алгоритмов и 1%.
Для того разные профессии и нужны.
Я уверен, что 99% программистов, которые способны будут разобраться с нехваткой памяти, инод и тем, кто там за шестым сокетом четвёртый слушает, не поймут из его алгоритмов и 1%.
Для того разные профессии и нужны.
Примадонна? ;)
Плохой код постоянно создают, и, в конце концов, он умирает.
Всё это безусловно здорово, но поздно написанный хороший код вообще не увидит свет.
Про коммиты: первый признак неатомарного коммита — наличие союза «и» в сообщении.
Когда вы начинаете вводить сообщение и вдруг получается, что в сообщении будут запятые и союзы (перечисления), то задумайтесь — вам нужно разбить коммит на несколько (по числу перечислительных запятых и союзов).
Когда вы начинаете вводить сообщение и вдруг получается, что в сообщении будут запятые и союзы (перечисления), то задумайтесь — вам нужно разбить коммит на несколько (по числу перечислительных запятых и союзов).
Ещё важная вещь про коммиты:
Если это не open source, то пишите сообщения к коммитам на языке вашего начальства или заказчика, сообщение должно отвечать на вопрос «Что было сделано?». В первой строке должен быть ответ на этот вопрос, в последующих (теле сообщения) может быть объяснение причин и так далее. В тот момент, когда к вам придёт начальник и скажет «Заказчик хочет знать, что мы сделали за последние две недели», то вы с каменным лицом можете выполнить команду
Вывод: Правильное использование систем контроля версии значительно улучшает жизнь.
Если это не open source, то пишите сообщения к коммитам на языке вашего начальства или заказчика, сообщение должно отвечать на вопрос «Что было сделано?». В первой строке должен быть ответ на этот вопрос, в последующих (теле сообщения) может быть объяснение причин и так далее. В тот момент, когда к вам придёт начальник и скажет «Заказчик хочет знать, что мы сделали за последние две недели», то вы с каменным лицом можете выполнить команду
git log --no-merges --pretty=format:"%s" --since='2 weeks ago' (или похожую) и получить документ, требующий минимальной обработки напильником.Вывод: Правильное использование систем контроля версии значительно улучшает жизнь.
НЛО прилетело и опубликовало эту надпись здесь
или во время push-операции вы повредили файлы
Когда такое возможно? Какие файлы повреждаются?
7. Планируйте
А можно для тупых: о чем статья?
Ну правда, я ничего не понял…
Ну правда, я ничего не понял…
Спасибо, меня зацепило следующее: Ваши программы – это ваше наследие. Решайте сами, как долго оно будет существовать.
Потратил пару дней чтобы сделать для своего расширения Regex Tester поддержку Visual Studio 2015.
После уже задумался, а ведь скоро будет 5 лет как я написал этот плагин для VS2010. Время летит слишком быстро.
Потратил пару дней чтобы сделать для своего расширения Regex Tester поддержку Visual Studio 2015.
После уже задумался, а ведь скоро будет 5 лет как я написал этот плагин для VS2010. Время летит слишком быстро.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
7 правил написания программ, которые не умрут вместе с вами