Комментарии 104
Остался только вопрос — а при чём тут Россия?
Я за свои 10+ лет работы на серьезную компанию в США своими глазами видел наборы очень похожих историй. Кровавый энтерпрайз везде одинаковый вообще. И аджайл там тоже внедряют так, что в цирке потом никто не смеется.
Я за свои 10+ лет работы на серьезную компанию в США своими глазами видел наборы очень похожих историй. Кровавый энтерпрайз везде одинаковый вообще. И аджайл там тоже внедряют так, что в цирке потом никто не смеется.
Вы правы, Россия в этом смысле не уникальна. И в том-то и дело, что следуя за мировыми трендами, зачастую с некоторой задержкой, никто не утруждает себя тем, чтобы взглянуть по сторонам и принять во внимание опыт тех компаний, которые уже прошли этот путь и набили шишки.
Почти уверен, что такие поведенческие паттерны свойственны и США и Европе, но мы живем и работаем в России.
Почти уверен, что такие поведенческие паттерны свойственны и США и Европе, но мы живем и работаем в России.
Так это русская национальная привычка такая. Начинать с «Только в России...», а после указания на то, что в других странах тоже не всегда хорошо, лучшая отмазка «Я живу в России, меня волнует Россия».
clickbait
НЛО прилетело и опубликовало эту надпись здесь
Внезапно заказчик решил потребовать выдать ему исходный код. Как оказалось, у их имеющегося подрядчика были планы на то, что они проведут разработку софта, а потом будут продавать результат как SaaS по рынку. В договоре про код ничего не сказано.Я помню, нам в универе говорили, что в России по какому-то там госту-шмосту (ссылку не дам, не помню) при заказной разработке ПО исполнитель обязан передать заказчику исходники по умолчанию. И как по мне, это абсолютно правильно.
А что делать, если я прямо в машинных кодах пишу? Распечатка хекс-кодов за исходники сойдут?
НЛО прилетело и опубликовало эту надпись здесь
Мы тут обсуждаем случай когда в договоре не прописана обязанность передавать исходники.
Правомерно ли тогда требование заказчика предоставить исходные тексты ссылаясь на законы РФ? И может ли исполнитель отказать, говоря что он руками байты в екзешник пишет?
Правомерно ли тогда требование заказчика предоставить исходные тексты ссылаясь на законы РФ? И может ли исполнитель отказать, говоря что он руками байты в екзешник пишет?
Если он и правда руками байты пишет, то должен выдать экзешник, как исходник. Другое дело, что если он не руками байты пишет, то это обман заказчика и преследуется уже по другой статье (ну или ректальным криптоанализом, если в людях ошибся).
НЛО прилетело и опубликовало эту надпись здесь
Речь, видимо, об этом:
Вот вопрос на форуме:
«Компания разработала программу для ЭВМ на основании договора, по условиям которого заказчику передается исключительное право на эту программу. Обязана ли компания-разработчик передавать исходный код на программу? Ситуация 1: в договоре про передачу исходного кода ничего не указано.»
Ответ
«Да, обязана. В противном случае приобретатель не сможет реализовать свое право на модификацию программы (пп. 9 п. 2 ст. 1270 ГК РФ). Получится, что компания-разработчик передала только часть прав на программу, что не соответствует положениям ст. 1285 ГК Р. Ф. По договору об отчуждении исключительного права на произведение автор или иной правообладатель передает или обязуется передать принадлежащее ему исключительное право на произведение в полном объеме приобретателю такого права.»
НЛО прилетело и опубликовало эту надпись здесь
Абсолютно любой носитель сойдёт. Даже распечатка хекс-кодов. Вы главное передайте.
Меня как-то раз просили сдать в архив распечатанный дамп базы. Вот прямо в бинарном виде. База была средненькая, гигов на 100. Но архивариуса вполне устроили 50 листов распечатанной абракадабры.
Вместо организации подлога нужно было просто написать служебку следующего характера:
Дамп базы = 100 000 000 000 знаков. Ну ладно, сжалимся и сожмём до 30% от исходного. 30 000 000 000.
Лист А4 = 1 800 знаков.
Получается 17 млн страниц. Допустим напечатали с двух сторон. 8.5 млн листов. Каждые 500 листов весят 2.5 кг. 42 тонны бумаги.
Необходимо было попросить архивариуса во исполнение требований выделить железнодорожный контейнер, способный хранить 42т бумаги с учетом температуры и влажности.
Затем отправить очередную служебку завхозу или кто-там ведает закупками, что для распечатки 17млн страниц потребуется перезаправить лазерный принтер с ёмкостью тонера 10,000 страниц и, скажем, барабана 50 000 страниц (дорогой же принтер?). Необходимо запросить бюджет. В т.ч. выделить грузчиков с тележками для заполнения ж/д контейнера по мере распечатки.
ЛИБО, милостиво предложите, как альтернатива, купить флешку за $50.
Думаю, архивариус был бы счастлив принять правильное решение, а Вам не пришлось бы подставляться :-)
Дамп базы = 100 000 000 000 знаков. Ну ладно, сжалимся и сожмём до 30% от исходного. 30 000 000 000.
Лист А4 = 1 800 знаков.
Получается 17 млн страниц. Допустим напечатали с двух сторон. 8.5 млн листов. Каждые 500 листов весят 2.5 кг. 42 тонны бумаги.
Необходимо было попросить архивариуса во исполнение требований выделить железнодорожный контейнер, способный хранить 42т бумаги с учетом температуры и влажности.
Затем отправить очередную служебку завхозу или кто-там ведает закупками, что для распечатки 17млн страниц потребуется перезаправить лазерный принтер с ёмкостью тонера 10,000 страниц и, скажем, барабана 50 000 страниц (дорогой же принтер?). Необходимо запросить бюджет. В т.ч. выделить грузчиков с тележками для заполнения ж/д контейнера по мере распечатки.
ЛИБО, милостиво предложите, как альтернатива, купить флешку за $50.
Думаю, архивариус был бы счастлив принять правильное решение, а Вам не пришлось бы подставляться :-)
Была подобная мысль, начальник отговорила. Вот как раз 50 листов с устным пояснением, что это < 1% от целевого результата убедили архивариуса, что не стоит доводить начатое до конца.
Но ей надо что-то предоставить в случае ревизии? У нее регламент. Пришлось идти «на подлог».
Это было в те прекрасные времена, когда каждое «электронное письмо», даже если это вообще не письмо, а передача файлов по шифрованной сети, требовалось распечатывать и сдавать в архив вместе с вложениями. Со временем нормативные документы переделали.
Но ей надо что-то предоставить в случае ревизии? У нее регламент. Пришлось идти «на подлог».
Это было в те прекрасные времена, когда каждое «электронное письмо», даже если это вообще не письмо, а передача файлов по шифрованной сети, требовалось распечатывать и сдавать в архив вместе с вложениями. Со временем нормативные документы переделали.
Конечно, это и есть исходный код.
НЛО прилетело и опубликовало эту надпись здесь
в ГОСТ 19.401-78. ЕСПД допускается:
Если кратко, да сойдут. Но это, если в договоре указано обязательное исполнение ГОСТ. А так могут что угодно прописать, хоть на камне высечь, если не расходится с действующим законодательством
символическая запись на исходном языке;
символическая запись па промежуточных языках;
символическое представление машинных кодов и т. п
Если кратко, да сойдут. Но это, если в договоре указано обязательное исполнение ГОСТ. А так могут что угодно прописать, хоть на камне высечь, если не расходится с действующим законодательством
Сейчас передавать исходники… этого мало, очень мало! Нужны ещё инструкции по компиляции и сборке, а так же по внутренней модели данных и базу с системными настройками. Исходники — ничто, если нет базы. База без магических настроек — ничто…
Infrastructure as code, Configuration as code…
Под СКВ должно находиться всё необходимое для развёртывания приложения в любом окружении с нуля, после клонирования. Не знаю насчёт передачи кодов и ГОСТов, по мне это современный, и единственно разумный подход.
Благо инструментарий для поддержки такой концепции очень активно развивается последние годы.
Под СКВ должно находиться всё необходимое для развёртывания приложения в любом окружении с нуля, после клонирования. Не знаю насчёт передачи кодов и ГОСТов, по мне это современный, и единственно разумный подход.
Благо инструментарий для поддержки такой концепции очень активно развивается последние годы.
Ну вот сделает вам подрядчик проект с teamcity DSL прямо в коде. Где все настроено просто отлично, с автотестами, с автоматическом разворачивании тестовых окружений в облаке и так далее.
Но вот у вашей компании лицензии на тимсити нет, аккаунты у вас в AWS а не гугл клауд — надо сильно переделывать, и вообще в Котлине, на котором Teamcity хранит свои настройки никто не разбирается, потому что проект на Nodejs, и что вы локально будете делать?
Но вот у вашей компании лицензии на тимсити нет, аккаунты у вас в AWS а не гугл клауд — надо сильно переделывать, и вообще в Котлине, на котором Teamcity хранит свои настройки никто не разбирается, потому что проект на Nodejs, и что вы локально будете делать?
Вот по этим причинам я предпочитаю не использовать тимсити. Другие современные ci системы как раз ориентированы на полное управление продуктом и процессами через репозиторий.
Конкретно в приведённом вами примере, лично я, в зависимости от роли. Договариваться с подрядчиком на берегу о критериях приёмки, либо вытаскивать проект из богомерзкого тимсити.
Вот по этим причинам я предпочитаю не использовать тимсити. Другие современные ci системы как раз ориентированы на полное управление продуктом и процессами через репозиторий.
Ну вот сделает вам подрядчик проект с teamcity DSL прямо в коде
Тимсити ТАКЖЕ как и другие CI системы может и умеет хранить все процессы в репозитории. Я же упомянул DSL. Тимсити даже поддерживает Котлин в качестве языка, на котором можно писать пайплайны и описание джобы, чтобы легко и автоматически создать проекты и таски в ней на другом тимсити с нуля.
Инфраструктура-как-код — это означает, что она поддерживается как код — удобно, с версионированием, с централизированным хранением и простым способом бэкапа.
То есть переразвернуть какие-то части с нуля можно быстро, и даже автоматизировано.
Но инфраструктура-как-код не означает, что ее можно очень легко можно поднять и развернуть в другой компании. Бывает даже наоборот — если все переехало в код, многие уже и не знают как вообще собрать продукт без этого. А это означает что прежде чем настроить с нуля в других условиях, нужно глубоко разобраться в предыдущем коде.
Иногда исходники — это просто исходники.
А инфраструктура, на которой все это пишется, собирается, откатывается — это отдельная часть, которая к исходникам продукта отношения не имеет.
И отдавая исходники, ты понимаешь что для того, чтобы банально собрать и протестировать продукт — там нужно будет потратить месяц работы девопса или нормального архитектора, чтобы разобраться что к чему.
А инфраструктура, на которой все это пишется, собирается, откатывается — это отдельная часть, которая к исходникам продукта отношения не имеет.
И отдавая исходники, ты понимаешь что для того, чтобы банально собрать и протестировать продукт — там нужно будет потратить месяц работы девопса или нормального архитектора, чтобы разобраться что к чему.
Вообще, не оговорить в договоре историю с исходниками и правами на использование результатов разработки — это верх некомпетентности.
Тут ещё такая прикольная тонкость есть, что исходники и права интеллектуально собственности на исходники — это очень сильно не одно и то же.
Ну не в России, а в СССР. А еще был в г. Калинине Фонд Алгоритмов и Программ, из давались сборники, хранящегося в этом фонде. И все это не чета нынешнему реестру отечественного ПО.
Два раза в жизни была такая предъява. Распечатали исходники в HEX шестым кеглем, заверили каждый лист, сдали и попрощались.
Прикол часто в том, что ваш (или чей угодно ещё) пилот не нужен. Люди, которые «работу работают» и так знают о бутылочных горлышках. Если вы сделаете пилот, то эти самые люди станут виноваты в этих бутылочных горлышках (ну не начальство или владельцы же, в самом деле).
Штука в том, что к большой радости, уровень осознанности людей растет. И многие руководители не ставят перед собой цель искать виноватых, это не приближает их к результату в виде качественного конечного продукта/сервиса и тд. Им-то по голове стучат огого как за невыполненные комиты. И они это понимают. Поэтому фокус у них на оптимизации инструментариев/процессов и повышения эффективности тех ресурсов, которыми они обладают. И это реально рабочая история.
Если бы это было так, то ситуация разрешалась бы опять же без вашего участия. Повторюсь, «рабочие руки» в большинстве случаев знают в чём проблема.
Или вы думаете, разработчик, который пишет на проде рад этому? А может у него просто теста нет?
А теста у него почему нет? Может потому, что в организации надо написать какую-то макулатуру вроде «технического решения», где описать сетевые структуры и т.п.?
И почему же нет этого «важного и полезного» документа? Уж не потому ли, что разработчик должен его сам выродить, а все окружающие будут кривить морды и говорить «ой, тут что-то не по корпоративным политикам, тут что-то не понятно...»
А документы надо согласовать может потому, что там «самый большой» захотел? Или потому, что бардак вокруг и не понятно где-что-почему-как работает, и люди прямо на прод пишут код?
Вот он и замкнулся цикл. И все прекрасно всё знают. Но очередные «аджайлы по-русски» (прямо как у вас и описано) появляются, усугубляя ситуацию.
Или вы думаете, разработчик, который пишет на проде рад этому? А может у него просто теста нет?
А теста у него почему нет? Может потому, что в организации надо написать какую-то макулатуру вроде «технического решения», где описать сетевые структуры и т.п.?
И почему же нет этого «важного и полезного» документа? Уж не потому ли, что разработчик должен его сам выродить, а все окружающие будут кривить морды и говорить «ой, тут что-то не по корпоративным политикам, тут что-то не понятно...»
А документы надо согласовать может потому, что там «самый большой» захотел? Или потому, что бардак вокруг и не понятно где-что-почему-как работает, и люди прямо на прод пишут код?
Вот он и замкнулся цикл. И все прекрасно всё знают. Но очередные «аджайлы по-русски» (прямо как у вас и описано) появляются, усугубляя ситуацию.
Все, что вы пишете — правда. Это мы видим сплошь и рядом.
Но то, что пишу я — тоже правда.
И тут нет конфликта.
Просто надо понимать, что для формирования потребности что-то поменять должны быть предпосылки. Она (потребность) не возникает на пустом месте и просто так. И «рабочие руки» в вашем примере зачастую не всегда могут эту потребность даже начать формировать. Ввиду разных обстоятельств (все устраивает, а сейчас заикнусь меня потом крайним сделают, что я умнее других? и тд). Потому что подсознательно каждый из нас понимает, что изменения устоявшегося положения дел, это не всегда приятно, а, как правило, наоборот.
Потребность формируется уровнем выше под постепенным давлением того, о чем вы написали. И процесс этот не мгновенный. Но когда люди понимают, что что-то не так, они начинают эту историю копать и разбираться. Кто-то сам, кто-то приходит к нам. И мы помогаем.
Но то, что пишу я — тоже правда.
И тут нет конфликта.
Просто надо понимать, что для формирования потребности что-то поменять должны быть предпосылки. Она (потребность) не возникает на пустом месте и просто так. И «рабочие руки» в вашем примере зачастую не всегда могут эту потребность даже начать формировать. Ввиду разных обстоятельств (все устраивает, а сейчас заикнусь меня потом крайним сделают, что я умнее других? и тд). Потому что подсознательно каждый из нас понимает, что изменения устоявшегося положения дел, это не всегда приятно, а, как правило, наоборот.
Потребность формируется уровнем выше под постепенным давлением того, о чем вы написали. И процесс этот не мгновенный. Но когда люди понимают, что что-то не так, они начинают эту историю копать и разбираться. Кто-то сам, кто-то приходит к нам. И мы помогаем.
Нет, я же не спорю, что у нас менталитет такой, что «варягам» доверия больше, чем своим. И то что «Ванька» скажет — от того лишь отмахнутся, а когда тоже от «консалтеров/интеграторов великих и могучих» (а лучше ещё заморских) — то сразу надо тому же «Ваньке» на вид поставить и заставить сделать.
Тут не про потребность. А про то, что от пилота в вашем описании пользы для людей на местах действительно не будет. Будет только головная боль.
Тут не про потребность. А про то, что от пилота в вашем описании пользы для людей на местах действительно не будет. Будет только головная боль.
Все очень зависит от того как этот пилот будет проходить. Если, как часто бывает, придут консалтеры напишут много умных слов и уйдут — то да будет головная боль. Так как любая «лучшая практика» во-первых, все лишь рекомендация, а не строгий закон, во-вторых имеет границы применимости, т.е. пост и пред-условия, без выполнения которых превращается в цирк. А если консультанты постараются подружиться с людьми на местах и будут планомерно внедрядть новые процессы, то может и выйдет толк. Причем «подружиться» это, ИМХО, ключевое — иначе местные будут невольно саботировать процесс — никто не любит когда их учат наставлениями и приказами.
Про внедрение лучших практик у меня есть два примера — обе «внедрялись» с подачи заморского интегратора.
Первый про документацию — нужно документировать разработки производиемые в ERP(SAP). Вроде и нужно и даже полезно, результат — куча docx файлов в хранилище без индексации и поиска. Причем в этих файлах содержались по сути pull-requests(только к коду никак не привязанные), они не были поделены ни по бизнес-процессам, ни по модулям в системе, один и тот же класс мог упоминаться в десяткаях разных документов(про SOLID там никто не слышал). То есть если берешь какой-нибудь бизнес-процесс или кусок сервисного кода и пытаешься найти к нему документацию — то это бесполезная потеря времени.
Второй — аджайл, все круто, только заказчику забыли рассказать что это и зачем, а заказчику этот ваш MVP даром не сделася, ему подавай готовую систему, которую писать год минимум и она за это время естественно устареет. Хотя бы митинги с «я ничего не сделал» быстро отменили.
Про внедрение лучших практик у меня есть два примера — обе «внедрялись» с подачи заморского интегратора.
Первый про документацию — нужно документировать разработки производиемые в ERP(SAP). Вроде и нужно и даже полезно, результат — куча docx файлов в хранилище без индексации и поиска. Причем в этих файлах содержались по сути pull-requests(только к коду никак не привязанные), они не были поделены ни по бизнес-процессам, ни по модулям в системе, один и тот же класс мог упоминаться в десяткаях разных документов(про SOLID там никто не слышал). То есть если берешь какой-нибудь бизнес-процесс или кусок сервисного кода и пытаешься найти к нему документацию — то это бесполезная потеря времени.
Второй — аджайл, все круто, только заказчику забыли рассказать что это и зачем, а заказчику этот ваш MVP даром не сделася, ему подавай готовую систему, которую писать год минимум и она за это время естественно устареет. Хотя бы митинги с «я ничего не сделал» быстро отменили.
очень часто разрабы выпрашивают тест окружение, а потом хренакс и оно становится продакшен без объявления войны, причем, что оно стало продакшен становится известно, когда разрабов попросили освободить тестовый стенд
1. Штраф за ошибки в ПО, внесённом разработчиками.
Штрафы, это, конечно, жестоко, но что плохого в том, что код перепроверяется вдоль и поперёк перед релизом вместо тестирования на проде и десятка патчей следом? Даже если в ущерб скорости разработки.
Да, но кого штрафовать? Может, это менеджер наседал, мол, давай быстрее в прод, времени нет?
Или тестировщик не проверил?
Или аналитик неправильно расписал?
Может, человеку вообще угрожали увольнением по статье и запугали, чтобы он побыстрее в продакшен вытащил?
Да и любое ПО содержит ошибки. Все это знают. Мы лишь стараемся уменьшить количество ошибок, но не можем от них полностью избавиться.
Или тестировщик не проверил?
Или аналитик неправильно расписал?
Может, человеку вообще угрожали увольнением по статье и запугали, чтобы он побыстрее в продакшен вытащил?
Да и любое ПО содержит ошибки. Все это знают. Мы лишь стараемся уменьшить количество ошибок, но не можем от них полностью избавиться.
штрафуют подрядчика поставщика кода, как он убытки будет в своей системе распределять его головняк. Но «попытки решить задачу» должны стоить дешевле чем «решение задачи». Если в договоре у вас «решение» и вы за «решение» платите и подрядчик деньги уже получил, то «процесс решения» это несколько иное. И он изначально оценился бы по другому. Или хотя бы предупреждайте по человечески заказчика что код не тестировали и стоимость тестов в продакшене прогнозируется меньше стоимости тестирования в разработке, что бы заказчик хотя б забекапился посерьезнее.
В соседней теме вообще советуют запускать код в проде без тестирования.
- Штраф за ошибки в ПО, внесённом разработчиками.
- Естественно, любой релиз (даже мелкий) выпускается в десятки раз медленнее, чем мог бы.
Вы хотели сказать что софт в кои-то веки начали нормально тестировать? Ну а не как обычно -«время программиста дороже аппаратных ресурсов и релизы должны быть каждый день» и в продакшн.
В общем, высказался. Если узнали свои проблемы — пишите в почту oeremeev@croc.ru. У нас для крупного бизнеса есть почти бесплатные пилоты с экспресс-диагностикой (поиски бутылочных горлышек за 3-5 дней). Если кому-то у вас из бизнеса надо объяснить, что с техдолгом мириться нельзя, — тоже пишите, мы умеем это нормально считать.
Я помню, у меня на одном месте работы основная проблема была в том, что выдали компьютер с глючным wifi адаптером, который постоянно зависал и терял сеть. Сколько я не просил его починить, в ответ слышал только крики и истерики. Вплоть до CEO доходило.
Ну вы же понимаете, что ни один CEO никогда не признается, что не смог организовать даже закупку техники.
Неинтересная рутина — так было, так есть и так будет
Кто-то ещё в одной компании кодит прямо на проде. «Тут один маленький скриптик, я знаю, что делаю». Спасибо тебе, милый человек, но если я тебя найду, то даже не знаю, что с тобой сделаю.
Такое в некрупных компаниях запросто может быть.
Если бизнес устраивает, что в штате есть только программист(ы) и сисадмин(ы) — почему нет?
Зависит от масштаба.
Да и в крупных…
В общем то — в почти любых, где требуется максимальная скорость исправления косяков.
Я, как то, на собеседовании одном долго слушал о том, как поставлен процесс разработки, сколько кругов ада проходит задача для деплоя, как разработчики всё делают исключительно на тестовой среде… а потом:
-Ну, на прод у разработчиков есть доступ?
-(потупив глазки) Есть, конечно… надо же как то факапы фиксить.
В общем то — в почти любых, где требуется максимальная скорость исправления косяков.
Я, как то, на собеседовании одном долго слушал о том, как поставлен процесс разработки, сколько кругов ада проходит задача для деплоя, как разработчики всё делают исключительно на тестовой среде… а потом:
-Ну, на прод у разработчиков есть доступ?
-(потупив глазки) Есть, конечно… надо же как то факапы фиксить.
А максимальная скорость исправления косяков требуется именно там, где болт положен на тестовую среду. Когда прод физически недоступен (например, посреди тайги на военной базе), то тестовая среда будет содержать уйму тест-кейсов, собираемых от пользователей, с нагрузочным тестированием. А когда можно что-то «быстренько» поправить, то тестовая среда заброшена, с устаревшими данными и т.п. В результате получается разработка через «авось»: ну на стейджинге вроде запустилось, а на проде проверим. Если что, поправим.
Максимальная скорость исправления косяков требуется везде где требуется, независимо от положен болт на тестовую среду или нет. Чаще всего эта необходимость пропорциональна количеству денег/эквивалента денег которые теряются в случае факапа за время факапа.
А факапы на проде случаются. Количество тестов и прочей шелухи может их количество снизить, но не до 0%.
Соответственно и протокол по скорейшему решению таких проблем должен быть. И тут уже начинается компромис между скоростью, доверием к профессионализму сотрудникам и «штатным порядком деплоя»… и бизнес выбирает первое обычно.
Так и получается, что человек, разрабатывающий данный функционал, как человек, которые быстрее и чётче всех может исправить ошибку, наделяется правами для экстренного фикса прода.
И ничего о том, что тест заброшен или с устаревшими данными или про авось тут нет. Просто прагматика.
Если бизнес готов к исправлению критического или не очень бага через значительное время или оплате кроме дежурного программиста ещё и команды дежурных тестировщиков и QA — это хорошо, но что то я такое не часто видел (бывало, конечно, но обычно это или компании которым в достаточной степени всё-равно на клиентов или с оооочень толстым бюджетом).
ЗЫ: но есть, конечно, большая разница между «разработка на проде» (да, это чертовски сурово) и «доступ для хотфикса» (в известной степень допустимое решение). Из статьи непонятно к какому случаю относится «скриптик», но выглядит как хотфикс. )
А факапы на проде случаются. Количество тестов и прочей шелухи может их количество снизить, но не до 0%.
Соответственно и протокол по скорейшему решению таких проблем должен быть. И тут уже начинается компромис между скоростью, доверием к профессионализму сотрудникам и «штатным порядком деплоя»… и бизнес выбирает первое обычно.
Так и получается, что человек, разрабатывающий данный функционал, как человек, которые быстрее и чётче всех может исправить ошибку, наделяется правами для экстренного фикса прода.
И ничего о том, что тест заброшен или с устаревшими данными или про авось тут нет. Просто прагматика.
Если бизнес готов к исправлению критического или не очень бага через значительное время или оплате кроме дежурного программиста ещё и команды дежурных тестировщиков и QA — это хорошо, но что то я такое не часто видел (бывало, конечно, но обычно это или компании которым в достаточной степени всё-равно на клиентов или с оооочень толстым бюджетом).
ЗЫ: но есть, конечно, большая разница между «разработка на проде» (да, это чертовски сурово) и «доступ для хотфикса» (в известной степень допустимое решение). Из статьи непонятно к какому случаю относится «скриптик», но выглядит как хотфикс. )
Не понимаю зачем доступ на прод для хотфикса?
А потому что не у всех есть инфраструктура деплоя. Часто выглядит так — деплоим редко(не аджайл ага), поэтому инфраструктуру автоматизировать не будем. Зато когда деплоим, то вылезает куча косяков, которые нужно фиксить вот прямо сейчас.
Есть еще вариант, если пойти через имеющийся DI, то придется писать объяснительную какую, а если напряму в проде, то почему-то — не придется.
Есть еще вариант, если пойти через имеющийся DI, то придется писать объяснительную какую, а если напряму в проде, то почему-то — не придется.
Окей, а какие варианты? )
Провести полный цикл деплоя с тестированием,QA и прочими прелестями?
Для этого нужны люди (которые могут отсутствовать на рабочем месте, а их присутствие в виде дежурных — деньги и время), и время.
А если деплой полностью автоматический, то разницы в правках на тесте или на бою, в общем то нет, по большому счёту. (но тут ещё может быть косяк в самой системе деплоя или данных на бою и тогда ТТ).
Провести полный цикл деплоя с тестированием,QA и прочими прелестями?
Для этого нужны люди (которые могут отсутствовать на рабочем месте, а их присутствие в виде дежурных — деньги и время), и время.
А если деплой полностью автоматический, то разницы в правках на тесте или на бою, в общем то нет, по большому счёту. (но тут ещё может быть косяк в самой системе деплоя или данных на бою и тогда ТТ).
Для ясности — я говорю о серьезных конторах, а не о начинающих стартапах и бизнесах с одним-двумя разработчиками.
1) Полный цикл деплоя занимает меньше времени, чем правка на проде руками.
2) Доступа на прод у разработчиков нет, а девопсов которые умеют в программирование три с половиной человека.
Если у вас не так, то у вас проблемы.
Например, из реального. Программист поправил код на проде (питон скрипт) в пятницу вечером и пошел домой. А после него провели релиз, его изменения затерли — и сайт все выходные неправильно обрабатывал данные. Тут сложились сразу несколько ошибок — код не был закомичен в cvs, доступ девелопера на прод, правка руками на проде, пятница, релиз. И можно сказать, что его ошибка что он не закомитил, что у нас хорошие разработчики, они так не сделают. Но если вы менеджер проекта, тим лид или просто разработчик который общается с бизнесом, вы понимаете что это риск.
PS Статья и коменты показали в каком плачевном состоянии индустрия.
1) Полный цикл деплоя занимает меньше времени, чем правка на проде руками.
2) Доступа на прод у разработчиков нет, а девопсов которые умеют в программирование три с половиной человека.
Если у вас не так, то у вас проблемы.
Например, из реального. Программист поправил код на проде (питон скрипт) в пятницу вечером и пошел домой. А после него провели релиз, его изменения затерли — и сайт все выходные неправильно обрабатывал данные. Тут сложились сразу несколько ошибок — код не был закомичен в cvs, доступ девелопера на прод, правка руками на проде, пятница, релиз. И можно сказать, что его ошибка что он не закомитил, что у нас хорошие разработчики, они так не сделают. Но если вы менеджер проекта, тим лид или просто разработчик который общается с бизнесом, вы понимаете что это риск.
PS Статья и коменты показали в каком плачевном состоянии индустрия.
Для ясности — я говорю о серьезных конторах, а не о начинающих стартапах и бизнесах с одним-двумя разработчиками.
ну так и я о фирмах с штатом больше 100 разработчиков (иногда на порядок)
1) Полный цикл деплоя занимает меньше времени, чем правка на проде руками.это по определению не так ) потому что кроме самого непосредственного внесения правок, ещё и полный цикл деплоя.
2) Доступа на прод у разработчиков нет, а девопсов которые умеют в программирование три с половиной человека.=)) т.е. надо ещё и дежурного девопса держать?
Например, из реального. Программист поправил код на проде (питон скрипт) в пятницу вечером и пошел домой. А после него провели релиз, его изменения затерли — и сайт все выходные неправильно обрабатывал данные. Тут сложились сразу несколько ошибок — код не был закомичен в cvs, доступ девелопера на прод, правка руками на проде, пятница, релиз. И можно сказать, что его ошибка что он не закомитил, что у нас хорошие разработчики, они так не сделают. Но если вы менеджер проекта, тим лид или просто разработчик который общается с бизнесом, вы понимаете что это риск.
Все знают риски. А кто не знает — тем это быстро объяснят. Но те кто за это отвечают (чаще всего бизнес) предпочитают скорость решения бага возможными осложнениями. Особенно во время, когда больше части работников нет в доступе (выходной, к примеру) и держать дежурного QA, Тестировщика, Девопса, и разработчика (желательно ещё кодревьюера) причём способных поддержать ВЕСЬ проект (или каждую из его частей) и ждать пока фикс пройдёт все тесты, кодревью и задеплоится (что не так уж и быстро бывает, особенно если народ по удалёнке).
И это вполне приемлимо, если правильно оформлять фиксы и потом спокойно и правильно доделать когда наступит рабочее время.
А если исходить из того, что человек может быть членистоног и что то сломает — так он с тем же успехом выпустит фикс который пройдёт все тесты и опять положит прод (как тот, который положил), или QA неправильно что то сделает или ещё кто то в цепочке деплоя. Риски, в общем то, те же )
Если у вас иначе — хорошо. =) Но чем длиннее цепочка — тем она длиннее.
это по определению не так ) потому что кроме самого непосредственного внесения правок, ещё и полный цикл деплоя.
Я видимо не понимаю что вы на проде правите — скрипт какой-то? Тогда теоретически это может быть быстрее чем правильный релиз. Согласен. Только вероятность привнести новый баг становится выше.
что то сломает — так он с тем же успехом выпустит фикс который пройдёт все тесты и опять положит прод (как тот, который положил)
Ну нет же. Допустим вероятность того, что разработчик сломал что-то во время фикса в коде равна p > 0. Но есть еще вероятность q > 0 того, что он сломал что-то во время подключения (например подключился не на тот сервер, добавил лишний пробел или запятую, скопировал файл с line break виндовским из IDE, скопировал из IDE не ту версию скрипта и т.п.). Получили вероятность p+q > p.
Я видимо не понимаю что вы на проде правите — скрипт какой-то? Тогда теоретически это может быть быстрее чем правильный релиз. Согласен. Только вероятность привнести новый баг становится выше.
Так скрипт уже поломан. Даже если там и появится новый баг — хуже уже не станет.
Хуже может стать только в том маловероятном случае, когда программист по ошибке начнет править не тот скрипт. Но вероятность такого события куда ниже чем просто вероятность допустить ошибку.
Я видимо не понимаю что вы на проде правите — скрипт какой-то? Тогда теоретически это может быть быстрее чем правильный релиз. Согласен. Только вероятность привнести новый баг становится выше.Ну да, скрипт или часть/модуль которую можно отдельно исправить без пересборки всего и вся.
Ну да, риск увеличивается, хотя, если уже существующий сломанный «скрипт» прошёл в прод — значит риск что даже при правильном деплое что то будет сломано тоже велик )
Ну нет же. Допустим вероятность того, что разработчик сломал что-то во время фикса в коде равна p > 0. Но есть еще вероятность q > 0 того, что он сломал что-то во время подключения (например подключился не на тот сервер, добавил лишний пробел или запятую, скопировал файл с line break виндовским из IDE, скопировал из IDE не ту версию скрипта и т.п.). Получили вероятность p+q > p.А есть ещё вероятность что где то в процессе деплоя есть ошибка, в процессе сборки, в людях которые этим занимаются и прочая-прочая.
Между итоговым риском хотфикса человеком который это делал и понимает в чём ошибка сразу по живому против скорости и стоимости внеплановой выкатки изменений по штатному расписанию обычно (по моему личному опыту) выбирают первое. И в этом есть смысл ) Как в прочем и в обратном.
ЗЫ: но разработчиков которые регулярно промышляют описанными вами вещами я бы и до теста не допускал, не то что на прод хотфиксы выкатывать.
я говорю о серьезных конторах, а не о начинающих стартапах и бизнесах с одним-двумя разработчиками.
1) Полный цикл деплоя занимает меньше времени, чем правка на проде руками.
В серьезных конторах согласование о разрешении деплоя на прод занимает неделю, пока все тикеты откроешь, аппрувалы получишь. А сам деплой да, может занять и секунды.
Согласен.
Поэтому нет смысла экономить секунды, делая фикс на проде руками.
Поэтому нет смысла экономить секунды, делая фикс на проде руками.
Экономится как раз эта неделя согласований и решений, особенно учитывая что в этом время проект стоит.
Не неделя экономится, а процессы аудита вообще security policy как таковой отсутствует в проекте, что может привести к гораздо большим рискам, чем задержка отдельного релиза.
Может. А может и не привести.
Риски и издержки каждый оценивает по-своему.
Для кого то риски повторной ошибки при фиксе (и так же оперативно исправленной) куда ниже чем издержки от недельного выкатывания фикса в бой и простоя всей системы в течении этого времени. (который может пройти все тесты, как и предыдущая версия).
Риски и издержки каждый оценивает по-своему.
Для кого то риски повторной ошибки при фиксе (и так же оперативно исправленной) куда ниже чем издержки от недельного выкатывания фикса в бой и простоя всей системы в течении этого времени. (который может пройти все тесты, как и предыдущая версия).
Повторная ошибка может быть не исправимой. Например удаление данных пользователей. Или рассылка автоматических сообщений пользователям. Или списание со счета пользователя.
Но в общем соглашусь, каждый оценивает риски для себя по своему.
Но в общем соглашусь, каждый оценивает риски для себя по своему.
Ну, тут зависит от компетентности того, кто исправляет. =)
Если бизнес верит, что перед внесением неисправимых изменений разработчик не озаботится бэкапом или возможностью отката, не отложит проблему как невозможную в разрезе его ответственности или не призовёт кого то для дублирования своих выкладок и вообще — не очень ответственный и адекватный человек… Ну что ж, тогда стоит пересмотреть кандидата на дежурство или риски и процесс внесения хотфиксов на бой )
Если бизнес верит, что перед внесением неисправимых изменений разработчик не озаботится бэкапом или возможностью отката, не отложит проблему как невозможную в разрезе его ответственности или не призовёт кого то для дублирования своих выкладок и вообще — не очень ответственный и адекватный человек… Ну что ж, тогда стоит пересмотреть кандидата на дежурство или риски и процесс внесения хотфиксов на бой )
Зовите меня когда нужно будет настроить процессы. :)
На всякий случай — я инженер, а не менеджер.
На всякий случай — я инженер, а не менеджер.
Собственно, настройка процессов тут не причём.
Или вы упорствуете просто чтобы доказать, что правы, либо у вас не настроены процессы разработки и доставки.
Эх-хе… ну давайте расскажите, как должны быть настроены процессы разработки и доставки что бы исправить скрипт на проде было быстрее через штатный цикл деплоя, а не напрямую.
*ну, допустим, закоментировать отладочный SELECT.
*ну, допустим, закоментировать отладочный SELECT.
Вы смешали несколько моих высказываний в одно, может быть я сам неправильно выразился.
Если у вас скриптовый язык, нет кубернетеса и доступ на прод сервер есть у всех подряд, то действительно быстрее руками. Но это небезопасно.
Как сделать правильно — представьте, что доступ к проду будет обрезан через месяц для всех разработчиков. А деплой осуществляет команда девопсов, менеджера которой посадят на 10 лет если кто-то не из его команды сможет поправить код руками на проде. И дальше сводите время релиза к минимуму.
Если у вас скриптовый язык, нет кубернетеса и доступ на прод сервер есть у всех подряд, то действительно быстрее руками. Но это небезопасно.
Как сделать правильно — представьте, что доступ к проду будет обрезан через месяц для всех разработчиков. А деплой осуществляет команда девопсов, менеджера которой посадят на 10 лет если кто-то не из его команды сможет поправить код руками на проде. И дальше сводите время релиза к минимуму.
Ну так речь как раз о первом случае, когда можно внести локальные изменения и когда это зашибись как критично.
Да и доступ, обычно, только у дежурного, а не у всех )
А второй вариант — чаще всего тупо дольше и требует больше ресурсов на поддержание (хотя бы в виде дежурных и разрабов и девопсов и прочих участников выкатки).
Но да, конечно второй вариант безопаснее, с этим никто и не спорит.
Поэтому я и говорю — это вопрос выбора и рисков. Скорость vs безопасность. =)
Да и доступ, обычно, только у дежурного, а не у всех )
А второй вариант — чаще всего тупо дольше и требует больше ресурсов на поддержание (хотя бы в виде дежурных и разрабов и девопсов и прочих участников выкатки).
Но да, конечно второй вариант безопаснее, с этим никто и не спорит.
Поэтому я и говорю — это вопрос выбора и рисков. Скорость vs безопасность. =)
Может. А может и не привести.
Ну в таком случае, я могу заявить, что неделя может экономится а может и не экономится.
Только в случае если ошибка того же класса, что и была (которая прошла все тесты и задеплоилась) можно потерять и две недели в случае повтора.
А так — тоже мгновение на вмешательство в прод.
Тут не вопрос «может или не может», «ошибётся / не ошибётся», а вопрос издержек.
На одной чаше весов:
— Риск что человек, который хорошо понимает систему и сам же её разрабатывал сделает что то непоправимое и сломает вообще всё.
На другой:
— Содержание целого штата дежурных (разраб, техлид, тестировщик, QA, девопс, сисадмин, кто там ещё), причём по ставке выходного дня.
— Простой системы (чем она больше — тем она больше стоит) в течении прохождения задачи полного цикла выпуска или вообще — пока на работу не выйдут ответственные работники.
Вопрос лишь в величине рисков и издержек. По моему опыту — бизнес достаточно доверяет компетентности своих разрабов (или конкретных людей, к примеру тимлидам), что бы считать риск первого достаточно небольшим что бы избежать реальных и постоянных издержек второго варианта.
Если издержки на второй вариант не велики, а доверие к профессионализму сотрудников не очень велико — то решение будет иным и это будет тоже правильно. =)
А так — тоже мгновение на вмешательство в прод.
Тут не вопрос «может или не может», «ошибётся / не ошибётся», а вопрос издержек.
На одной чаше весов:
— Риск что человек, который хорошо понимает систему и сам же её разрабатывал сделает что то непоправимое и сломает вообще всё.
На другой:
— Содержание целого штата дежурных (разраб, техлид, тестировщик, QA, девопс, сисадмин, кто там ещё), причём по ставке выходного дня.
— Простой системы (чем она больше — тем она больше стоит) в течении прохождения задачи полного цикла выпуска или вообще — пока на работу не выйдут ответственные работники.
Вопрос лишь в величине рисков и издержек. По моему опыту — бизнес достаточно доверяет компетентности своих разрабов (или конкретных людей, к примеру тимлидам), что бы считать риск первого достаточно небольшим что бы избежать реальных и постоянных издержек второго варианта.
Если издержки на второй вариант не велики, а доверие к профессионализму сотрудников не очень велико — то решение будет иным и это будет тоже правильно. =)
Если это хотя бы средний по размеру продукт, то в штате уже как минимум 20-30 человек.
Если это продукт чуть больший, чем средний, у него куча зависимостей, то уже не существует одного человека, который бы знал всю систему, даже если он в проекте уже давно.
Если это statefull продукт, то у него может быть база, и ошибка, которые вызывает изменения прямо на проде, может привести крупным проблемам, которые не так легко откатить назад.
Особенно если база большая, а операций много. Там даже банальное восстановление из бэкапа может занять часы, при этом надо еще разобраться можно ли откатываться с потерей текущих операций и как это правильно все сделать и вообще сразу снежный ком.
По моему опыту — бизнес не должен доверять разрабам на слово.
И если риск проблем на продакшене стоит денег/репутацию, все изменения должны проходить через тестовый енвайрнмент и как минимум «четыре глаза».
На самом деле это не нужно, если все изменения на прод выкатываются после тестирования. Риск, что выйдет что-то с ошибкой — в таких случаях стремится к нулю, а значит что на выходных релиз выкатывает релиз инженер, а все остальные — максимум on-call, на случай нестандартной ситуации.
Это как раз в случае прямого исправления чего-либо на продакшене, нужен целый штат на всякий случай, чтобы оперативно понять что и как чинить и восстанавливать.
Если это продукт чуть больший, чем средний, у него куча зависимостей, то уже не существует одного человека, который бы знал всю систему, даже если он в проекте уже давно.
Если это statefull продукт, то у него может быть база, и ошибка, которые вызывает изменения прямо на проде, может привести крупным проблемам, которые не так легко откатить назад.
Особенно если база большая, а операций много. Там даже банальное восстановление из бэкапа может занять часы, при этом надо еще разобраться можно ли откатываться с потерей текущих операций и как это правильно все сделать и вообще сразу снежный ком.
По моему опыту — бизнес не должен доверять разрабам на слово.
И если риск проблем на продакшене стоит денег/репутацию, все изменения должны проходить через тестовый енвайрнмент и как минимум «четыре глаза».
— Содержание целого штата дежурных (разраб, техлид, тестировщик, QA, девопс, сисадмин, кто там ещё), причём по ставке выходного дня.
На самом деле это не нужно, если все изменения на прод выкатываются после тестирования. Риск, что выйдет что-то с ошибкой — в таких случаях стремится к нулю, а значит что на выходных релиз выкатывает релиз инженер, а все остальные — максимум on-call, на случай нестандартной ситуации.
Это как раз в случае прямого исправления чего-либо на продакшене, нужен целый штат на всякий случай, чтобы оперативно понять что и как чинить и восстанавливать.
Если это хотя бы средний по размеру продукт, то в штате уже как минимум 20-30 человек.ну допустим 150. в штате разработки.
Если это продукт чуть больший, чем средний, у него куча зависимостей, то уже не существует одного человека, который бы знал всю систему, даже если он в проекте уже давно.значит в каждой команде должен быть такой человек.
Если это statefull продукт, то у него может быть база, и ошибка, которые вызывает изменения прямо на проде, может привести крупным проблемам, которые не так легко откатить назад.Да, конечно. При исправлении проблемы такое странно будет не учитывать.
Особенно если база большая, а операций много. Там даже банальное восстановление из бэкапа может занять часы, при этом надо еще разобраться можно ли откатываться с потерей текущих операций и как это правильно все сделать и вообще сразу снежный ком.
По моему опыту — бизнес не должен доверять разрабам на слово.
Если бизнес не доверяет разработчикам, то я даже не знаю… отдавать сторонним специалистам проверять и ревьюить код? =)
Конечно бизнес должен доверять программистам. Но это не значит, что программисты не должны прикрывать свои пятые точки и защищать бизнес.
И если риск проблем на продакшене стоит денег/репутацию, все изменения должны проходить через тестовый енвайрнмент и как минимум «четыре глаза».Ну, с этим никто и не спорит.
Вопрос в хотфиксах и исправлении критических ошибок. И тут стоит уже выбор: тратить время и средства на содержание итп-итп-итп я это уже писал. =)
На самом деле это не нужно, если все изменения на прод выкатываются после тестирования. Риск, что выйдет что-то с ошибкой — в таких случаях стремится к нулю, а значит что на выходных релиз выкатывает релиз инженер, а все остальные — максимум on-call, на случай нестандартной ситуации.
Так разговор как раз о нештатных ситуациях и падениях в бою и необходимости срочного исправления.
Это как раз в случае прямого исправления чего-либо на продакшене, нужен целый штат на всякий случай, чтобы оперативно понять что и как чинить и восстанавливать.т.е. что бы исправить что то на проде этот штат не нужен, а что бы исправить то что кто то исправил на проде — нужен?
Если бизнес не доверяет разработчикам, то я даже не знаю… отдавать сторонним специалистам проверять и ревьюить код? =)
Конечно бизнес должен доверять программистам. Но это не значит, что программисты не должны прикрывать свои пятые точки и защищать бизнес.
Не так поняли, или я не так выразился. Дело не в доверии между людьми
Дело в риске допустить человеческую ошибку, от которой никто не застрахован.
Поэтому практики «четыре глаза», «пулл реквесты с обязательным review», автотесты и вообще прогон на тестовом энве — как раз и уменьшают вероятность того, что человеческая ошибка прокрадется на продакшен.
Так разговор как раз о нештатных ситуациях и падениях в бою и необходимости срочного исправления.
Ну как-то эта ваша фраза уже конфликтует с тем, что
«значит в каждой команде должен быть такой человек.»
«при исправлении проблем с базой и откатом данных понятно что надо будет это учитывать»
Если по вашим словам нужно срочное исправление прямо на проде, а например одного человека который все знает не существует, то вот вам уже и консилиум из самых знающих представителях каждой команды, плюс та же проблема с откатом данных в базе и все это превращается в вопрос — что значит
И тут стоит уже выбор: тратить время и средства на содержание итп-итп-итп я это уже писал. =)
Да при ваших 150 разработчиках, содержание CI системы с автоматической сборкой, тестированием и деплойментом будет стоить менее 1-2 зарплат этих разработчиков, то есть 1-2%.
Не так поняли, или я не так выразился. Дело не в доверии между людьми
Дело в риске допустить человеческую ошибку, от которой никто не застрахован.
Поэтому практики «четыре глаза», «пулл реквесты с обязательным review», автотесты и вообще прогон на тестовом энве — как раз и уменьшают вероятность того, что человеческая ошибка прокрадется на продакшен.
Прошу прощения, это я немного поёрничал.
Но — на проде через все автотесты уже прошла одна ошибка, что мешает и второй так же пройти? Шанс, в общем то так же велик как и человеческая ошибка (учитывая что эта ошибка уже пролезла на прод), а ресурсы и время будет потеряно.
Но если шанс оценивать иначе — то и вывод иной )
Ну как-то эта ваша фраза уже конфликтует с тем, чтоДа нет, не конфликтует. Какой консилиум если команды разные? Парни из других команд обычно в данном проекте не разбираются — о чём с ними совещаться? так что достаточно дежурного от команды/проекта.
«значит в каждой команде должен быть такой человек.»
«при исправлении проблем с базой и откатом данных понятно что надо будет это учитывать»
Если по вашим словам нужно срочное исправление прямо на проде, а например одного человека который все знает не существует, то вот вам уже и консилиум из самых знающих представителях каждой команды, плюс та же проблема с откатом данных в базе и все это превращается в вопрос — что значит
Да при ваших 150 разработчиках, содержание CI системы с автоматической сборкой, тестированием и деплойментом будет стоить менее 1-2 зарплат этих разработчиков, то есть 1-2%.1-2 зарплаты на поддержание системы, ещё столько же на тех кто будет этим пользоваться и штат дежурных по её запуску. 3-4 зп — это ещё целая команда. =)
Иногда то что соседняя команда не разбирается в вопросе это даже большой плюс — они могут взглянуть на проблему незамыленым глазом и сказать «да у вас тут и тут хвосты торчат метровой длины, а вы и не замечаете».
И будут посланы далеко и надолго. =)
1. В нерабочее время во время исправления бага на проде — это СОВСЕМ НЕ ТОТ момент, когда нужно слушать сомнительные заявления о техдолге и оптимальном способе реализации людей, которые не в курсе архитектуры и объектов системы.
2. Процесс «тыканья грязным пальцем» в чужой проект должен проходить в штатном порядке (если такое необходимо), с поставленным подходом, иначе это будет не конструктив а срач. =)
Так что, даже если соседняя команда считает что может что то порекомендовать другой команде — это надо делать иначе, а лучше — вообще через обсуждение с архитектором и главой команды.
И, нет, практически никогда это не плюс. Команда обычно в курсе, где у неё костыли и техдолг, и лишний раз макать их в это лицом — просто унижать их как профессионалов, особенно если они справляются с поставленными требованиями к продукту. Если не в курсе — то это вопрос совсем не к соседним командам, а к тем, кто управляет проектом и вышестоящим начальством — почему продукт не соответствует требованиям, а люди — занимаемым должностям.
Так что -пусть пилят свой проект и не лезут, если не звали. Давать советы другим командам и тыкать в их ошибки — не их задача.
1. В нерабочее время во время исправления бага на проде — это СОВСЕМ НЕ ТОТ момент, когда нужно слушать сомнительные заявления о техдолге и оптимальном способе реализации людей, которые не в курсе архитектуры и объектов системы.
2. Процесс «тыканья грязным пальцем» в чужой проект должен проходить в штатном порядке (если такое необходимо), с поставленным подходом, иначе это будет не конструктив а срач. =)
Так что, даже если соседняя команда считает что может что то порекомендовать другой команде — это надо делать иначе, а лучше — вообще через обсуждение с архитектором и главой команды.
И, нет, практически никогда это не плюс. Команда обычно в курсе, где у неё костыли и техдолг, и лишний раз макать их в это лицом — просто унижать их как профессионалов, особенно если они справляются с поставленными требованиями к продукту. Если не в курсе — то это вопрос совсем не к соседним командам, а к тем, кто управляет проектом и вышестоящим начальством — почему продукт не соответствует требованиям, а люди — занимаемым должностям.
Так что -пусть пилят свой проект и не лезут, если не звали. Давать советы другим командам и тыкать в их ошибки — не их задача.
Был случай, когда всё отлично отработало на тестах, было показано заказчику, заказчик похлопал в ладоши, развернули на проде у заказчика… И ничего не работает.
Потому что на тест заказчик выдал старую структуру БД с невалидными данными, а ключевые колонки в таблицах молча обрезал и не сказал об этом.
Потому что там секретные данные, их нельзя передавать. И sha2 к ним нельзя. И забить случайными данными нельзя, потому что секретно.
Пришлось пепеписывать и тестить на месте — и фронт, и бэк.
Зато какой чудесный код, когда приходит Высокое Начальство и в честь праздника наливает… Отказаться нельзя — оскорбление начальства. Не кодить нельзя, нужно срочнобыстро доделать, заодно и показать, что мы делаем всё возможное.
Потому что на тест заказчик выдал старую структуру БД с невалидными данными, а ключевые колонки в таблицах молча обрезал и не сказал об этом.
Потому что там секретные данные, их нельзя передавать. И sha2 к ним нельзя. И забить случайными данными нельзя, потому что секретно.
Пришлось пепеписывать и тестить на месте — и фронт, и бэк.
Зато какой чудесный код, когда приходит Высокое Начальство и в честь праздника наливает… Отказаться нельзя — оскорбление начальства. Не кодить нельзя, нужно срочнобыстро доделать, заодно и показать, что мы делаем всё возможное.
НЛО прилетело и опубликовало эту надпись здесь
Например, hh.ru, судя по их статье, практикует подобное. Если верить wikipedia, в декабре у них было 683 сотрудника (не знаю, насколько это много или мало).
Олег, это же не документация.
А чём там говорилось? Аффтар верит, что я помню все эти пункты?
Ок, надо пролистать к пункту 1. А где же он? Не в начале текста. Абзац, абзац, абзацина со перечнем страшных ужасов разработки… а, вот. Про штрафы за баги.
Теперь надо вспомнить, где я был в тот момент, когда этот чёртов первый пункт был упомянут…
Да ёпт!
А потом они ходютЪ и говорят, что у кого-то процессы не налажены…
Ну, например, смотрите пункт 1.
А чём там говорилось? Аффтар верит, что я помню все эти пункты?
Ок, надо пролистать к пункту 1. А где же он? Не в начале текста. Абзац, абзац, абзацина со перечнем страшных ужасов разработки… а, вот. Про штрафы за баги.
Теперь надо вспомнить, где я был в тот момент, когда этот чёртов первый пункт был упомянут…
Да ёпт!
А потом они ходютЪ и говорят, что у кого-то процессы не налажены…
Штраф за ошибки в ПО, внесённом разработчиками.Недавно расследовал баг, что именно это и захотелось сделать: код вызывал SQL с картезианским джойном, получал в сотни раз больше записей, чем было в таблицах, а пототм средствами Java избавлялся от дупликатов. Код писал подрядчик, который специализируется на Java-разработке, крутые ребята, если не брать во внимание этот прокол. До сих пор ломаю голову, как такое может быть написано человеком…
Клиент, кстати, сказал пока не фиксить, так как есть более приоритетные задачи. Вот такой он, ентерпрайз…
НЛО прилетело и опубликовало эту надпись здесь
Если кому-то у вас из бизнеса надо объяснить, что с техдолгом мириться нельзя, — тоже пишите, мы умеем это нормально считать.
— Коду под сорок лет. Около 10К человекочасов техдолга на Коболе. Древние Никсы. Никто не хочет платить за грейды даже железа, которое соревнуется с нами по возрасту, про софт вообще молчим. Кобол програмки интерфейсят с миром через шелскрипты и даже курлят всякие API сервисы. Под сотню больших, средних и малых бизнесов, на каждом свои заточки и кто-то обязательно накодил маленький или огроменный скрипт на проде. 56К Модемы стоят местами до сих пор. Не Россия, даже не СНГ, дальнее забугорье.
НЛО прилетело и опубликовало эту надпись здесь
кодит прямо на проде
Лучший тестер — финальный пользователь, это всем известно. Ну и так-то можно написать скрипт без ошибок, если ты — профессионал и знаешь систему.
Заказчик — тоже немаленькая компания — накатывает релизы ERP. А прикол в том, что система такая здоровая, что на полной базе или чём-то похожем её тестировать негде. Просто нет инфраструктуры. Точнее, есть, но нельзя сделать нагрузочный тест, только мелкие локальные вещи проверяются. Релиз встаёт — и никто не знает, как он себя поведёт на деле. Один раз всё знатно так упало, когда релиз повёл себя не так, как хотелось. В итоге позвали нас смотреть, что можно сделать. Мы обсудили, что они хотят посмотреть HP Perfomance Center, сделали пилот, потом интегрировали, обучили, поставили. Теперь релизы — через него. Эти нормированные операции тестируются, сводная аналитика по SLA по операциям.
Если честно, непонятно что сделали вы такого чего не мог сделать Заказчик.
Борьба с безопасниками.
У вас это тоже присутствует. В смысле, присутствуют безопасники, которых приходится потом обходить. Вот за каким надом вместо нормальных VPN-решений для доступа к интеграционному стенду в одном из проектом вы решили Stonesoft SSL использовать?
И финальный аккорд. Кто-то ещё в одной компании кодит прямо на проде. «Тут один маленький скриптик, я знаю, что делаю».
А это не может быть последствием слишком долгих деплоев? Когда полное развертывание системы занимает 9 часов и может окончиться неудачей из-за стечения обстоятельств (привет, Sharepoint!), а работать скрипт должен был уже вчера...
Эх, производство. Задачи писали в расшаренный Excel. Начальству потребно было сделать БД где хранились бы наименования деталей, агентов, и т.п. Можно за месяц в Access полностью под себя сделать, но нет, будем покупать CRM за 10.000$+ плюс полгода внедрения… Стоило заикнуться что можно проще и под себя: был послан нахер менеджер лучше знает.
1. Откаты.
2. Ответственность. Если делаем своими силами — значит подписываемся под смертным приговором и пожизненная поддержка «изделия». Кто этого захочет? Кроме того, в случае ошибки или факапа есть на кого сослаться — это подрядчики налажали…
«изделие» собственного изготовления это всегда головная боль и все шишки на голову, поэтому менеджеры чаще и не хотят брать на себя такую ношу.
2. Ответственность. Если делаем своими силами — значит подписываемся под смертным приговором и пожизненная поддержка «изделия». Кто этого захочет? Кроме того, в случае ошибки или факапа есть на кого сослаться — это подрядчики налажали…
«изделие» собственного изготовления это всегда головная боль и все шишки на голову, поэтому менеджеры чаще и не хотят брать на себя такую ношу.
на одну болванку вообще аниме записано
Какое именно аниме? Очень интересно.
НЛО прилетело и опубликовало эту надпись здесь
писал код в Notepad.exe, потом кидал в компилятор без ошибок
Хы, я в армии написал кросс-компайлер С для БК-0010(СМ4 ЭВМ) и линкер.
Когда дембельнулся — набил это все, скомпилялось без ошибок.
Только на БК уже не нужно было переносить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Байки про суровое российское ИТ и жертв цифровизации