Вы были здесь прежде. Ваша программа элегантна. Вы использовали точно требуемое количество абстракций. Ваши модули безупречно модульные. Ваша система имеет дело с внешним миром через продуманные интерфейсы и не имеет никакой прямой зависимости от внешних систем. Ваши тесты пройдены безукоризненно. Ваш отчёт о покрытии тестами кода требует целую минуту для загрузки. 97% это значит…
Жизнь прекрасна. А затем происходит нечто.
Продуктовый менеджер врывается и заявляет, что в обновлении, отправленном вами на прошлой неделе, обнаружен баг. Всякий раз, когда пользователь добавляет какую-то позицию в свою корзину для покупок, счётчик, который предназначен для показа количества позиций в этой корзине, обновляется лишь через несколько секунд. А раньше обновление происходило мгновенно.
Менеджер сообщает, что жалобы от пользователей идут потоком. И он спрашивает: «Можешь ли посмотреть?».
Конечно, вы можете посмотреть. В конце концов, именно вы создали этот продукт. Это, скорее всего, вина кого-то другого. Но вы собираетесь устранить ошибку. Это — часть работы своего рода «кризисного» сотрудника, которым вы и являетесь.
Вы вытягиваете Git hash из самого последнего релиза и копаетесь в журнале изменений. Вы обновили библиотеку HTTP-запросов до самой последней версии в последнем релизе. Это и так откладывалось довольно долго. Вы можете вспомнить коммит, который привёл к этому. Это был хороший день.
Вы переключаетесь на коммит, затем имитируете запрос, который обновляет корзину для покупок. Хорошо, что у вас есть такое чёткое разделение задач. Можно легко провести тест на вспомогательном и продакшен серверах с продвижением флага сборки.
Вы нашли преступника. Похоже, что HTTP библиотека, которую вы обновили, имеет дефект. Для определённых типов запросов ей требуется довольно много времени, чтобы проанализировать поступающее информационное наполнение в формате JSON. Ваше приложение может обновить пользовательский интерфейс счётчика корзины для покупок только после того, как информационное наполнение запроса проанализировано. Инфраструктура не настроена для обработки возможной согласованности и добавления того, что могло бы быть отдельным проектом само по себе. Вы не можете просто обновить счётчик локально и засинхронизировать позднее.
Вы знаете, что кто-то, не вы, допустил ошибку. Такова жизнь.
Вы информируете менеджера о случившемся. Он одобрительно поздравляет вас. Он говорит, что, конечно, всегда знал, что на вас можно положиться. Он спрашивает, известно ли, как устранить этот баг?
Ну, конечно! Вы уже рассмотрели все возможности.
Откатить по изменениям невозможно. Весь новый код и исправления багов завязаны на новую версию библиотеки. Вы потеряете также их все, если просто откатите всё назад.
Просто форкнуть эту библиотеку и работать с вашей собственной копией также не представляется разумной идеей. Эксплуатационный персонал исходного проекта имеет гигантскую тестовую инфраструктуру, которая протестирует ваше исправление на тысячах устройств. У вас же имеется три устройства, на двух из которых стоят устаревшие версии операционной системы. Лучше всего получить обратную связь от них также. Это же, в конце концов, их библиотека, и они должны знать её устройство, а не вы.
Итак, действия спланированы:
- Форкнуть библиотеку;
- Внести исправление;
- Отправить запрос на включение кода в репозитарий оригинала;
- Тщательно обсудить ситуацию с эксплуатационным персоналом;
- Наконец убедить их в том, что ваша идея является наилучшим решением;
- Выполнить восходящее слияние изменений;
- Дождаться релиза библиотеки с устранённой ошибкой;
- Обновить библиотеку в вашей программе;
- Выдать новый релиз.
Всё элементарно, Ватсон!
«Замечательно», — говорит вам менеджер. «Сколько по-твоему это потребует времени?».
Вы знаете ответ. Некоторые думают, что технические специалисты неспособны оценить время. Но вы-то точно не из таких специалистов.
«2 недели» — без запинки отвечаете вы. «Зависит от того, как быстро будет принят запрос на включение кода и как быстро эксплуатационный персонал выдаст новую сборку».
Лицо менеджера на глазах белеет. «2 недели? 2 недели?!». Он продолжает повторять эти два слова, как будто они могут изменить что-то. Но вы остаётесь спокойным. Менеджеры, как известно, слабые ребята, могут кипятиться. Не стоит вам волноваться из-за этого.
«От нас уйдут наши пользователи! Они ничего не покупают, потому что не видят, что происходит с их корзинами! Мы же компания, торгующая через интернет! Это невозможно!».
Вы наблюдаете, как он проходит 5 этапов отчаяния. Вы ждёте, пока он, наконец, согласится. Но это не происходит. Он, кажется, пытается прессовать.
«Неужели нет какой-либо возможности исправить быстрее? Ну, может быть, что-нибудь временное? Ну, подумай! Это очень важно!».
«Хорошо», — говорите вы, опускаясь на ваше вращающееся кресло. «Дай посоображать».
Вы уступаете ему немного. Может быть, тогда он оставит вас в покое. У вас много других дел, вы это знаете.
Вы опять погружаетесь в источник. Вы в своей стихии. Ваши пальцы перемещаются по пиктограммам IDE, подобно богу Посейдону, скользящему по волнам океана.
О! Вы нашли его. Есть незадокументированный способ войти в программу анализа JSON и заменить её вашей собственной разработкой!
Но подождите. Это может быть опасным. Здесь программный интерфейс приложения является непубличным. Возможно, неправильно поступить с ним так, как вы предположили. Вам не хочется идти на это. Что если в следующем выпуске ошибка будет устранена? Тогда придётся проделать всё это заново. Есть желающие? Хотя это быстрее, чем поддержание вашей собственной, непротестированной, ветви библиотеки. Опять же, это опасно.
Нет!
Вы не позволите сомнительным бизнес-решениям разрушить ваш храм чистоты. Вы являетесь хранителем всего святого в борьбе с невежественными массами. Ведь именно за это вам платят большие деньги. Ваш долг, в такой ситуации — отказаться.
Вы быстро входите в закуток менеджера: «Я говорю тебе — нет! Здесь нет чистого способа сделать это и я не могу полагаться на небезопасные хакерские трюки. Извини.»
Он реагирует ожидаемо.
«Ты говоришь, что есть способ решить проблему, но не будешь это делать, поскольку способ, оказывается, нечистый? Наши пользователи буквально кричат на нас, угрожают уйти к нашим конкурентам, а ты не желаешь устранить баг, потому что способ нечистый?!»
Вы теряете контроль над собой.
Что этот парень знает о проектировании программ? Вы создали фантастические миры из ничего, кроме битов. Великолепно масштабируемые системы, которые могут противостоять DDoS-атакам всех компьютерных хакеров бывшего советского блока, созданы вами. Вы — художник, а компьютер — ваш холст. Вы прочитали книгу «Чистый код» Роберта Мартина столько раз, что знаете её лучше, чем даже собственный GitHub-паспорт.
«Да!», — срываетесь вы. «Я не замараю нашу базу кода этим дерьмом! Я потратил месяцы своей жизни на создание этого дворца! В каждой строке кода запечатлелись моя боль и кровь! Единственная причина по которой здесь, вообще, что-то работает — в том, что всё делалось не благодаря вам, а несмотря на вас. Именно такие, как я, обеспечивают работу всех этих программ и именно такие, как я, должны будут долго приводить в порядок всю эту мешанину, после того как вы и ваши „бизнес-процессы“ уйдут!»
Вы вылетаете из закутка. Что-то выпиваете. Такие парни, как этот — просто бедствие нашей отрасли. Они думают, что их модные степени магистров бизнеса дают им какое-то понимание в вопросах создания серьёзного ПО, что разработчики почему-то прощают. Надо давать им отпор.
Вы заходите в кафе. То, где вы каждый день получаете изысканные блюда. И кофе. Восхитительный, ласкающий душу кофе — безо всяких ограничений. Вы заслуживаете этого, потому что вы — высококвалифицированный специалист.
Вы берёте чашечку кофе и смотрите, где бы присесть.
И тут вы видите его.
Самого почтенного по годам специалиста в нашей компании.
Этот человек относится к крутым, бескомпромиссным специалистам типа «я-могу-написать-компилятор-за-5-минут». Он был хакером ещё до того, как появились хакеры. Вы желаете быть похожим на него. Он отчасти похож на мага Гэндальфа из книг Толкина. Все его уважают и боятся одновременно. Но он добр и всегда выручает детей. Он точно захочет услышать, как вы поставили этого менеджера на место. В конце концов, он — один из представителей вашего цеха.
И вы садитесь рядом с ним. Он не спеша пьёт свой кофе и читает что-то вроде «Абстрактные типы данных в Haskell».
Да. Просто коллега, чтобы поговорить.
Вы излагаете ему свою эпопею. Он терпеливо выслушивает. Он кивает и задаёт несколько вопросов. Его тело спокойно и расслаблено. Он был здесь прежде. Вы можете видеть это в его глазах.
Вы, наконец, закончили.
Это было утомительно.
Вы сбросили груз с плеч.
Он смотрит в раздумье, как будто тщательно подбирает слова.
Вы ждёте, что он громко рассмеётся. Он воскликнет: «Да, мой мальчик!» — а затем вы выпьете ещё по чашечке кофе вместе. Он развлечёт вас историей похожей взбучки, которую он задал бестолковому менеджеру сто лет назад.
Вы мечтали об этом дне. Вы стукнете друг о друга ваши чашки с кофе, как это делают мужчины после победы в битве. По крайней мере, так они делают в кино. И, конечно, у них — не чашки, а кружки, а в кружках — пиво, а не кофе.
Это — сентиментальность, хотя она имеет значение.
Вы ждёте…
И ещё ждёте, и ещё…
Он смотрит вам прямо в глаза. Его взгляд проникает в вашу душу. Долгие годы разборок с машинами придали его глазам твёрдость. И он несёт в себе завораживающую мощь. Вы не можете отвести взгляд.
Он произносит совсем немного.
«Ваша работа состоит не в том, чтобы пить кофе и уклоняться от написания кода. Ваша работа в том, чтобы делать программы, которые работают.»
Затем он уходит.
Вы сидите минуту. Возникает неприятное ощущение в области желудка. Ощущение пустоты и подташнивания. Вы начинаете понимать, что это за ощущение. Вам стыдно.
Вы подвели людей, которым вы обязаны больше всего. Ваших клиентов.
И вы идёте назад к вашему компьютеру. Вы быстро взламываете программу, затем удаляете последний релиз.
Вы извиняетесь перед менеджером: «Извини, друг, дела вышли немного из-под контроля». Он говорит, что всё в порядке. Всё хорошо, что хорошо кончается.
Вы также выводите в отдельную ветвь библиотеку, устраняете баг и посылаете её расположенному иерархически выше менеджеру по продукции. Когда новый релиз библиотеки с правильным решением придёт, вы всегда сможете перепроектировать ПО.
Комментарии (93)
KonstantinSoloviov
22.09.2016 23:31+8Вы обновили библиотеку HTTP запросов до самой последней версии в последнем релизе.
Нда? А к «элегантной программе», «с точно требуемым количеством абстракций», «безупречны модулям» — тестирования не прилагалось?
И «самый почтенный по годам специалист компании» не станет произносить эту мудрую, но бессмысленную в данной ситуации фразу выделенную курсивом (ради которой, очевидно, и писался рассказ). А бросит коротко — «ну, что ж откатывайся, а потом действуй по своему плану». Еще может быть, для одобрения, пошутит вроде: «в этим мире нельзя никому доверять,… мне можно».
TimsTims
23.09.2016 01:16+1> Нда? А к «элегантной программе», «с точно требуемым количеством абстракций», «безупречны модулям» — тестирования не прилагалось?
Это ведь выдуманный рассказ как-никак. Ошибочки или нестыковки возможны. Да даже если это специально так придумано, подумайте — неужели вы считаете, что ваш код говно? Напротив, большинство из разработчиков считают свой код весьма продуманным, и менять его лишний раз не захотят.
> не станет произносить эту фразу
Ну, снова вы всё портите) это же рассказ, не стоит придераться, имхо. Это как щас Толкиену предъявлять, что Гендальф что-то там неправильно сказал, а должен был «вот-так» сказать. Это ведь авторская работа, а не тру-лайф.
ReklatsMasters
23.09.2016 00:27Откатить по изменениям невозможно. Весь новый код и исправления багов завязаны на новую версию библиотеки.
Похоже на мажорное обновление. И без тестов. Неужели кто-то так делает?
Alexey2005
23.09.2016 01:18Так ведь ничего не сломалось, просто на несколько секунд увеличилась задержка. Тесты же обычно проверяют конечный результат, а не время его получения.
Bonart
23.09.2016 01:33+4Если время отклика критично — еще как проверяют.
Am0ralist
23.09.2016 08:27+3о том, что что-то критично, часто узнают уже постфактум…
Bonart
23.09.2016 15:00Не в этой ситуации: основной сценарий, ключевой в понимании бизнеса.
Все равно что Безосу второй клик на покупку добавить.Am0ralist
23.09.2016 16:36Когда заказчик и исполнитель по сути «одно лицо», т.е. разработка для себя — то да.
Когда заказчик из-вне, то разработчики должны понимать в бизнесе заказчика не меньше (а то и больше), что бы предусмотреть все те места, которые могут оказаться критичными.
Не, в идеальных условиях то конечно должно быть именно так.
AndreyDmitriev
23.09.2016 11:00Если так случается — это большущий минус в карму QA. Я шестнадцать лет работал ведущим разработчиком в небольшой команде из нескольких человек и мы успешно выпускали довольно нетривиальный продукт. Сейчас проект перезапускается и над ним работает команда в несколько десятков человек. Это привело к тому, что каждый разработчик «видит» лишь малую часть проекта, над которой он работает, в результате даже в хорошо покрытый тестами проект просачиваются баги, похожие на описанный. В результате я ушёл из разраба в QA, оставшись консультантом, и теперь моя задача не пропускать такие баги. В этом мне помогает то, что я вижу весь продукт целиком, не вдаваясь в подробности, ну и предыдущий опыт в разработке. Ну и время от времени я сажусь в кресло UAT тестера и «коридорным» методом проверяю — чего там накодили. Кстати, одна из основных проблем бывает доказать менеджерам ещё на этапе тестирования, что такое поведение — это реальный баг (результат-то правильный), потому что драгоценное время на фиксы или доп. разработку тратить не хочется.
fishca
23.09.2016 08:02Восхитительный, ласкающий душу кофе — безо всяких ограничений
Прямо бальзам на душу, как и статья! Спасибо!
hdfan2
23.09.2016 09:05+6Вы были здесь прежде.
Пусть меня поправят знатоки английского, но, по-моему, фраза «You've been here before» переводится скорее как «С вами уже было/случалось такое». Похоже на какую-то идиому, но найти её значение не смог.
Antelle
23.09.2016 10:25Это называется fixed expression, в русском тоже есть "где мы сейчас" в смысле не географически где, а в какой ситуации: where we’re at. Мне больше нравится перевод автора "вы были здесь прежде", потому что в нём сохранился такой же тонкий намёк, как и был в оригинальной фразе, что "здесь" — это "в жопе".
stokker
23.09.2016 09:47Идеального решения (или методики) не будет никогда. Всегда придется идти на компромисс.
AVI-crak
23.09.2016 09:47А потом окажется что эта новая библиотека проверяла возможность продажи товара клиенту, бронировала конкретный товар с уникальным id — для того чтобы клиент купил именно то что увидел в описании.
И внезапно получается что клиент покупает что-то зелёное и круглое, а оно уже базах компании отмечено как красное и квадратное. Вот крику-то будет…
bbldzr
23.09.2016 09:47+1Я чуть не заплакал, отличный атмосферный перевод, спасибо.
И посыл правильный!
iqiaqqivik
23.09.2016 10:09+10Давайте расскажу, как в такой ситуации действую я: со мной такое дважды случалось.
1. fork библиотеки, правка, коммит в свой репозиторий, указание своего репозитория в зависимостях проекта;
2. pull request в trunc;
3. hotfix release у себя;
4. кофе;
5. получение письма о том, что мой pull request принят, переключение обратно.
sneakyfildy
23.09.2016 10:35+2Мне кажется, у 99% практикующих программистов именно так и происходит.
iqiaqqivik
23.09.2016 11:11+1Мне тоже так казалось, но я внимательно изучил комментарии, и оказалось, что казалось.
Scf
23.09.2016 11:17+3Тут проблема в п.5 — PR могут мурыжить месяцами, а то и вообще отклонить. И придется либо самому поддерживать свой форк, либо как-то возвращаться на официальную версию.
iqiaqqivik
23.09.2016 11:55+3А еще оригинальную библиотеку может купить Oracle, на голову может упасть кирпич, Скайнет может восстать, Роскомнадзор может запретить пользоваться интернетом.
Я предпочитаю решать проблемы по мере их поступления, и — о, чудо! — они решаются. В описанном в статье случае PR принимают фактически мгновенно, транк легко вливается обратно в мой форк, пока это происходит (потому что я умею писать код так, чтобы он мерджился без бубна), и через месяц все возвращается на круги своя.
И каждый раз где-то вокруг находится теоретик «правильного как надо» и выдумывает тысячу мифических причин того, почему все пойдет не так. И пока он с хмурым лицом ходит и рассказывает, что PR могут и не принять, а если и да, то через год, и так далее — все работает, код принимают и все довольны.
Привет.
staticlab
23.09.2016 13:12Да даже если PR и не примут по тем или иным причинам (отклонили или просто оставили висеть), то всё равно горящая проблема исправлена и уже можно думать, что делать дальше: поддерживать форк библиотеки, перейти на другую, подождать, не исправят ли авторы библиотеки проблему в новом релизе. Тогда на это бюджет времени уже будет запланирован.
iborzenkov
23.09.2016 13:50+1Поэтому стоит немного изменить первый пункт — не форк библиотеки, а фикс патч, который накладывается в то время когда PR ожидает, и накатывается на каждый апдей библиотеки с помощью хуков (composer например), а если что-то обновилось и патч поломался — правится под новую версию.
В этом случае в форке не будет много merge origin/master и всегда актуальная версия библиотеки, даже если твой патч проходит месяцами.
iqiaqqivik прав — обычно PR принимают очень быстро, но не всегда, патч в проекте обычно более управляем и требует меньше телодвижений чем форк библиотеки.iqiaqqivik
23.09.2016 13:55+1> патч в проекте обычно более управляем и требует меньше телодвижений чем форк библиотеки
Это очень спорное утверждение, особенно, если вспомнить, что из форка патч — сделать можно, а наоборот — не всегда (имеется в виду, что в форке больше данных, диффеоморфизма нет). Кроме того, если вы не фиксируете версии сторонних библиотек, у меня для вас плохие новости. А если фиксируете — проще и дешевле при следующем апдейте, если надо обновиться, работать всеми инструментами, которые предоставляет для слияний git, чем ковыряться в текстовом файле невнятного формата.
staticlab
23.09.2016 13:05У автора, как ни странно, алгоритм: 1) пофиксить код в библиотеке; 2) ждать, пока не вольют патч; 3) обновить библиотеку. И очень странно, что "высококвалифицированному специалисту" это представляется единственно корректным способом.
iqiaqqivik
23.09.2016 13:39Во всяких неповоротливых микрософтах и гуглах это очень часто делается именно так: поставил блокировку на тикет «ждем вот такого фикса от вон того отдела», и хоть трава не расти.
В стартапах такой паттерн не работает, но беллетристам типа автора это невдомек.
duskpoet
23.09.2016 13:58+1А что делать в случае отказа в pull request? (да, случалось в реальной жизни и такое, к сожалению)
iqiaqqivik
23.09.2016 14:18Не знаю, мне никогда не отказывали пока. Может, код аккуратнее писать, чтобы ваш pull request прямо возлюбили майнтейнеры?
duskpoet
23.09.2016 14:28+3Бывает и так, что взгляд на проблему не совпадает…
Чтобы не быть голословным: мной был найден баг в библиотеке backbone.js (если в коллекцию попадала модель с id 'undefined', то коллекция начинала вести себя очень весело). Авторы не сочли это за баг, мол нечего сувать всякую гадость в id, хотя в документации писали, что id может быть любым string.iqiaqqivik
23.09.2016 14:33-1Когда я в последний раз ковырялся в js, `undefined` не был «любым string». Пока я согласен со скелетоводами. Я бы тоже отклонил такой реквест, поскольку проверка на `undefined` может ощутимо просадить бенчмарки у и так не самого быстрого фреймворка.
staticlab
23.09.2016 14:45+3Вот этот баг: https://github.com/jashkenas/backbone/issues/3905 id = "undefined", то есть это всё-таки такая строка (которая приходит извне), а не специальное значение.
iqiaqqivik
23.09.2016 15:52Ага, не зря я употребил слово «пока» в моем предыдущем комментарии :)
Да, это некрасиво (но не баг, строго говоря!). Печально, что не удалось убедить разработчиков. Я покопался в коде (не особенно глубоко), там логика, похоже, вросла корнями в core и тянется очень издревле, поэтому тут ситуация другая: новая версия этой библиотеки поломать в существующем коде в этом месте ничего не сможет. Ну да, вы вскрыли недочет третьесторонней библиотеки: так бывает.
Если же поломалось все с апдейтом — то это недавно внесенная проблема, как правило — легко изолируемая, и с вероятностью около 100% ваш PR примут.
PsyHaSTe
26.09.2016 19:24Сидеть на своем форке первой версии до скончания веков. Ну либо раз в год мерджиться с официальной веткой, сохраняя свои изменения.
Bonart
23.09.2016 10:18+1Подумал, что вводная и дальнейший сюжет никак не соответствуют друг другу.
Потом понял, что большая часть достоинств системы существует только в воображении разработчика, который руководствуется абсолютно непрофессиональной логикой "если ошибка в зависимости, то это не моя проблема".
Менеджер тоже ведет себя абсолютно контрпродуктивно — вместо того, чтобы спокойно объяснить, какие деньги теряются на этом баге, выплескивает эмоции, хотя в выпуске сырой версии он наверняка виноват побольше разработчика.
Scf
23.09.2016 10:42Хороший пост о фреймворках. Современное, хорошое спроектированное приложение позволило бы оставить всё как есть, а для конкретно этого запроса с корзиной прикрутить другую библиотеку.
GamePad64
23.09.2016 13:11+2Когда программист изначально пишет код, он закладывает в него некий запас гибкости. Эта гибкость — это ресурс, который можно использовать в критичных ситуациях, подобных этой. При этом, не надо тратить его попусту, иначе потом придётся делать долгий и дорогой рефакторинг.
Bolotnikoff
23.09.2016 13:59Хм. За то немногое время что я писал программный код, я понял только одно! никто не оценит ваши «безупречно модульные модули», зато все оценят концепцию НажалКнопку = Профит!
MurzikFreeman
23.09.2016 13:59«самый почтенный по годам специалист компании» скорее посоветует больше никогда не рассказывать менеджеру о подобных вариантах решения проблем и жёстко отстаивать позицию написания только качественного кода, без хитрых костылей и велосипедов. В противном случае, этот рассказ можно будет дополнить следующей историей, как этот «временный» хак, пришлось подпирать следующим костылём, чтобы корзина вообще работала, а его в свою очередь, следующим, чтобы система хоть как-то запускалась.
Bonart
23.09.2016 14:13У этой логики есть нюанс — без адского хака убытки могут быть сильнее, чем при его наличии.
И разумеется, первое, что надо затребовать, если хотят хак — ресурсы на то, чтобы исправить по феншую. В письменном виде.
MaxKitsch
23.09.2016 13:59+14Я серьёзно изменил своё отношение к происходящему, когда у меня появился собственный проект с собственными всамделишными клиентами. И, на самом деле, если вот прямо здесь и сейчас надо подпереть стенку бомбой с часовым механизмом, за неимением ничего другого подходящего по размеру и весу, надо брать и подпирать — потому что иначе завтра вся конструкция потеряет свой смысл. Да, потом надо будет если не заменить бомбу, например, мешком с гантелями (наивно считать, что теперь туда влезет что-то стандартное без перестройки половины фундамента), то хотя бы перерезать провода таймера и, по возможности, выкрутить взрыватель и поставить пару тройку табличек «НЕ ТРОГАЙ!» для потомков. Но это всё потом, а сейчас — не с менеджером, а с разъярённым живым человеком на проводе и пальцами на клавиатуре надо очень быстро решить проблему любым доступным способом.
Я раньше поражался тому, как уродливы изнутри «взлетевшие» проекты. Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь. Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций. Авантюрист любезно раздаёт восторженным пассажирам талоны и бумажные пакетики.
cdmlex
23.09.2016 13:59IMHO Жалобы от клиентов бы не было, если бы в организации помимо юнит-тестов кто-то занимался человеческим тестированием, как конечный пользователь, садился открывал у себя dev-версию сайта и делал покупки, следил за обновлением корзины и т.д. Не только разработчик должен этим заниматься, тут и «глаз замылился» и реальное поведение клиента отличается от того, что разработчик ожидает. В идеале должны быть отдельные тестировщики, но мог и тот же самый менеджер это сделать.
К сожалению, приходится встречаться с ситуацией, когда все верят, что разработчик допустить ошибку не может, а если что, сам все проверит и все недочеты увидит.
aquamakc
23.09.2016 13:59Вы также выводите в отдельную ветвь библиотеку, устраняете баг и посылаете её расположенному иерархически выше менеджеру по продукции.
Код уходит в релиз. А через несколько дней сервер магазина падает/вместо 1 пылесоса клиентам в корзину приходит 10/не проходит оплата и т.д.
Пользователи уходят, попутно расписывая вконтактиках какой плохой магазин. Манагер в ярости, программист лишается премии. Доводы «я же предупреждал» никого не волнуют. Компания несёт убытки. Сокращается штат. Опытный гуру сруливает первым в контрору-конкурент. Падает метеорит. FIN.
eloiman
23.09.2016 13:59+1Извините за дремучесть, а что такое «восходящее слияние изменений» в списке идеалиста?
mikhailf
23.09.2016 17:31Очевидно, библиотека, виновная во всех бедах, хостится на github. Поэтому процедура описана в терминологии github, и перевести это пожалуй довольно сложно. «восходящее слияние изменений» в оригинале: merge upstream.
Вкратце: после того, как создаешь собственную ветку репозитария (fork repo — неудачно переведено как «Отсоединить библиотеку») и в ней производишь некоторые манипуляции, в то же самое время в оригинальном репозитарии могут происходить какие-то другие изменения. Ну и чтобы эти изменения из оригинального репозитория скопировать в свою ветку, т.е. синхронизировать свой репозитарий и оригинальный — нужно как раз выполнить merge upstream. См. https://help.github.com/articles/syncing-a-fork/
alz72
23.09.2016 16:25+2О — Ответственность.
О! Вы нашли его. Есть незадокументированный способ войти в программу анализа JSON и заменить её вашей собственной разработкой!
Но подождите. Это может быть опасным. Здесь программный интерфейс приложения является непубличным.
Статья предлагает переложить ответственность менеджера (ибо не нашли вовремя и не пофиксили баг — который по хорошему надо фиксить и тестить 2 недели) на плечи абсолютно «левого программера». Ибо если он совестливо пойдет
делать программы, которые работают
и ошибется — а человеку вообще свойственно ошибаться, и проштрафившийся менеджер это доказывает, то накажут уже его, а менеджер удачно уйдет от ответственности…
Stas911
23.09.2016 22:18Прямо про меня история. Лет 12 назад писал я парсер (не важно чего). Первая версия парсера была кривенькая, мутная, но была плотно обложена тестами на все случаи жизни и работала (звалась, как сейчас помню, CrazyLogicParser :). Потом я отрюхал regexp и заменил весь этот говнокод одной строкой регекспа. Все стало вообще красиво.
Время шло, добавлялись новые компоненты, логика парсинга все усложнялась и однажды настал момент, когда я просто не смог поправить regexp так, чтобы не ломались старые тесты. Бился несколько дней — без толку. Тогда от отчаяния я взял свой старый кусок говнокода на циклах и ветвлениях и привинтил новый функционал туда, прогнал все тесты — все работало. Так оно и ушло в прод и, боюсь, так и работает до сих пор :)
taujavarob
23.09.2016 23:05+1>Так оно и ушло в прод и, боюсь, так и работает до сих пор :)
Так, в принципе, работает всё. ;-)
Bonart
23.09.2016 23:42+3Как говорится, если вы стали решать проблему регулярками — значит проблем у вас уже две.
vyatsek
И манагер и девелопер — зелень. Манагер был бы крутым, если бы не орал, а девелоперу надо понимать как можно «похачить» чтобы и система не «взорвалась» и пользователь остался доволен. Цель работающее ПО, какие хаки внутри — проблема компании. Конечному пользователю абсолютно до лампочки.
Wesha
"Плохим разработчиком, построившим угрожающе полную ошибок или из рук вон плохо спроектированную систему, в её основание заложена тикающая бомба замедленного действия, и чтобы разгрести руины после того, как она рванёт, потребуются вложения, тысячекратно превосходящие сэкономленное на старте."
sim-dev
Я, как наблюдатель за хабром из области «машиностроения», а не IT, могу сказать несколько тривиальных, с моей точки зрения, вещей. Почему-то мне кажется, что IT-специалисты не ощущают этой тривиальности, а воспринимают её как некое откровение, иначе повода для этой статьи (кстати, неплохой в литературном смысле, молодец автор) не возникло бы.
1. Любой работник на любом месте ДОЛЖЕН делать то, что сказано вышестоящим начальником. Либо должен уходить.
2. Думать о целесообразности, причинах, последствиях и т.п. не его собачье дело.
3. Считать, что где-то (т.е. в принципе где-то) есть что-либо ЕГО, к чему он может относиться, как к драгоценности (даже просто ЦЕННОСТИ), — большая ошибка. На рабочем месте ЕГО — только грязь под ногтями, остальное — ХОЗЯЙСКОЕ. Соответственно, пусть у хозяина и болит голова об этом.
Поясню капельку. Если начальник сойдет с ума и прикажет вместо перфоратора пробивать стену головой, то до приезда санитаров следует безоговорочно биться головой о стену — это будет единственный ПРАВИЛЬНЫЙ поступок любого работника. Если не повезет и санитары не приедут, то следует либо уходить, либо запасаться стальным шлемом под парик.
Если начальник считает, что надо вместо смазки в коробку передач тойоты, которой вы управляете по службе, насыпать кулек алмазной пыли, следует именно так и поступить. Упаси бог спорить!
Если хрустальный замок, который вы надфилем вытачивали на протяжении 25 лет своей работы начальство прикажет вам разбить, это следует немедля сделать. И не спрашивать, зачем вы тогда 25 лет его создавали.
Никакой рефлексии на рабочем месте. Подставить нужные термины из IT-индустрии в вышенаписанное, наверняка, вы сможете самостоятельно.
Я буду безмерно счастлив, если эти 3 тезиса неприменимы к вашей индустрии. Но в этом случае просто обращаю ваше внимание, что 80 или даже более процентов машиностроительной индустрии зиждется на этом. Просто к сведению.
TimsTims
Вы описали обычное армейское слепое повиновение.
> Биться головой об стену
Кажется, голова не хозяйская, а своя. Если только тебя не продали в рабство
> начальство прикажет вам разбить, это следует немедля сделать
Дело в том, что ИТ — вещь очень специфичная. Далеко не каждый начальник вообще понимает, чем вы заняты. И если он скажет убрать не нужный сервер, и вы удалите по слепому приказу сервак менеджеров(продавцов. Ведь сервак вам не нужен?), то выкручиваться в стиле «мне приказали, я сделал» не получится. Начальник покрутит у виска, спросит зачем тебе голова и попросит увольняться, и будет прав в целом.
На заводах люди совсем по-другому работают, чем в бизнесе. Одно ваше слово «ХОЗЯЙСКОЕ» о многом говорит. И к воровству там относятся проще, мол хозяин жадничает, вот я и утащил. Возможно, приказы на заводе и дело вынужденное, но не могу говорить за другие места.
iCpu
Это касается всего инженерного состава. Они же все либо придумывают детальки, либо собирают из деталей убермашины. Да и программисты, если так подумать, тоже инженеры. Куча непонятных терминов, постоянно витают в облаках, результат труда не ясен до завершения, требуются навыки а гуманитарных областях, и вишенка на торте — 100500 ошибок на выходе.
youlose
В армии, в уставе есть пункты:
1. про то что надо выполнять приказ, а потом оспаривать
2. если приказ унижает личное достоинство подчинённого, его можно НЕ ВЫПОЛНЯТЬ.
Так что там тоже не всё так плохо и головой биться об стены не обязательно.
GarryC
Не совсем так. Например, если Вы выполняете приказ более вышестоящего начальника (в нашем случае требований качества ПО), то Вы обязаны доложить об этом отдавающему приказ, и после этого он принимает решение — повторить приказ и тогда Вы обязаны его выполнять или не повторять.
А когда речь идет о производстве, то служебная (докладная) записка с перечнем возможных проблем и Ваша совесть чиста и через месяц на вопрос начальника «А Вы не предупреждали, что так нельзя» чпокойно демонстрируете копию с его подписью.
Randl
Я не знаю, как в армии вашей страны, но у нас приказ можно (и нужно) не выполнять только если от солдата требуется совершить уголовное преступление.
То есть если с головой об стену случай можно сказать пограничный, но в общем случае унижающий личное достоинство приказ надо именно выполнять, а потом оспаривать
CrazyNiger
И еще добавлю. Менеджер – не начальник над разработчиком. Это роли одного уровня.
rijk
>> начальство прикажет вам разбить, это следует немедля сделать
>Дело в том, что ИТ — вещь очень специфичная. Далеко не каждый начальник вообще понимает, чем вы заняты.
Согласен с предыдущим ораторам. Я при возникновении проблем прихожу к начальнику с несколькими решениями, объясняю о плюсах и минусах, и просто, предлагаю ему выбор
Idot
Правильный поступок — это ПОЛОЖИТЬ БОЛТ на неадекватный приказ.
Процитирую военного гения Сунь-Цзы, написавшего «Искусство войны»:
Wesha
Всё понятно. Это слово сказно поколением, родившимся и выросшим при капитализме. У которого просто в принципе отсутствует советское воспитание — "работу надо любить, и делать её хорошо".
selivanov_pavel
Ну конечно, любовь к своему делу — исключительно монополия советского воспитания, больше такого нигде не было. Я, правда, почему-то много таких людей знаю, из моего выросшего при бездушном капитализме поколения.
iCpu
Если эти решения приняты после полноценного обсуждения со специалистами — вы правы. Если начальник является авторитетом в вашей же области — вы правы.
Если пришёл начальник и просто стал требовать новую фишку, целесообразность которой вам не очевидна от слова «Галоперидольчику, шеф?», — вы не правы. Важно, чтобы вы, как специалист, обозначили перед своим начальником все «за» и «против» введения желаемой фичи. Желательно, в понятных цифрах «у нас будет загрузка серверов не 33%, а 28%, то есть мы сэкономим 1000 рублей за свет в месяц, мы потратим на выполнение 4 месяца работы бригады из 25 программистов, что выливается в 10млн рублей, всё это время фиксить баги не будем». И пусть он дальше живёт с новыми знаниями. А дальше вы правы, если он захочет, либо выполняйте, либо уходите.
Ivan22
тем хуже для «машиностроения»
DexterHD
Вы в общем то правы, это нормальное поведение для обычного «рабочего» (слесаря к примеру). Только вот проблема в том, что программисты в IT это не слесаря, это инженеры. В ваших терминах скорее всего подойдет аббревиатура ИТР (как в общем любом производстве). Я сомневаюсь что хорошие ИТР на производстве слепо следуют указаниям начальства.
В свое время я работал в металлургии и помню как инженеры и директора матом друг друга крыли на планерках обсуждая какую то проблему, при этом ни кто тупым приказам сверху почему то слепо не следовал. После конечно, приходили к какому то консенсусу, и производство не вставало, или возвращалось в нормальный режим работы. От части только потому, что есть ИТР работники которые думают головой.
chieftain_yu
Не согласен.
Для начала при наличии сомнений в целесообразности действий работник должен сообщить о своих сомнениях и пояснить, почему он сомневается в успехе.
У его руководства может по тем или иным причинам отсутствовать ключевая информация. В этом случае решение может не учитывать тех данных, что есть у работника.
Если, конечно, руководство, не прервет его потуги высказать свое мнение.
И хорошо бы распоряжения получать в фиксируемом виде. Для предъявления в случае наступления негативных последствий.
White_Scorpion
> 1. Любой работник на любом месте ДОЛЖЕН делать то, что сказано вышестоящим начальником. Либо должен уходить.
Любой работник в первую очередь квалифицированный профессионал. Если к разработчику приходит какой-то левый менеджер и начинает распоряжаться как сделать то, в чём не разбирается в принципе — горе тому разработчику, который не скажет «Нет!»
> 2. Думать о целесообразности, причинах, последствиях и т.п. не его собачье дело.
Именно разработчика потом обвинят в причинах и последствиях если из-за изменений кода по приказу некомпетентного менеджера какой-то важный функционал отвалится.
> 3. Считать, что где-то (т.е. в принципе где-то) есть что-либо ЕГО, к чему он может относиться, как к драгоценности (даже просто ЦЕННОСТИ), — большая ошибка. На рабочем месте ЕГО — только грязь под ногтями, остальное — ХОЗЯЙСКОЕ. Соответственно, пусть у хозяина и болит голова об этом.
Обычно есть пункты в контракте, котоыре требуют ЗАБОТЫ о хозяйском. Хозяин для того и нанимал разработчика, чтобы сделать то, в чём он не разбирается сам. Задача хозяина — продать решение, задача разработчика — помочь в создании решения.
Ну и пример про битьё головой об стену — вообще не выдерживает никакой критики. Человека нанимали «решать проблему», а не «выполнять капризы начальства». Для того, чтобы «выполнять капризы» — есть эскорт сервисы ;).
kurojneko
Вот именно из за такого отношения наши машины стыдно показывать своим же, не говоря за заграницу (вспомните каменное лицо Владимира Владимировича, пытавшегося завести новую ладу)
ИТ спецы часто меняют место работы,(кстати зачастую из за вот таких вот задвигов менеджеров)
А когда на собеседовании тебя просят показать примеры твоей работы — эти самые примеры показывают чаще всего другому спецу. А что он скажет когда увидит костыль в критичном месте системы?? он скажет что это костыль потому что менеджер был идиотом? неет, он скажет что прогер гавно, потому что влепил костыль!
И даже если не брать перемену места, один хрен, если ты ставишь в системе костыль не по своей инициативе, а потом вся компания об этот костыль спотыкается — никто не вспомнит менеджера, все шишки а они иногда чугунные посыпяться на тебя!!! Никто не даст программисту уйти от ответственности за чужие решения!
Oraclist
noldowalker
Ага, давайте, ставьте нелицензионное ПО под свою ответственность, когда потом проверка заметет вас вместо дирика я на вас посмотрю, выполнятель приказов, блин.
amberovsky
А как же трудовой договор? Понятно, что много где это просто бумажка, где написано «сотрудник обязуется работать работу», но всё-таки хоть какие-то границы и обязанности должны быть определены.
V-core
Я полагаю что подобный подход изжил себя в начале прошлого века.
Эволюция теории управления прошла этап от слепых указаний через учения Форда, Тейлора к Демингу.
В наше время, когда более менее формально определены степени зрелости сиcтемы управления по модели CMMI, можно сказать что вопрос «Кто главнее?» — из эпохи мамонтов.
Зрелая система управления на предприятии просто не допустит самодуров-царьков к руководству.
Sokolyuk
Уважаемый Sim-dev! Дело в том, что есть разные подходы к управлению коллективами, и они варьируются в зависимости от решаемых задач и уровня образованности подчиненных. Что мы имеем на выходе отечественной машиностроительной отрасли нам всем хорошо известно, описанные Вами методы управления многое объясняют. Но ИТ — это 100% высококвалифицированный инженерный состав, и тут «сапоговщина» не прокатывала, не катит и не покатит. И на то есть масса логически обоснованных причин. Ваша попытки прировнять, или даже опустить ИТ на нашем же форуме вызывает смех и сочувствие Вашей непосвященности. Но то, что Вы пытаетесь понять наши реалии, а возможно и перенять лучшее, это Вам плюс. Удачей!
sim-dev
Я не стремлюсь опускать или приравнивать сообщество ИТ к остальным. Но глядя на рассуждения в комментах и в статье, я вижу, что сообщество это, к сожалению, живет в другой реальности, нежели остальные… ИТ сообщество — это сколько процентов? 5 или 10? А остальные 90% живут в суровой реальности, где начальник обязательно самодур, который с легкостью сотрет в порошок любого, кто посмеет усомниться в его правоте. Причем стереть в порошок означать может все. что угодно: от невозможности найти работу в городе до несчастного случая… Например, мой начальник любит рассказывать, как в его «прошлой жизни» у него был один подчиненный, который пошел жаловаться на него генеральному директору… И потом (вот совпадение!) вечером упал и сломал обе ключицы… Понимаете ли?
Я бы и хотел поверить, но не могу, что в ИТ-индустрии все белые и пушистые, начальники сплошь прислушиваются к подчиненным и продвигают особо умных…
Но даже если это и так, ИТ-сообществу совсем не помешает знать, как на самом деле «там, за стеклами офиса»… Просто имейте ввиду, что есть и такие, как я — нас 90% от всех.
Am0ralist
Знаете в чем проблема наездов на админов и айтишников?
Вот у нас в городе раз вакансия была, в которой сразу было указано, что пароля администратора от сервака нет. Не, в итоге они все-таки нашли себе нового админа, который договорился со старым за энную сумму…
А уж сколько случаев было, когда таинственным образом в органы попадали данные и на такие производства приезжали проверки, которые однозначно знали, что искать? Или когда вся техинформация и базы сливались конкурентам.
И ЧО?
Если вы готовы биться головой об стенку — это ваша проблема.
Я вот на предыдущей решал задачи, а не капризы. И когда мне начали намекать, что уж больно я позволяю спорить, я — ушел. И вот уже год, как у них разобраться все конструктора, технологи и айтишники не могут, и ничего сделать в плане автоматизации больше того, что сделал я, — тоже. У них даже поддерживать получается хреново.
Так что тут одно из двух, либо инженеры и айтишники — решают задачи и их слушают, либо производства занимаются по сути хренью, а начальство лишь самоутверждается. Они даже могут что-то выпускать, но на чем-то более крупном, чем местный рыночек, обычно, данные конторы даже не отсвечивают. Потому что конкурентные товары так не сделаешь.
Пример автоваза показателен.
fireSparrow
Высококвалифицированных специалистов меньше, чем потребность в них. Поэтому, они имеют возможность выбирать, где работать. А это дисциплинирует работодателей.
Если какой-то начальник будет дурить — от него специалисты уйдут в другое место, останутся только те, кого в других местах не очень-то ждут. Соответственно, в нормальной организации такому начальнику скорее всего покажут на дверь ещё до того, как он совсем задуреет.
Ну а если в какой-то организации и самое высшее руководство поощряет самодурство, то такая организация просто будет неконкурентноспособной и долго на рынке не продержится.
PsyHaSTe
В идеальном мире — да, предприятия с самодурами разоряются, на их место приходят новые, более адекватные, но к сожалению это работает только там, где финансирование структуры коррелирует с её эффективностью. А вот в нашей «российской действительности», как любят говорить, это не всегда и не совсем так, а иногда и совсем не так.
Randl
В мире есть много стран, в которых такое — не норма
sim-dev
Randl, это не норма и в нашей стране. Но существует, к сожалению.
sumanai, во-первых, когда начальник выполняет указание своего начальника, он является подчиненным, т.е. по сути становится на ваше место. Соответственно, как вы или я, осознает идиотичность ситуации и может (подчеркиваю — МОЖЕТ, но не обязан) не реагировать на ершистость подчиненного, т.к. в некотором смысле «понимает» его. А вот если бы ваш главврач лично вам дал бы указание приходить на работу ТОЛЬКО В РЕЗИНОВЫХ САПОГАХ, то посмотрел бы я на вас, если бы вы заявились в кедах. Т.е. когда «идея» идет от него лично, это совсем не то же самое, что «испорченный телефон» сверху (особенно всяких «разнарядок» на выборы/субботники).
fireSparrow, система РЖД, к которой я косвенно имею отношение, стоит именно на том, что я описал — армия плачет, когда речь идет о беспрекословности выполнения приказов вышестоящих. И, как вы можете заметить, данная «компания» не только держится на рынке, но и неплохо развивается и процветает. А теперь самостоятельно приплюсуйте к ней всю инфраструктуру, благодаря которой это происходит — принципы там те же самые, даже если это прачечные, стирающие вагонные занавески. И все шикарно работает. И подобных примеров МАССА. Это мелочь всякая с числом работников 10-100, может 200-500, конкурирует между собой, а если в компании работает более десятка тысяч людей — нифига там нет связи между снятием начальника и его самодурством. Наоборот: если снимают, то, как правило, с повышением… Кстати, по слухам, мелкие предприятия, которые производят «низкоинтеллектуальную» продукцию (например, что-то типа гаражных ворот и т.п.) испытывают все вышеописанное мною плюс описанное вами: там дикая текучка кадров по этим причинам. Умные и гордые постоянно бегут от придурка-директора, а им на смену полно «здоровых конкурентов», что еще больше убеждает директора, что он ведет себя правильно, и позволяет держать «шибко умных» на минимально возможной зарплате. Исключения, разумеется, есть, все он них знают, все туда стремятся, но… на всех не хватает.
Am0ralist, никаких наездов с моей стороны нет. Просто я удивлен, как умные люди могут не видеть (не замечать) очевидного ВНЕ круга их постоянного обитания, только и всего. Я рассматриваю любую проблему философски, обобщая факты, разделяя и классифицируя их и потом делаю универсальные выводы. Ну, скажем честнее — я стараюсь так делать. Возможно, распространяя опыт «всех» на «конкретно ИТ» я ошибся — это не исключено… Но если существуют ситуации, описанные вами (столкнулся с наездом — повернулся и ушел), а компания продолжает «успешно» существовать и без вас, то есть далеко не нулевая вероятность, что я все-таки прав и в отношении «ИТ-индустрии», просто эти проблемы могут быть более завуалированы или отделены от большинства рядовых сотрудников… Ну а сами ИТ-шники слишком погружены в работу и слишком довольны зарплатой, чтобы обращать внимание на это — вот и создается впечатление… Может такое быть или я снова пальцем в небо ткнул?
fireSparrow
Я всё-таки не вполне понимаю, какую мысль вы хотите донести.
Что в нашей стране вообще самодурство есть и его немало? Ну так с этим фактом никто и не спорит, мы все прекрасно об этом знаем.
Но зачем эту тему детально разбирать здесь? Это IT-ресурс, нам здесь интересно общаться про то, как оно всё в IT, а не про то, как оно всё в РЖД. Если кто-то захочет про РЖД почитать, то он может просто параллельно с хабром читать и какой-нибудь сайт железнодорожников (я сейчас погуглил — такие сайты есть, и их немало).
В IT, конечно, тоже бывают и конфликты внутри коллектива, и попытки начальников давить своей властью. Но это всё в гораздо-гораздо меньших масштабах, на уровне отдельных напряжных эпизодов, а не на уровне каждодневного ада.
Просто в IT-сфере очень большой процент высококвалифицированных специалистов, которых ещё нужно искать. И если такой специалист увольняется, то не получится на следующий день взять троих таких же.
Am0ralist
«Успешно» — это если бы темпы автоматизации и внедрения новинок сохранились хотя бы на 75% от моего уровня, а так же не увеличилось количество ошибок в заказах. А по сути — процесс встал (а через полгода ушел и программист 1С, так как переводчиком между начальством и программистом в конторе не стало).
Так что свали сейчас еще один человек, которому я сдал дела и который за год еще не въехал — там вообще понимающих хоть что-то, как их система работает — не останется считай. Только мои инструкции.
И да, я по доброте душевной периодически им даю подсказки и помогаю решить отдельные вопросы (ну и иногда общаюсь с админом под пивко), поэтому в курсе дел.
PS. Так же перед этим «соптимизировали» отдел конструкторов-технологов, что все сплоченные старички, в том числе и тот, кто это производство создавал, свалили, а остались тюфяки, которым все пофиг. ЗП то в итоге сэкономили, но зато сейчас ни качества, ни скорости работы предыдущего отдела не имеют. Нормально. Компания не конкурент теперь на серьезном рынке.
chieftain_yu
Ну, компания, может, и развивается, но мне крайне странно было получать от их специалистов ряд вопросов.
Я занимался поддержкой ряда ИТ-систем РЖД, и меня удивляли приходящие от них вопросы, ответом на которые было «откройте инструкцию на странице 2 и начинайте читать». То есть нет — ответом на которые была простая перепечатка инструкции, мы ж вежливые.
Нет, по одному-два человека на систему в РЖД (из тех, которые были в поле моего зрения) были прекрасные специалисты. Но там разведена целая прорва простых проксирующих исполнителей, не обладающих нужными компетенциями.
Меня крайне удивляло, что при выпущенном их безопасниками распоряжении о порядке работы с внешними подрядчиками я объяснял спецам РЖД, как и что они должны делать в своей бюрократии, чтобы моих ребят пустили к боевым серверам.
Меня крайне удивляло, что у ряда монолитных систем в РЖД нет ответственного за систему в целом. На Октябрьской дороге за софт отвечает Имярек1, на Свердловской — Имярек2, на Приволжской — Имярек3… За работоспособность самого железа — Имяреки4-120 по местам размещения. А вот чтобы за всю систему целиком — никого. Может, правда, все резко изменилось за последние пару месяцев. Кто знает.
Право слово, между «монополист на господдержке еще не навернулся» и «компания эффективно работает» есть очень солидная разница.
Randl
Перефразирую, есть много стран в которых не надо рассматривать возможность такого события
sumanai
Ходил жаловаться главврачу довольно крупной (1800 работников) больницы, когда всех погнали на выборы палками. Он конечно всё отрицал, мол, мы просто попросили, а не угрожали, но после этого на последующих двух выборах ни слова про них не сказали, и никаких мер ко мне не применили, хотя я демонстративно не пошёл. Работаю далеко, далеко не программистом, и легко заменил почти любым с улицы.
Что я делаю не так?
vyatsek
Этот хак должен быть СТРОГО выпилен в след версиях и это задача менджера, лида и т.д. следить за контекстом разработки.
Если такие вещи не выпиливать то да, потом юзеры будут «подрываться».
KonstantinSamsonov
непонятно как вообще «это» в релиз ушло? функциональные тесты в игноре или отсутствуют?