Россия иррациональна. Есть правильные практики, есть сто раз ощупанные грабли, но всё равно с завидным постоянством случается что-то эпическое. Иногда по причине: «Ну уж меня-то точно пронесёт», иногда: «Всегда так делали, и работало», иногда просто из-за ошибок. Возможно, в генах.
Первый яркий пример невероятной дичи (детали немного изменены по требованию безопасников). Заказчик занимается капитальным строительством. Заказал несколько лет назад у подрядчика систему, которая управляет всем этим (в частности, сметными работами). Система была установлена на десятке немаленьких объектов, внедрена. Внезапно заказчик решил потребовать выдать ему исходный код. Как оказалось, у их имеющегося подрядчика были планы на то, что они проведут разработку софта, а потом будут продавать результат как SaaS по рынку. В договоре про код ничего не сказано. Поругались.
Когда позвали нас разбираться, там было примерно 10 разных версий ПО (релизы от 0.9 до 2.4). Есть исходники 1.5, эта версия собиралась когда-то из них. Документации нет. А систему надо дорабатывать и развивать. Посчитали «переписать всё заново» и «доработать 1.5» и остановились на втором — TtM три-четыре месяца против года. Научили собирать спецов поддержки, поправили исходники, свели кодовые базы, сделали инфраструктуру, организовали одну «разливочную», куда принимается исходник, там собирается и дистрибутируется. Это стоило нам и заказчику большого количества геморроя.
Заходите, покажу ещё примерно то, как можно поошибаться с процессом разработки, и к каким интересным последствиям это приводит.
Ещё пример
Заказчик — тоже немаленькая компания — накатывает релизы ERP. А прикол в том, что система такая здоровая, что на полной базе или чём-то похожем её тестировать негде. Просто нет инфраструктуры. Точнее, есть, но нельзя сделать нагрузочный тест, только мелкие локальные вещи проверяются. Релиз встаёт — и никто не знает, как он себя поведёт на деле. Один раз всё знатно так упало, когда релиз повёл себя не так, как хотелось. В итоге позвали нас смотреть, что можно сделать. Мы обсудили, что они хотят посмотреть HP Perfomance Center, сделали пилот, потом интегрировали, обучили, поставили. Теперь релизы — через него. Эти нормированные операции тестируются, сводная аналитика по SLA по операциям.
Или вот у госзаказчика наступило импортозамещение. Бизнес приходит к нам и говорит: нам наши айтишники сказали, что заменить базу Оракл на Постгресс очень сложно. Мы им не верим, проконсультируйте. Две недели разбирательств — и результат: «Ну да, поменять базу несложно. Просто потом весь прикладной уровень придётся переписать. Немного. Примерно на 90%. У вас огромные пакеты, нужно переносить слой бизнес-логики — и приехали. Разработчиков, которые писали ядро, уже не найти, потому что системе восемь лет». Поверили ИТ-команде. Оказалось, просто недостаточно понятно аргументировали.
Где-то безопасность смотрим, вот эпический пример. К счастью, этот ещё простой, там просто никто ничего пять лет не делал, и бизнес не федерального масштаба всё же.
Следующий пример. Ставим ту же историю с приёмкой релизов. Идеальная ситуация: сторонний подрядчик пишет код, передаёт его на тестирование, проходит тесты, кладётся всё это в репозиторий, оттуда собирается и дистрибутируется. Красиво? Красиво. Мы так внутри своей компании уже года три живём без исключений (до этого были не все отделы и команды). А вот у заказчика — «фонд алгоритмов и программ». Туда каждый исполнитель отгружает болванку или распечатку исходного кода. Они там тлеют. Как оказалось в процессе аудита, на одну болванку вообще аниме записано. И даже если де-факто код в фонде есть, то толку нет.
Другой похожий заказчик. У них типовая боль — много подрядчиков. Они сделали внутриотраслевого интегратора, они проверяют, что подрядчик приносит корректный софт. Там проблемы были в том, что есть права третьих лиц (библиотеки опенсорса с вирусными открытыми лицензиями, например) — нечистоплотные подрядчики могут поставить всё это без лицензирования по порядку. В случае опенсорса ещё можно как-то заныкать проблему, но иногда попадаются и коммерческие библиотеки. Виноват кто будет — угадайте с трёх раз. Потом один их подрядчик ещё и обанкротился, а заказчику с этим кодом жить. Такие ситуации надо ловить на ранней стадии. Мы помогли настроить процесс правильно. У нас есть решение типа автоматизации фонда алгоритмов и программ. Техническая документация, версии, исходники, договоры и все ссылки на тендеры. При среднем сроке жизни ИТ-директора два-три года это очень помогает следующему разбираться сразу.
Ещё у нас в России внедряют аджайл. Я теперь в цирке не смеюсь. Почти каждый раз это начинается как модная история по цифровизации бизнеса. Главное, все пытаются понять, что это за слова. Но никто не понимает. Концепции заказывают, нанимают странных людей. Они говорят слова «кажется», «гипотеза», стартаперов приглашают, акселерацию мутят, смузи пьют — в общем, это всё имеет внешние признаки какой-то долины. Потом аджайл начинают применять, а он не взлетает. Если делаешь серьёзную систему, надо её долго проверять. Если не поставить процессы, то спринты будут долгие (месяц-два), если ставить процессы, то нужно начинать с инфраструктуры тестирования, девопса, делать конвейер поставки, процессы работы между командами и внутри команд. А это всё обычно забывают. Если процессы старообрядческие — 98%, что проект не будет сделан. В итоге потом нам разгребать и запускать. В целом мы не жалуемся: тоже хлеб. Но иногда просто хочется как-то объяснить, что ли, что ИТ — это сначала инфраструктура, а потом уже — быстрый TtM. А не наоборот.
Что обычно идёт не так? Набор примеров
Мы с коллегами собрали вот такой не очень объективный, но очень хорошо описывающий ситуацию набор ярких проблем. Понятное дело, мы ездим только туда, где плохо, и экстраполировать это на состояние отрасли не надо. Но всё же, уверен, вы узнаете что-то и от своей компании. Небольшую часть. В целом всё описывается словами: «неэффективность процессов, немотивированные сотрудники, плохие инструменты или плохо используемые инструменты». Ну а теперь — примеры.
1. Штраф за ошибки в ПО, внесённом разработчиками.
Я даже не знаю, как это рационально описать. Просто штраф за выявленные баги. Живите теперь с этим знанием. Естественно, любой релиз (даже мелкий) выпускается в десятки раз медленнее, чем мог бы.
2. Собрания с утра до вечера.
Разработчик должен на них присутствовать. Он молчит и кивает головой в трубку. Это те самые встречи, когда на совещании нужна вся проектная команда и плюс руководитель отдела, чтобы контролировать. Нельзя не прийти. Но смысла от участия почти нет. Это традиционная ошибка руководителя проекта, называется «избыточный контроль».
3. Карго-культ. Берём гибкие методологии и жёстко их внедряем.
Лучшее, что я видел: внедрили аджайл, но работали, как раньше. Только заставили разработчиков приходить на ежедневный стендап. Они строятся и рассказывают: я ничего не сделал. Это происходит изо дня в день.
4. Инструменты: внедряем, чтобы отчитаться, что внедрены.
«У нас есть Continious Integration-сервер, а задачу может добавить только администратор». «У нас внедрили хранилище бинарных сборок, а там очень маленький диск, надо удалять старые, и там только последние три версии». Или вот: система ведения задач в эксель-файле на пошареном диске. Так бэклог часто ведут даже в больших компаниях, при том, что есть и Jira. При этом пока задача не попадёт в этот файл, никто делать не будет. Он официальный.
В другой компании есть внутренняя база знаний, но всё подряд хранят прямо в системе контроля версий: менеджеру так удобнее. Дистрибутивы операционки туда даже складывают. Когда нет ответственного за систему контроля версий, менеджеры могут положить гигабайтные файлы, чтобы передавать их контрагенту, потому что в Дропбоксе место кончилось.
5. Стандарты кодирования: написаны без понимания или не обновлялись 10 лет.
Просто пара примеров: требуем 100% покрытия кода тестами и документацией. В частности, всех сторонних библиотек. Обратная сторона — отсутствие стандартных тестов. Недавно видел, как инженер развернул систему, а пользователь не может войти, потому что ключ с теста на прод не поменяли.
Ещё один раз видел, как руководитель писал код в Notepad.exe, потом кидал в компилятор без ошибок. Он с перфокарт ещё учился. Такой навык, конечно, заслуживает уважения. Но только до тех пор, пока эта профдеформация не начинает влиять на стандарты для остального отдела разработки.
6. Ошибки регламента.
Например, фиксированное время обеда, которое выгуливается полностью. Это симптом. Спрашиваю, почему. Объясняют: если ты на рабочем месте сидишь в обед, то ты мишень. Должен отвечать на письма за пять минут и так далее.
Излишняя бюрократизация: частое следование документированным процедурам, которое ведёт к куче бумаги. Те же тестпланы на каждый чих. А это описание каждого фильтра, в том числе типы данных в каждом поле интерфейса, длина поля и так далее. Обычно это решается примерами, а не полной детализацией.
В одной компании не было человека с ответственностью за актуальный релиз, иногда срывались сроки по выпуску продуктов на две недели.
Коммуникации: приходит что-то от заказчика в почте. Причём пишет он тому, кто последний с ним общался. Даже если хочется это сделать, комментарии к задаче могут быть в разных местах, включая мессенджеры. Потом кто-то ушёл, кто-то пришёл, кому-то удалили почту — всё.
7. Борьба с безопасниками.
Сюда входят ручные обновления всех систем (а надо автоматически разливать, это экономит кучу времени), физические обходы с флешкой по узлам сети, выделение портов по три недели и так далее.
8. Не налажены коммуникации между разработчиками и аналитиками.
Это настолько детский косяк, что повторяется на каждом пятом проекте. Просто аналитик написал, что нужно, разработчик разработал и через месяц показал готовое. Аналитик бегает в ужасе, потому что он имел в виду не это. Три недели из этого месяца разработчик работал зря, хотя мог бы показать часть проекта, а аналитик мог бы поинтересоваться, как там дела. Есть методологии, которые это просто закрывают, но проблема в том, что в данной ситуации обе стороны не понимают, зачем нужен проект, и как он идёт.
9. Конференц-дривен девелопмент.
Руководитель увидел что-то крутое на конференции, и это без оглядки внедрили. Через три месяца повторили. В итоге в отчёте красиво, а работа стоит.
Из-за внутренних конференций ещё бывает доведение до результата по схеме «Всегда на 80% готово». На публичных отчётах — «Почти готово», и это бесконечно. Доведение до 100% никогда не случается. Почему? Ну, например, смотрите пункт 1.
Отдельно отмечу недообследование сторонних систем. Читаешь статейку — вау, круто, давайте использовать, а потом только изучаешь, как. И сталкиваешься с массой ограничений, потому что вендор мёд в уши лил только на первых двух встречах. Мы тут сами наступили на грабли. Было внутреннее внедрение системы для интернет-магазинов документации по проектированию инфраструктур, в т.ч. ЦОДов для очень интересных объектов. Обнаружился кейс ограничения стоимости товара в 100 миллионов. Фишка в том, что по предметной области цены на единицу документа выше. И там же система должна была перелопатить для поиска индекс, а у нас есть вложения по 1 гигабайту в документы. И ожидаемое время индексации — один месяц. Вендор про такое не предупреждал.
10. Страшно вносить изменения.
Есть такое состояние проекта: нужен рефакторинг, приходите через месяц. Но при этом ни тестов, ни документов, ничего нет. И разработчики сидят: «Мы боимся вносить изменения, мы боимся всё поломать».
Ещё я видел, как в одной компании разработалась интеграция с системой, которую нельзя развернуть на стороне разработчика, потому что она очень тяжёлая. Тестировщики тестируют на передачу данных сервисом (насколько можно). Выход на стенды заказчика перед сдачей — и ещё две недели доработок, потому что модель транзакций была неправильная. Правильная практика — сделать заглушку для этой системы, которая возвращала бы какие-то ответы. В итоге так и сделали, стало проще тестировать и принимать.
Ещё заказчик может писать экономические описания на привычном ему языке. На том проекте мы дали некий псевдоязык-конструктор (набор стандартов), который потом конвертируется в данные аналитиков. В духе «Если Ваня на больничном, то он не сможет пойти на производство».
И финальный аккорд. Кто-то ещё в одной компании кодит прямо на проде. «Тут один маленький скриптик, я знаю, что делаю». Спасибо тебе, милый человек, но если я тебя найду, то даже не знаю, что с тобой сделаю.
В общем, высказался. Если узнали свои проблемы — пишите в почту oeremeev@croc.ru. У нас для крупного бизнеса есть почти бесплатные пилоты с экспресс-диагностикой (поиски бутылочных горлышек за 3-5 дней). Если кому-то у вас из бизнеса надо объяснить, что с техдолгом мириться нельзя, — тоже пишите, мы умеем это нормально считать.
Комментарии (70)
dom1n1k
25.07.2019 10:17+1Внезапно заказчик решил потребовать выдать ему исходный код. Как оказалось, у их имеющегося подрядчика были планы на то, что они проведут разработку софта, а потом будут продавать результат как SaaS по рынку. В договоре про код ничего не сказано.
Я помню, нам в универе говорили, что в России по какому-то там госту-шмосту (ссылку не дам, не помню) при заказной разработке ПО исполнитель обязан передать заказчику исходники по умолчанию. И как по мне, это абсолютно правильно.
alexxisr
25.07.2019 11:15А что делать, если я прямо в машинных кодах пишу? Распечатка хекс-кодов за исходники сойдут?
AbstractGaze
25.07.2019 13:02Если вы исполнитель заказа, то вы подписались не только его выполнить, но и выполнить на прописанных в договоре условиях.
alexxisr
25.07.2019 14:36Мы тут обсуждаем случай когда в договоре не прописана обязанность передавать исходники.
Правомерно ли тогда требование заказчика предоставить исходные тексты ссылаясь на законы РФ? И может ли исполнитель отказать, говоря что он руками байты в екзешник пишет?
metalim
25.07.2019 19:13Если он и правда руками байты пишет, то должен выдать экзешник, как исходник. Другое дело, что если он не руками байты пишет, то это обман заказчика и преследуется уже по другой статье (ну или ректальным криптоанализом, если в людях ошибся).
AbstractGaze
26.07.2019 07:59С каких пор ГОСТ чему либо обязывает и стал законом РФ?
Гост это соответствие определенным требованиям, но если вы не делаете по госту, то можете и не соответствовать. А делаете или нет, это как раз у вас и будет указано в договоре.
AbstractGaze
26.07.2019 08:48Исходики это «служебное произведение» в результате выполнения договора не выходящее за его рамки? Да. Значит принадлежит заказчику по умолчанию. А чем он пишет это не важно, пусть хоть как некоторые художники кисточкой вставленной в причинное место это делает.
juray
26.07.2019 10:41Служебное произведение — это произведение, созданное работником в рамках своих трудовых обязанностей
Договор подряда (а речь именно о нём, судя по терминам Заказчик и Подрядчик) — это не трудовой договор, даже если подрядчик — физлицо.
Raspy
25.07.2019 13:02Абсолютно любой носитель сойдёт. Даже распечатка хекс-кодов. Вы главное передайте.
yoshka
25.07.2019 14:07+1Меня как-то раз просили сдать в архив распечатанный дамп базы. Вот прямо в бинарном виде. База была средненькая, гигов на 100. Но архивариуса вполне устроили 50 листов распечатанной абракадабры.
mitnlag
25.07.2019 17:02+3Вместо организации подлога нужно было просто написать служебку следующего характера:
Дамп базы = 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.
Думаю, архивариус был бы счастлив принять правильное решение, а Вам не пришлось бы подставляться :-)yoshka
25.07.2019 18:08Была подобная мысль, начальник отговорила. Вот как раз 50 листов с устным пояснением, что это < 1% от целевого результата убедили архивариуса, что не стоит доводить начатое до конца.
Но ей надо что-то предоставить в случае ревизии? У нее регламент. Пришлось идти «на подлог».
Это было в те прекрасные времена, когда каждое «электронное письмо», даже если это вообще не письмо, а передача файлов по шифрованной сети, требовалось распечатывать и сдавать в архив вместе с вложениями. Со временем нормативные документы переделали.
PeterK
25.07.2019 17:40-1Вы не пишите в hex-кодах. Я даже думаю, что Вы их не знаете.
androidovshchik
26.07.2019 07:12+1Можно писать. Я, например, часто на smali пишу, да не такой сложный, но все же машинный язык тоже
rum
25.07.2019 20:08+1в ГОСТ 19.401-78. ЕСПД допускается:
символическая запись на исходном языке;
символическая запись па промежуточных языках;
символическое представление машинных кодов и т. п
Если кратко, да сойдут. Но это, если в договоре указано обязательное исполнение ГОСТ. А так могут что угодно прописать, хоть на камне высечь, если не расходится с действующим законодательством
garageman
27.07.2019 01:34Помню байку… Один ИП (индивидуальный предприниматель) выкатил претензию банку. Претензию выгравировал на гранитных плитах. ИП изготавливало надгробия, так что работа привычная. И выгрузили стопку "листов" на крыльцо краном.
Alexeyslav
25.07.2019 15:30+1Сейчас передавать исходники… этого мало, очень мало! Нужны ещё инструкции по компиляции и сборке, а так же по внутренней модели данных и базу с системными настройками. Исходники — ничто, если нет базы. База без магических настроек — ничто…
samizdam
25.07.2019 20:41Infrastructure as code, Configuration as code…
Под СКВ должно находиться всё необходимое для развёртывания приложения в любом окружении с нуля, после клонирования. Не знаю насчёт передачи кодов и ГОСТов, по мне это современный, и единственно разумный подход.
Благо инструментарий для поддержки такой концепции очень активно развивается последние годы.
saboteur_kiev
26.07.2019 02:26+2Ну вот сделает вам подрядчик проект с teamcity DSL прямо в коде. Где все настроено просто отлично, с автотестами, с автоматическом разворачивании тестовых окружений в облаке и так далее.
Но вот у вашей компании лицензии на тимсити нет, аккаунты у вас в AWS а не гугл клауд — надо сильно переделывать, и вообще в Котлине, на котором Teamcity хранит свои настройки никто не разбирается, потому что проект на Nodejs, и что вы локально будете делать?samizdam
26.07.2019 07:55Вот по этим причинам я предпочитаю не использовать тимсити. Другие современные ci системы как раз ориентированы на полное управление продуктом и процессами через репозиторий.
Конкретно в приведённом вами примере, лично я, в зависимости от роли. Договариваться с подрядчиком на берегу о критериях приёмки, либо вытаскивать проект из богомерзкого тимсити.
saboteur_kiev
27.07.2019 10:15Вот по этим причинам я предпочитаю не использовать тимсити. Другие современные ci системы как раз ориентированы на полное управление продуктом и процессами через репозиторий.
Ну вот сделает вам подрядчик проект с teamcity DSL прямо в коде
Тимсити ТАКЖЕ как и другие CI системы может и умеет хранить все процессы в репозитории. Я же упомянул DSL. Тимсити даже поддерживает Котлин в качестве языка, на котором можно писать пайплайны и описание джобы, чтобы легко и автоматически создать проекты и таски в ней на другом тимсити с нуля.
Инфраструктура-как-код — это означает, что она поддерживается как код — удобно, с версионированием, с централизированным хранением и простым способом бэкапа.
То есть переразвернуть какие-то части с нуля можно быстро, и даже автоматизировано.
Но инфраструктура-как-код не означает, что ее можно очень легко можно поднять и развернуть в другой компании. Бывает даже наоборот — если все переехало в код, многие уже и не знают как вообще собрать продукт без этого. А это означает что прежде чем настроить с нуля в других условиях, нужно глубоко разобраться в предыдущем коде.
saboteur_kiev
26.07.2019 02:24+2Иногда исходники — это просто исходники.
А инфраструктура, на которой все это пишется, собирается, откатывается — это отдельная часть, которая к исходникам продукта отношения не имеет.
И отдавая исходники, ты понимаешь что для того, чтобы банально собрать и протестировать продукт — там нужно будет потратить месяц работы девопса или нормального архитектора, чтобы разобраться что к чему.
IsyanovDV
26.07.2019 03:06+1Вообще, не оговорить в договоре историю с исходниками и правами на использование результатов разработки — это верх некомпетентности.
adictive_max
26.07.2019 05:16Тут ещё такая прикольная тонкость есть, что исходники и права интеллектуально собственности на исходники — это очень сильно не одно и то же.
saipr
26.07.2019 10:56Ну не в России, а в СССР. А еще был в г. Калинине Фонд Алгоритмов и Программ, из давались сборники, хранящегося в этом фонде. И все это не чета нынешнему реестру отечественного ПО.
lexnekr
25.07.2019 11:16Прикол часто в том, что ваш (или чей угодно ещё) пилот не нужен. Люди, которые «работу работают» и так знают о бутылочных горлышках. Если вы сделаете пилот, то эти самые люди станут виноваты в этих бутылочных горлышках (ну не начальство или владельцы же, в самом деле).
OEremeev Автор
25.07.2019 12:42Штука в том, что к большой радости, уровень осознанности людей растет. И многие руководители не ставят перед собой цель искать виноватых, это не приближает их к результату в виде качественного конечного продукта/сервиса и тд. Им-то по голове стучат огого как за невыполненные комиты. И они это понимают. Поэтому фокус у них на оптимизации инструментариев/процессов и повышения эффективности тех ресурсов, которыми они обладают. И это реально рабочая история.
lexnekr
25.07.2019 13:16Если бы это было так, то ситуация разрешалась бы опять же без вашего участия. Повторюсь, «рабочие руки» в большинстве случаев знают в чём проблема.
Или вы думаете, разработчик, который пишет на проде рад этому? А может у него просто теста нет?
А теста у него почему нет? Может потому, что в организации надо написать какую-то макулатуру вроде «технического решения», где описать сетевые структуры и т.п.?
И почему же нет этого «важного и полезного» документа? Уж не потому ли, что разработчик должен его сам выродить, а все окружающие будут кривить морды и говорить «ой, тут что-то не по корпоративным политикам, тут что-то не понятно...»
А документы надо согласовать может потому, что там «самый большой» захотел? Или потому, что бардак вокруг и не понятно где-что-почему-как работает, и люди прямо на прод пишут код?
Вот он и замкнулся цикл. И все прекрасно всё знают. Но очередные «аджайлы по-русски» (прямо как у вас и описано) появляются, усугубляя ситуацию.OEremeev Автор
25.07.2019 16:55Все, что вы пишете — правда. Это мы видим сплошь и рядом.
Но то, что пишу я — тоже правда.
И тут нет конфликта.
Просто надо понимать, что для формирования потребности что-то поменять должны быть предпосылки. Она (потребность) не возникает на пустом месте и просто так. И «рабочие руки» в вашем примере зачастую не всегда могут эту потребность даже начать формировать. Ввиду разных обстоятельств (все устраивает, а сейчас заикнусь меня потом крайним сделают, что я умнее других? и тд). Потому что подсознательно каждый из нас понимает, что изменения устоявшегося положения дел, это не всегда приятно, а, как правило, наоборот.
Потребность формируется уровнем выше под постепенным давлением того, о чем вы написали. И процесс этот не мгновенный. Но когда люди понимают, что что-то не так, они начинают эту историю копать и разбираться. Кто-то сам, кто-то приходит к нам. И мы помогаем.lexnekr
25.07.2019 18:04Нет, я же не спорю, что у нас менталитет такой, что «варягам» доверия больше, чем своим. И то что «Ванька» скажет — от того лишь отмахнутся, а когда тоже от «консалтеров/интеграторов великих и могучих» (а лучше ещё заморских) — то сразу надо тому же «Ваньке» на вид поставить и заставить сделать.
Тут не про потребность. А про то, что от пилота в вашем описании пользы для людей на местах действительно не будет. Будет только головная боль.v2kxyz
26.07.2019 09:26Все очень зависит от того как этот пилот будет проходить. Если, как часто бывает, придут консалтеры напишут много умных слов и уйдут — то да будет головная боль. Так как любая «лучшая практика» во-первых, все лишь рекомендация, а не строгий закон, во-вторых имеет границы применимости, т.е. пост и пред-условия, без выполнения которых превращается в цирк. А если консультанты постараются подружиться с людьми на местах и будут планомерно внедрядть новые процессы, то может и выйдет толк. Причем «подружиться» это, ИМХО, ключевое — иначе местные будут невольно саботировать процесс — никто не любит когда их учат наставлениями и приказами.
Про внедрение лучших практик у меня есть два примера — обе «внедрялись» с подачи заморского интегратора.
Первый про документацию — нужно документировать разработки производиемые в ERP(SAP). Вроде и нужно и даже полезно, результат — куча docx файлов в хранилище без индексации и поиска. Причем в этих файлах содержались по сути pull-requests(только к коду никак не привязанные), они не были поделены ни по бизнес-процессам, ни по модулям в системе, один и тот же класс мог упоминаться в десяткаях разных документов(про SOLID там никто не слышал). То есть если берешь какой-нибудь бизнес-процесс или кусок сервисного кода и пытаешься найти к нему документацию — то это бесполезная потеря времени.
Второй — аджайл, все круто, только заказчику забыли рассказать что это и зачем, а заказчику этот ваш MVP даром не сделася, ему подавай готовую систему, которую писать год минимум и она за это время естественно устареет. Хотя бы митинги с «я ничего не сделал» быстро отменили.lexnekr
26.07.2019 09:38Из статьи:
пилоты с экспресс-диагностикой (поиски бутылочных горлышек за 3-5 дней)
Внедрения, о котором вы говорите в их пилотах, по-моему нет.
MikeLog
27.07.2019 02:23очень часто разрабы выпрашивают тест окружение, а потом хренакс и оно становится продакшен без объявления войны, причем, что оно стало продакшен становится известно, когда разрабов попросили освободить тестовый стенд
Crimento
25.07.2019 11:441. Штраф за ошибки в ПО, внесённом разработчиками.
Штрафы, это, конечно, жестоко, но что плохого в том, что код перепроверяется вдоль и поперёк перед релизом вместо тестирования на проде и десятка патчей следом? Даже если в ущерб скорости разработки.SuperProg122
25.07.2019 11:54Да, но кого штрафовать? Может, это менеджер наседал, мол, давай быстрее в прод, времени нет?
Или тестировщик не проверил?
Или аналитик неправильно расписал?
Может, человеку вообще угрожали увольнением по статье и запугали, чтобы он побыстрее в продакшен вытащил?
Да и любое ПО содержит ошибки. Все это знают. Мы лишь стараемся уменьшить количество ошибок, но не можем от них полностью избавиться.
SwingoPingo
25.07.2019 12:23штрафуют подрядчика поставщика кода, как он убытки будет в своей системе распределять его головняк. Но «попытки решить задачу» должны стоить дешевле чем «решение задачи». Если в договоре у вас «решение» и вы за «решение» платите и подрядчик деньги уже получил, то «процесс решения» это несколько иное. И он изначально оценился бы по другому. Или хотя бы предупреждайте по человечески заказчика что код не тестировали и стоимость тестов в продакшене прогнозируется меньше стоимости тестирования в разработке, что бы заказчик хотя б забекапился посерьезнее.
ntrike
25.07.2019 11:53+1- Штраф за ошибки в ПО, внесённом разработчиками.
- Естественно, любой релиз (даже мелкий) выпускается в десятки раз медленнее, чем мог бы.
Вы хотели сказать что софт в кои-то веки начали нормально тестировать? Ну а не как обычно -«время программиста дороже аппаратных ресурсов и релизы должны быть каждый день» и в продакшн.
SuperProg122
25.07.2019 12:14+1В общем, высказался. Если узнали свои проблемы — пишите в почту oeremeev@croc.ru. У нас для крупного бизнеса есть почти бесплатные пилоты с экспресс-диагностикой (поиски бутылочных горлышек за 3-5 дней). Если кому-то у вас из бизнеса надо объяснить, что с техдолгом мириться нельзя, — тоже пишите, мы умеем это нормально считать.
Я помню, у меня на одном месте работы основная проблема была в том, что выдали компьютер с глючным wifi адаптером, который постоянно зависал и терял сеть. Сколько я не просил его починить, в ответ слышал только крики и истерики. Вплоть до CEO доходило.
Ну вы же понимаете, что ни один CEO никогда не признается, что не смог организовать даже закупку техники.
smbsmn
25.07.2019 13:01Кто-то ещё в одной компании кодит прямо на проде. «Тут один маленький скриптик, я знаю, что делаю». Спасибо тебе, милый человек, но если я тебя найду, то даже не знаю, что с тобой сделаю.
Такое в некрупных компаниях запросто может быть.
Если бизнес устраивает, что в штате есть только программист(ы) и сисадмин(ы) — почему нет?
Зависит от масштаба.
dss_kalika
25.07.2019 14:19+1Да и в крупных…
В общем то — в почти любых, где требуется максимальная скорость исправления косяков.
Я, как то, на собеседовании одном долго слушал о том, как поставлен процесс разработки, сколько кругов ада проходит задача для деплоя, как разработчики всё делают исключительно на тестовой среде… а потом:
-Ну, на прод у разработчиков есть доступ?
-(потупив глазки) Есть, конечно… надо же как то факапы фиксить.yoshka
25.07.2019 15:14А максимальная скорость исправления косяков требуется именно там, где болт положен на тестовую среду. Когда прод физически недоступен (например, посреди тайги на военной базе), то тестовая среда будет содержать уйму тест-кейсов, собираемых от пользователей, с нагрузочным тестированием. А когда можно что-то «быстренько» поправить, то тестовая среда заброшена, с устаревшими данными и т.п. В результате получается разработка через «авось»: ну на стейджинге вроде запустилось, а на проде проверим. Если что, поправим.
dss_kalika
25.07.2019 15:40+1Максимальная скорость исправления косяков требуется везде где требуется, независимо от положен болт на тестовую среду или нет. Чаще всего эта необходимость пропорциональна количеству денег/эквивалента денег которые теряются в случае факапа за время факапа.
А факапы на проде случаются. Количество тестов и прочей шелухи может их количество снизить, но не до 0%.
Соответственно и протокол по скорейшему решению таких проблем должен быть. И тут уже начинается компромис между скоростью, доверием к профессионализму сотрудникам и «штатным порядком деплоя»… и бизнес выбирает первое обычно.
Так и получается, что человек, разрабатывающий данный функционал, как человек, которые быстрее и чётче всех может исправить ошибку, наделяется правами для экстренного фикса прода.
И ничего о том, что тест заброшен или с устаревшими данными или про авось тут нет. Просто прагматика.
Если бизнес готов к исправлению критического или не очень бага через значительное время или оплате кроме дежурного программиста ещё и команды дежурных тестировщиков и QA — это хорошо, но что то я такое не часто видел (бывало, конечно, но обычно это или компании которым в достаточной степени всё-равно на клиентов или с оооочень толстым бюджетом).
ЗЫ: но есть, конечно, большая разница между «разработка на проде» (да, это чертовски сурово) и «доступ для хотфикса» (в известной степень допустимое решение). Из статьи непонятно к какому случаю относится «скриптик», но выглядит как хотфикс. )grinCo
25.07.2019 19:43Не понимаю зачем доступ на прод для хотфикса?
v2kxyz
26.07.2019 09:31А потому что не у всех есть инфраструктура деплоя. Часто выглядит так — деплоим редко(не аджайл ага), поэтому инфраструктуру автоматизировать не будем. Зато когда деплоим, то вылезает куча косяков, которые нужно фиксить вот прямо сейчас.
Есть еще вариант, если пойти через имеющийся DI, то придется писать объяснительную какую, а если напряму в проде, то почему-то — не придется.
dss_kalika
26.07.2019 11:30Окей, а какие варианты? )
Провести полный цикл деплоя с тестированием,QA и прочими прелестями?
Для этого нужны люди (которые могут отсутствовать на рабочем месте, а их присутствие в виде дежурных — деньги и время), и время.
А если деплой полностью автоматический, то разницы в правках на тесте или на бою, в общем то нет, по большому счёту. (но тут ещё может быть косяк в самой системе деплоя или данных на бою и тогда ТТ).grinCo
26.07.2019 20:21Для ясности — я говорю о серьезных конторах, а не о начинающих стартапах и бизнесах с одним-двумя разработчиками.
1) Полный цикл деплоя занимает меньше времени, чем правка на проде руками.
2) Доступа на прод у разработчиков нет, а девопсов которые умеют в программирование три с половиной человека.
Если у вас не так, то у вас проблемы.
Например, из реального. Программист поправил код на проде (питон скрипт) в пятницу вечером и пошел домой. А после него провели релиз, его изменения затерли — и сайт все выходные неправильно обрабатывал данные. Тут сложились сразу несколько ошибок — код не был закомичен в cvs, доступ девелопера на прод, правка руками на проде, пятница, релиз. И можно сказать, что его ошибка что он не закомитил, что у нас хорошие разработчики, они так не сделают. Но если вы менеджер проекта, тим лид или просто разработчик который общается с бизнесом, вы понимаете что это риск.
PS Статья и коменты показали в каком плачевном состоянии индустрия.
DrunkBear
26.07.2019 11:24Был случай, когда всё отлично отработало на тестах, было показано заказчику, заказчик похлопал в ладоши, развернули на проде у заказчика… И ничего не работает.
Потому что на тест заказчик выдал старую структуру БД с невалидными данными, а ключевые колонки в таблицах молча обрезал и не сказал об этом.
Потому что там секретные данные, их нельзя передавать. И sha2 к ним нельзя. И забить случайными данными нельзя, потому что секретно.
Пришлось пепеписывать и тестить на месте — и фронт, и бэк.
Зато какой чудесный код, когда приходит Высокое Начальство и в честь праздника наливает… Отказаться нельзя — оскорбление начальства. Не кодить нельзя, нужно срочнобыстро доделать, заодно и показать, что мы делаем всё возможное.
tonad
25.07.2019 16:58Живой пример.
Интеграция. Функционал на создание/обновление бизнес объектов с именем по определенному паттерну.
2 месяца разработка-тестирование
Клиент посмотрел, сказал все отлично, но паттерн нужно немного поменять.
Паттерн захардкожен, так как зависит от многих параметров, и не должен в принципе меняться.
Решение — скриптик обдейта в базе. Что в этом плохого?
imanushin
25.07.2019 19:30Например, hh.ru, судя по их статье, практикует подобное. Если верить wikipedia, в декабре у них было 683 сотрудника (не знаю, насколько это много или мало).
astenix
25.07.2019 16:44+1Олег, это же не документация.
Ну, например, смотрите пункт 1.
А чём там говорилось? Аффтар верит, что я помню все эти пункты?
Ок, надо пролистать к пункту 1. А где же он? Не в начале текста. Абзац, абзац, абзацина со перечнем страшных ужасов разработки… а, вот. Про штрафы за баги.
Теперь надо вспомнить, где я был в тот момент, когда этот чёртов первый пункт был упомянут…
Да ёпт!
А потом они ходютЪ и говорят, что у кого-то процессы не налажены…
amaksr
25.07.2019 17:01Штраф за ошибки в ПО, внесённом разработчиками.
Недавно расследовал баг, что именно это и захотелось сделать: код вызывал SQL с картезианским джойном, получал в сотни раз больше записей, чем было в таблицах, а пототм средствами Java избавлялся от дупликатов. Код писал подрядчик, который специализируется на Java-разработке, крутые ребята, если не брать во внимание этот прокол. До сих пор ломаю голову, как такое может быть написано человеком…
Клиент, кстати, сказал пока не фиксить, так как есть более приоритетные задачи. Вот такой он, ентерпрайз…
OlgaShrpva
25.07.2019 19:04При чем тут Россия? Да при том, что без нее ни туды и ни сюды. Мир пропадет без России)
Assimilator
25.07.2019 20:03+6Если кому-то у вас из бизнеса надо объяснить, что с техдолгом мириться нельзя, — тоже пишите, мы умеем это нормально считать.
— Коду под сорок лет. Около 10К человекочасов техдолга на Коболе. Древние Никсы. Никто не хочет платить за грейды даже железа, которое соревнуется с нами по возрасту, про софт вообще молчим. Кобол програмки интерфейсят с миром через шелскрипты и даже курлят всякие API сервисы. Под сотню больших, средних и малых бизнесов, на каждом свои заточки и кто-то обязательно накодил маленький или огроменный скрипт на проде. 56К Модемы стоят местами до сих пор. Не Россия, даже не СНГ, дальнее забугорье.
epishman
25.07.2019 20:27Насколько я понимаю, ERP можно протестировать только нагрузочно, так как полный набор функциональных тестов на все комбинации исходных данных будет стоить как сама ERP.
Heian
25.07.2019 21:57кодит прямо на проде
Лучший тестер — финальный пользователь, это всем известно. Ну и так-то можно написать скрипт без ошибок, если ты — профессионал и знаешь систему.epishman
26.07.2019 00:47Вообще тестировщик должен быть грамотней программиста в предметной области, попробуй протестировать функцию (x) => 1/x если у тебя двойка по математике. Тестирование в особых точках — отдельная наука, а без нее большинство модульных тестов — просто дань моде, еще и небесплатная.
9660
26.07.2019 05:52Заказчик — тоже немаленькая компания — накатывает релизы ERP. А прикол в том, что система такая здоровая, что на полной базе или чём-то похожем её тестировать негде. Просто нет инфраструктуры. Точнее, есть, но нельзя сделать нагрузочный тест, только мелкие локальные вещи проверяются. Релиз встаёт — и никто не знает, как он себя поведёт на деле. Один раз всё знатно так упало, когда релиз повёл себя не так, как хотелось. В итоге позвали нас смотреть, что можно сделать. Мы обсудили, что они хотят посмотреть HP Perfomance Center, сделали пилот, потом интегрировали, обучили, поставили. Теперь релизы — через него. Эти нормированные операции тестируются, сводная аналитика по SLA по операциям.
Если честно, непонятно что сделали вы такого чего не мог сделать Заказчик.
mayorovp
26.07.2019 09:30Борьба с безопасниками.
У вас это тоже присутствует. В смысле, присутствуют безопасники, которых приходится потом обходить. Вот за каким надом вместо нормальных VPN-решений для доступа к интеграционному стенду в одном из проектом вы решили Stonesoft SSL использовать?
И финальный аккорд. Кто-то ещё в одной компании кодит прямо на проде. «Тут один маленький скриптик, я знаю, что делаю».
А это не может быть последствием слишком долгих деплоев? Когда полное развертывание системы занимает 9 часов и может окончиться неудачей из-за стечения обстоятельств (привет, Sharepoint!), а работать скрипт должен был уже вчера...
Nubus
26.07.2019 15:12Эх, производство. Задачи писали в расшаренный Excel. Начальству потребно было сделать БД где хранились бы наименования деталей, агентов, и т.п. Можно за месяц в Access полностью под себя сделать, но нет, будем покупать CRM за 10.000$+ плюс полгода внедрения… Стоило заикнуться что можно проще и под себя: был послан нахер менеджер лучше знает.
Taciturn
26.07.2019 15:34-1на одну болванку вообще аниме записано
Какое именно аниме? Очень интересно.
JustDont
Остался только вопрос — а при чём тут Россия?
Я за свои 10+ лет работы на серьезную компанию в США своими глазами видел наборы очень похожих историй. Кровавый энтерпрайз везде одинаковый вообще. И аджайл там тоже внедряют так, что в цирке потом никто не смеется.
OEremeev Автор
Вы правы, Россия в этом смысле не уникальна. И в том-то и дело, что следуя за мировыми трендами, зачастую с некоторой задержкой, никто не утруждает себя тем, чтобы взглянуть по сторонам и принять во внимание опыт тех компаний, которые уже прошли этот путь и набили шишки.
Почти уверен, что такие поведенческие паттерны свойственны и США и Европе, но мы живем и работаем в России.
IsyanovDV
В Японии не лучше ))) (а то и хуже чем в некоторых российских компаниях).
nicholas_k
Так это русская национальная привычка такая. Начинать с «Только в России...», а после указания на то, что в других странах тоже не всегда хорошо, лучшая отмазка «Я живу в России, меня волнует Россия».
German1984
Уверенны, что только в России это национальная привычка?
dzsysop
clickbait
bisquitie
Вот, да. И в UK-, и в US-компаниях ещё не такого навидался.