Comments 98
И манагер и девелопер — зелень. Манагер был бы крутым, если бы не орал, а девелоперу надо понимать как можно «похачить» чтобы и система не «взорвалась» и пользователь остался доволен. Цель работающее ПО, какие хаки внутри — проблема компании. Конечному пользователю абсолютно до лампочки.
девелоперу надо понимать как можно «похачить» чтобы и система не «взорвалась» и пользователь остался доволен.
Я, как наблюдатель за хабром из области «машиностроения», а не IT, могу сказать несколько тривиальных, с моей точки зрения, вещей. Почему-то мне кажется, что IT-специалисты не ощущают этой тривиальности, а воспринимают её как некое откровение, иначе повода для этой статьи (кстати, неплохой в литературном смысле, молодец автор) не возникло бы.
1. Любой работник на любом месте ДОЛЖЕН делать то, что сказано вышестоящим начальником. Либо должен уходить.
2. Думать о целесообразности, причинах, последствиях и т.п. не его собачье дело.
3. Считать, что где-то (т.е. в принципе где-то) есть что-либо ЕГО, к чему он может относиться, как к драгоценности (даже просто ЦЕННОСТИ), — большая ошибка. На рабочем месте ЕГО — только грязь под ногтями, остальное — ХОЗЯЙСКОЕ. Соответственно, пусть у хозяина и болит голова об этом.
Поясню капельку. Если начальник сойдет с ума и прикажет вместо перфоратора пробивать стену головой, то до приезда санитаров следует безоговорочно биться головой о стену — это будет единственный ПРАВИЛЬНЫЙ поступок любого работника. Если не повезет и санитары не приедут, то следует либо уходить, либо запасаться стальным шлемом под парик.
Если начальник считает, что надо вместо смазки в коробку передач тойоты, которой вы управляете по службе, насыпать кулек алмазной пыли, следует именно так и поступить. Упаси бог спорить!
Если хрустальный замок, который вы надфилем вытачивали на протяжении 25 лет своей работы начальство прикажет вам разбить, это следует немедля сделать. И не спрашивать, зачем вы тогда 25 лет его создавали.
Никакой рефлексии на рабочем месте. Подставить нужные термины из IT-индустрии в вышенаписанное, наверняка, вы сможете самостоятельно.
Я буду безмерно счастлив, если эти 3 тезиса неприменимы к вашей индустрии. Но в этом случае просто обращаю ваше внимание, что 80 или даже более процентов машиностроительной индустрии зиждется на этом. Просто к сведению.
1. Любой работник на любом месте ДОЛЖЕН делать то, что сказано вышестоящим начальником. Либо должен уходить.
2. Думать о целесообразности, причинах, последствиях и т.п. не его собачье дело.
3. Считать, что где-то (т.е. в принципе где-то) есть что-либо ЕГО, к чему он может относиться, как к драгоценности (даже просто ЦЕННОСТИ), — большая ошибка. На рабочем месте ЕГО — только грязь под ногтями, остальное — ХОЗЯЙСКОЕ. Соответственно, пусть у хозяина и болит голова об этом.
Поясню капельку. Если начальник сойдет с ума и прикажет вместо перфоратора пробивать стену головой, то до приезда санитаров следует безоговорочно биться головой о стену — это будет единственный ПРАВИЛЬНЫЙ поступок любого работника. Если не повезет и санитары не приедут, то следует либо уходить, либо запасаться стальным шлемом под парик.
Если начальник считает, что надо вместо смазки в коробку передач тойоты, которой вы управляете по службе, насыпать кулек алмазной пыли, следует именно так и поступить. Упаси бог спорить!
Если хрустальный замок, который вы надфилем вытачивали на протяжении 25 лет своей работы начальство прикажет вам разбить, это следует немедля сделать. И не спрашивать, зачем вы тогда 25 лет его создавали.
Никакой рефлексии на рабочем месте. Подставить нужные термины из IT-индустрии в вышенаписанное, наверняка, вы сможете самостоятельно.
Я буду безмерно счастлив, если эти 3 тезиса неприменимы к вашей индустрии. Но в этом случае просто обращаю ваше внимание, что 80 или даже более процентов машиностроительной индустрии зиждется на этом. Просто к сведению.
Вы описали обычное армейское слепое повиновение.
> Биться головой об стену
Кажется, голова не хозяйская, а своя. Если только тебя не продали в рабство
> начальство прикажет вам разбить, это следует немедля сделать
Дело в том, что ИТ — вещь очень специфичная. Далеко не каждый начальник вообще понимает, чем вы заняты. И если он скажет убрать не нужный сервер, и вы удалите по слепому приказу сервак менеджеров(продавцов. Ведь сервак вам не нужен?), то выкручиваться в стиле «мне приказали, я сделал» не получится. Начальник покрутит у виска, спросит зачем тебе голова и попросит увольняться, и будет прав в целом.
На заводах люди совсем по-другому работают, чем в бизнесе. Одно ваше слово «ХОЗЯЙСКОЕ» о многом говорит. И к воровству там относятся проще, мол хозяин жадничает, вот я и утащил. Возможно, приказы на заводе и дело вынужденное, но не могу говорить за другие места.
> Биться головой об стену
Кажется, голова не хозяйская, а своя. Если только тебя не продали в рабство
> начальство прикажет вам разбить, это следует немедля сделать
Дело в том, что ИТ — вещь очень специфичная. Далеко не каждый начальник вообще понимает, чем вы заняты. И если он скажет убрать не нужный сервер, и вы удалите по слепому приказу сервак менеджеров(продавцов. Ведь сервак вам не нужен?), то выкручиваться в стиле «мне приказали, я сделал» не получится. Начальник покрутит у виска, спросит зачем тебе голова и попросит увольняться, и будет прав в целом.
На заводах люди совсем по-другому работают, чем в бизнесе. Одно ваше слово «ХОЗЯЙСКОЕ» о многом говорит. И к воровству там относятся проще, мол хозяин жадничает, вот я и утащил. Возможно, приказы на заводе и дело вынужденное, но не могу говорить за другие места.
Это касается всего инженерного состава. Они же все либо придумывают детальки, либо собирают из деталей убермашины. Да и программисты, если так подумать, тоже инженеры. Куча непонятных терминов, постоянно витают в облаках, результат труда не ясен до завершения, требуются навыки а гуманитарных областях, и вишенка на торте — 100500 ошибок на выходе.
В армии, в уставе есть пункты:
1. про то что надо выполнять приказ, а потом оспаривать
2. если приказ унижает личное достоинство подчинённого, его можно НЕ ВЫПОЛНЯТЬ.
Так что там тоже не всё так плохо и головой биться об стены не обязательно.
1. про то что надо выполнять приказ, а потом оспаривать
2. если приказ унижает личное достоинство подчинённого, его можно НЕ ВЫПОЛНЯТЬ.
Так что там тоже не всё так плохо и головой биться об стены не обязательно.
Не совсем так. Например, если Вы выполняете приказ более вышестоящего начальника (в нашем случае требований качества ПО), то Вы обязаны доложить об этом отдавающему приказ, и после этого он принимает решение — повторить приказ и тогда Вы обязаны его выполнять или не повторять.
А когда речь идет о производстве, то служебная (докладная) записка с перечнем возможных проблем и Ваша совесть чиста и через месяц на вопрос начальника «А Вы не предупреждали, что так нельзя» чпокойно демонстрируете копию с его подписью.
А когда речь идет о производстве, то служебная (докладная) записка с перечнем возможных проблем и Ваша совесть чиста и через месяц на вопрос начальника «А Вы не предупреждали, что так нельзя» чпокойно демонстрируете копию с его подписью.
Я не знаю, как в армии вашей страны, но у нас приказ можно (и нужно) не выполнять только если от солдата требуется совершить уголовное преступление.
То есть если с головой об стену случай можно сказать пограничный, но в общем случае унижающий личное достоинство приказ надо именно выполнять, а потом оспаривать
Что это за страна такая, где солдаты могут и не идти в атаку потому что могут совершить уголовное преступление — убийство?
Как они врага должны побеждать? Подушками закидывать, надеясь, что враг помрёт от смеха? Так ведь тоже — уголовное преступление. Причинение смерти по неосторожности.
А насчёт унижения: есть такой артхаусный фильм «Цельнометаллическая оболочка» — там доходчиво показывается, что случается с командирами, которые слишком уж увлекаются унижением подчинённых. И командиры боевых частей об этом знают — встречались в различных армиях мира ситуации, когда при первом же боевом столкновении человек чересчур увлекающийся унижениями погибал с дырками в спине, хотя спиной к врагу не поворачивался.
Как они врага должны побеждать? Подушками закидывать, надеясь, что враг помрёт от смеха? Так ведь тоже — уголовное преступление. Причинение смерти по неосторожности.
А насчёт унижения: есть такой артхаусный фильм «Цельнометаллическая оболочка» — там доходчиво показывается, что случается с командирами, которые слишком уж увлекаются унижением подчинённых. И командиры боевых частей об этом знают — встречались в различных армиях мира ситуации, когда при первом же боевом столкновении человек чересчур увлекающийся унижениями погибал с дырками в спине, хотя спиной к врагу не поворачивался.
Что это за страна такая
Израиль
потому что могут совершить уголовное преступление — убийство?
Убийство противника — это не уголовное преступление. А вот например кража или изнасилование — преступление.
что случается с командирами, которые слишком уж увлекаются унижением подчинённых.
Сразу после выполнение приказа солдат может и должен обжаловать приказ, и скорее всего такой командир покинет армию довольно быстро.
Я дико извиняюсь, но кража секретных данных — это тоже в стране у которой крадут — уголовное преступление. А изнасилование — оно разным бывает. Опять же кража офицера из штаба и есть насилие, а когда при этом его ещё и пинают — ну так вообще.
Но это уже реальный оффтоп и словоблудие.
Вообще же, если отбросить изящные словеса, любой армии вместо уголовного кодекса у солдата есть Устав. Под трибунал, а не гражданский суд, солдата отдают именно за его нарушение, а не за нарушение уголовного кодекса. Там ясно расписано — что, кому и в какое время он должен. Если в этом уставе написано, что солдат может воровать и насиловать — ну это проблема явно не солдата. И не его командира. Привлечь же солдата к гражданской уголовной ответственности минуя трибунал — невозможно.
Но это уже реальный оффтоп и словоблудие.
Вообще же, если отбросить изящные словеса, любой армии вместо уголовного кодекса у солдата есть Устав. Под трибунал, а не гражданский суд, солдата отдают именно за его нарушение, а не за нарушение уголовного кодекса. Там ясно расписано — что, кому и в какое время он должен. Если в этом уставе написано, что солдат может воровать и насиловать — ну это проблема явно не солдата. И не его командира. Привлечь же солдата к гражданской уголовной ответственности минуя трибунал — невозможно.
И еще добавлю. Менеджер – не начальник над разработчиком. Это роли одного уровня.
>> начальство прикажет вам разбить, это следует немедля сделать
>Дело в том, что ИТ — вещь очень специфичная. Далеко не каждый начальник вообще понимает, чем вы заняты.
Согласен с предыдущим ораторам. Я при возникновении проблем прихожу к начальнику с несколькими решениями, объясняю о плюсах и минусах, и просто, предлагаю ему выбор
>Дело в том, что ИТ — вещь очень специфичная. Далеко не каждый начальник вообще понимает, чем вы заняты.
Согласен с предыдущим ораторам. Я при возникновении проблем прихожу к начальнику с несколькими решениями, объясняю о плюсах и минусах, и просто, предлагаю ему выбор
Если начальник сойдет с ума и прикажет вместо перфоратора пробивать стену головой, то до приезда санитаров следует безоговорочно биться головой о стену — это будет единственный ПРАВИЛЬНЫЙ поступок любого работника.
Вы описали обычное армейское слепое повиновение.
Правильный поступок — это ПОЛОЖИТЬ БОЛТ на неадекватный приказ.
Процитирую военного гения Сунь-Цзы, написавшего «Искусство войны»:
Бывают дороги, по которым не идут; бывают армии, на которые не нападают; бывают крепости, из-за которых не борются; бывают местности, из-за которых не сражаются; бывают повеления государя, которых не выполняют.
Одно ваше слово «ХОЗЯЙСКОЕ» о многом говорит.
Всё понятно. Это слово сказно поколением, родившимся и выросшим при капитализме. У которого просто в принципе отсутствует советское воспитание — "работу надо любить, и делать её хорошо".
Если эти решения приняты после полноценного обсуждения со специалистами — вы правы. Если начальник является авторитетом в вашей же области — вы правы.
Если пришёл начальник и просто стал требовать новую фишку, целесообразность которой вам не очевидна от слова «Галоперидольчику, шеф?», — вы не правы. Важно, чтобы вы, как специалист, обозначили перед своим начальником все «за» и «против» введения желаемой фичи. Желательно, в понятных цифрах «у нас будет загрузка серверов не 33%, а 28%, то есть мы сэкономим 1000 рублей за свет в месяц, мы потратим на выполнение 4 месяца работы бригады из 25 программистов, что выливается в 10млн рублей, всё это время фиксить баги не будем». И пусть он дальше живёт с новыми знаниями. А дальше вы правы, если он захочет, либо выполняйте, либо уходите.
Если пришёл начальник и просто стал требовать новую фишку, целесообразность которой вам не очевидна от слова «Галоперидольчику, шеф?», — вы не правы. Важно, чтобы вы, как специалист, обозначили перед своим начальником все «за» и «против» введения желаемой фичи. Желательно, в понятных цифрах «у нас будет загрузка серверов не 33%, а 28%, то есть мы сэкономим 1000 рублей за свет в месяц, мы потратим на выполнение 4 месяца работы бригады из 25 программистов, что выливается в 10млн рублей, всё это время фиксить баги не будем». И пусть он дальше живёт с новыми знаниями. А дальше вы правы, если он захочет, либо выполняйте, либо уходите.
тем хуже для «машиностроения»
Вы в общем то правы, это нормальное поведение для обычного «рабочего» (слесаря к примеру). Только вот проблема в том, что программисты в IT это не слесаря, это инженеры. В ваших терминах скорее всего подойдет аббревиатура ИТР (как в общем любом производстве). Я сомневаюсь что хорошие ИТР на производстве слепо следуют указаниям начальства.
В свое время я работал в металлургии и помню как инженеры и директора матом друг друга крыли на планерках обсуждая какую то проблему, при этом ни кто тупым приказам сверху почему то слепо не следовал. После конечно, приходили к какому то консенсусу, и производство не вставало, или возвращалось в нормальный режим работы. От части только потому, что есть ИТР работники которые думают головой.
В свое время я работал в металлургии и помню как инженеры и директора матом друг друга крыли на планерках обсуждая какую то проблему, при этом ни кто тупым приказам сверху почему то слепо не следовал. После конечно, приходили к какому то консенсусу, и производство не вставало, или возвращалось в нормальный режим работы. От части только потому, что есть ИТР работники которые думают головой.
Не согласен.
Для начала при наличии сомнений в целесообразности действий работник должен сообщить о своих сомнениях и пояснить, почему он сомневается в успехе.
У его руководства может по тем или иным причинам отсутствовать ключевая информация. В этом случае решение может не учитывать тех данных, что есть у работника.
Если, конечно, руководство, не прервет его потуги высказать свое мнение.
И хорошо бы распоряжения получать в фиксируемом виде. Для предъявления в случае наступления негативных последствий.
Для начала при наличии сомнений в целесообразности действий работник должен сообщить о своих сомнениях и пояснить, почему он сомневается в успехе.
У его руководства может по тем или иным причинам отсутствовать ключевая информация. В этом случае решение может не учитывать тех данных, что есть у работника.
Если, конечно, руководство, не прервет его потуги высказать свое мнение.
И хорошо бы распоряжения получать в фиксируемом виде. Для предъявления в случае наступления негативных последствий.
> 1. Любой работник на любом месте ДОЛЖЕН делать то, что сказано вышестоящим начальником. Либо должен уходить.
Любой работник в первую очередь квалифицированный профессионал. Если к разработчику приходит какой-то левый менеджер и начинает распоряжаться как сделать то, в чём не разбирается в принципе — горе тому разработчику, который не скажет «Нет!»
> 2. Думать о целесообразности, причинах, последствиях и т.п. не его собачье дело.
Именно разработчика потом обвинят в причинах и последствиях если из-за изменений кода по приказу некомпетентного менеджера какой-то важный функционал отвалится.
> 3. Считать, что где-то (т.е. в принципе где-то) есть что-либо ЕГО, к чему он может относиться, как к драгоценности (даже просто ЦЕННОСТИ), — большая ошибка. На рабочем месте ЕГО — только грязь под ногтями, остальное — ХОЗЯЙСКОЕ. Соответственно, пусть у хозяина и болит голова об этом.
Обычно есть пункты в контракте, котоыре требуют ЗАБОТЫ о хозяйском. Хозяин для того и нанимал разработчика, чтобы сделать то, в чём он не разбирается сам. Задача хозяина — продать решение, задача разработчика — помочь в создании решения.
Ну и пример про битьё головой об стену — вообще не выдерживает никакой критики. Человека нанимали «решать проблему», а не «выполнять капризы начальства». Для того, чтобы «выполнять капризы» — есть эскорт сервисы ;).
Любой работник в первую очередь квалифицированный профессионал. Если к разработчику приходит какой-то левый менеджер и начинает распоряжаться как сделать то, в чём не разбирается в принципе — горе тому разработчику, который не скажет «Нет!»
> 2. Думать о целесообразности, причинах, последствиях и т.п. не его собачье дело.
Именно разработчика потом обвинят в причинах и последствиях если из-за изменений кода по приказу некомпетентного менеджера какой-то важный функционал отвалится.
> 3. Считать, что где-то (т.е. в принципе где-то) есть что-либо ЕГО, к чему он может относиться, как к драгоценности (даже просто ЦЕННОСТИ), — большая ошибка. На рабочем месте ЕГО — только грязь под ногтями, остальное — ХОЗЯЙСКОЕ. Соответственно, пусть у хозяина и болит голова об этом.
Обычно есть пункты в контракте, котоыре требуют ЗАБОТЫ о хозяйском. Хозяин для того и нанимал разработчика, чтобы сделать то, в чём он не разбирается сам. Задача хозяина — продать решение, задача разработчика — помочь в создании решения.
Ну и пример про битьё головой об стену — вообще не выдерживает никакой критики. Человека нанимали «решать проблему», а не «выполнять капризы начальства». Для того, чтобы «выполнять капризы» — есть эскорт сервисы ;).
Вот именно из за такого отношения наши машины стыдно показывать своим же, не говоря за заграницу (вспомните каменное лицо Владимира Владимировича, пытавшегося завести новую ладу)
ИТ спецы часто меняют место работы,(кстати зачастую из за вот таких вот задвигов менеджеров)
А когда на собеседовании тебя просят показать примеры твоей работы — эти самые примеры показывают чаще всего другому спецу. А что он скажет когда увидит костыль в критичном месте системы?? он скажет что это костыль потому что менеджер был идиотом? неет, он скажет что прогер гавно, потому что влепил костыль!
И даже если не брать перемену места, один хрен, если ты ставишь в системе костыль не по своей инициативе, а потом вся компания об этот костыль спотыкается — никто не вспомнит менеджера, все шишки а они иногда чугунные посыпяться на тебя!!! Никто не даст программисту уйти от ответственности за чужие решения!
ИТ спецы часто меняют место работы,(кстати зачастую из за вот таких вот задвигов менеджеров)
А когда на собеседовании тебя просят показать примеры твоей работы — эти самые примеры показывают чаще всего другому спецу. А что он скажет когда увидит костыль в критичном месте системы?? он скажет что это костыль потому что менеджер был идиотом? неет, он скажет что прогер гавно, потому что влепил костыль!
И даже если не брать перемену места, один хрен, если ты ставишь в системе костыль не по своей инициативе, а потом вся компания об этот костыль спотыкается — никто не вспомнит менеджера, все шишки а они иногда чугунные посыпяться на тебя!!! Никто не даст программисту уйти от ответственности за чужие решения!
Нет смысла нанимать толковых людей, а затем указывать, что им делать. Мы нанимаем людей, чтобы они говорили, что делать нам. (с) Стив Джобс
Ага, давайте, ставьте нелицензионное ПО под свою ответственность, когда потом проверка заметет вас вместо дирика я на вас посмотрю, выполнятель приказов, блин.
А как же трудовой договор? Понятно, что много где это просто бумажка, где написано «сотрудник обязуется работать работу», но всё-таки хоть какие-то границы и обязанности должны быть определены.
Я полагаю что подобный подход изжил себя в начале прошлого века.
Эволюция теории управления прошла этап от слепых указаний через учения Форда, Тейлора к Демингу.
В наше время, когда более менее формально определены степени зрелости сиcтемы управления по модели CMMI, можно сказать что вопрос «Кто главнее?» — из эпохи мамонтов.
Зрелая система управления на предприятии просто не допустит самодуров-царьков к руководству.
Эволюция теории управления прошла этап от слепых указаний через учения Форда, Тейлора к Демингу.
В наше время, когда более менее формально определены степени зрелости сиcтемы управления по модели CMMI, можно сказать что вопрос «Кто главнее?» — из эпохи мамонтов.
Зрелая система управления на предприятии просто не допустит самодуров-царьков к руководству.
Уважаемый Sim-dev! Дело в том, что есть разные подходы к управлению коллективами, и они варьируются в зависимости от решаемых задач и уровня образованности подчиненных. Что мы имеем на выходе отечественной машиностроительной отрасли нам всем хорошо известно, описанные Вами методы управления многое объясняют. Но ИТ — это 100% высококвалифицированный инженерный состав, и тут «сапоговщина» не прокатывала, не катит и не покатит. И на то есть масса логически обоснованных причин. Ваша попытки прировнять, или даже опустить ИТ на нашем же форуме вызывает смех и сочувствие Вашей непосвященности. Но то, что Вы пытаетесь понять наши реалии, а возможно и перенять лучшее, это Вам плюс. Удачей!
Я не стремлюсь опускать или приравнивать сообщество ИТ к остальным. Но глядя на рассуждения в комментах и в статье, я вижу, что сообщество это, к сожалению, живет в другой реальности, нежели остальные… ИТ сообщество — это сколько процентов? 5 или 10? А остальные 90% живут в суровой реальности, где начальник обязательно самодур, который с легкостью сотрет в порошок любого, кто посмеет усомниться в его правоте. Причем стереть в порошок означать может все. что угодно: от невозможности найти работу в городе до несчастного случая… Например, мой начальник любит рассказывать, как в его «прошлой жизни» у него был один подчиненный, который пошел жаловаться на него генеральному директору… И потом (вот совпадение!) вечером упал и сломал обе ключицы… Понимаете ли?
Я бы и хотел поверить, но не могу, что в ИТ-индустрии все белые и пушистые, начальники сплошь прислушиваются к подчиненным и продвигают особо умных…
Но даже если это и так, ИТ-сообществу совсем не помешает знать, как на самом деле «там, за стеклами офиса»… Просто имейте ввиду, что есть и такие, как я — нас 90% от всех.
Я бы и хотел поверить, но не могу, что в ИТ-индустрии все белые и пушистые, начальники сплошь прислушиваются к подчиненным и продвигают особо умных…
Но даже если это и так, ИТ-сообществу совсем не помешает знать, как на самом деле «там, за стеклами офиса»… Просто имейте ввиду, что есть и такие, как я — нас 90% от всех.
UFO just landed and posted this here
Высококвалифицированных специалистов меньше, чем потребность в них. Поэтому, они имеют возможность выбирать, где работать. А это дисциплинирует работодателей.
Если какой-то начальник будет дурить — от него специалисты уйдут в другое место, останутся только те, кого в других местах не очень-то ждут. Соответственно, в нормальной организации такому начальнику скорее всего покажут на дверь ещё до того, как он совсем задуреет.
Ну а если в какой-то организации и самое высшее руководство поощряет самодурство, то такая организация просто будет неконкурентноспособной и долго на рынке не продержится.
Если какой-то начальник будет дурить — от него специалисты уйдут в другое место, останутся только те, кого в других местах не очень-то ждут. Соответственно, в нормальной организации такому начальнику скорее всего покажут на дверь ещё до того, как он совсем задуреет.
Ну а если в какой-то организации и самое высшее руководство поощряет самодурство, то такая организация просто будет неконкурентноспособной и долго на рынке не продержится.
В идеальном мире — да, предприятия с самодурами разоряются, на их место приходят новые, более адекватные, но к сожалению это работает только там, где финансирование структуры коррелирует с её эффективностью. А вот в нашей «российской действительности», как любят говорить, это не всегда и не совсем так, а иногда и совсем не так.
Например, мой начальник любит рассказывать, как в его «прошлой жизни» у него был один подчиненный, который пошел жаловаться на него генеральному директору… И потом (вот совпадение!) вечером упал и сломал обе ключицы… Понимаете ли?
В мире есть много стран, в которых такое — не норма
Randl, это не норма и в нашей стране. Но существует, к сожалению.
sumanai, во-первых, когда начальник выполняет указание своего начальника, он является подчиненным, т.е. по сути становится на ваше место. Соответственно, как вы или я, осознает идиотичность ситуации и может (подчеркиваю — МОЖЕТ, но не обязан) не реагировать на ершистость подчиненного, т.к. в некотором смысле «понимает» его. А вот если бы ваш главврач лично вам дал бы указание приходить на работу ТОЛЬКО В РЕЗИНОВЫХ САПОГАХ, то посмотрел бы я на вас, если бы вы заявились в кедах. Т.е. когда «идея» идет от него лично, это совсем не то же самое, что «испорченный телефон» сверху (особенно всяких «разнарядок» на выборы/субботники).
fireSparrow, система РЖД, к которой я косвенно имею отношение, стоит именно на том, что я описал — армия плачет, когда речь идет о беспрекословности выполнения приказов вышестоящих. И, как вы можете заметить, данная «компания» не только держится на рынке, но и неплохо развивается и процветает. А теперь самостоятельно приплюсуйте к ней всю инфраструктуру, благодаря которой это происходит — принципы там те же самые, даже если это прачечные, стирающие вагонные занавески. И все шикарно работает. И подобных примеров МАССА. Это мелочь всякая с числом работников 10-100, может 200-500, конкурирует между собой, а если в компании работает более десятка тысяч людей — нифига там нет связи между снятием начальника и его самодурством. Наоборот: если снимают, то, как правило, с повышением… Кстати, по слухам, мелкие предприятия, которые производят «низкоинтеллектуальную» продукцию (например, что-то типа гаражных ворот и т.п.) испытывают все вышеописанное мною плюс описанное вами: там дикая текучка кадров по этим причинам. Умные и гордые постоянно бегут от придурка-директора, а им на смену полно «здоровых конкурентов», что еще больше убеждает директора, что он ведет себя правильно, и позволяет держать «шибко умных» на минимально возможной зарплате. Исключения, разумеется, есть, все он них знают, все туда стремятся, но… на всех не хватает.
Am0ralist, никаких наездов с моей стороны нет. Просто я удивлен, как умные люди могут не видеть (не замечать) очевидного ВНЕ круга их постоянного обитания, только и всего. Я рассматриваю любую проблему философски, обобщая факты, разделяя и классифицируя их и потом делаю универсальные выводы. Ну, скажем честнее — я стараюсь так делать. Возможно, распространяя опыт «всех» на «конкретно ИТ» я ошибся — это не исключено… Но если существуют ситуации, описанные вами (столкнулся с наездом — повернулся и ушел), а компания продолжает «успешно» существовать и без вас, то есть далеко не нулевая вероятность, что я все-таки прав и в отношении «ИТ-индустрии», просто эти проблемы могут быть более завуалированы или отделены от большинства рядовых сотрудников… Ну а сами ИТ-шники слишком погружены в работу и слишком довольны зарплатой, чтобы обращать внимание на это — вот и создается впечатление… Может такое быть или я снова пальцем в небо ткнул?
sumanai, во-первых, когда начальник выполняет указание своего начальника, он является подчиненным, т.е. по сути становится на ваше место. Соответственно, как вы или я, осознает идиотичность ситуации и может (подчеркиваю — МОЖЕТ, но не обязан) не реагировать на ершистость подчиненного, т.к. в некотором смысле «понимает» его. А вот если бы ваш главврач лично вам дал бы указание приходить на работу ТОЛЬКО В РЕЗИНОВЫХ САПОГАХ, то посмотрел бы я на вас, если бы вы заявились в кедах. Т.е. когда «идея» идет от него лично, это совсем не то же самое, что «испорченный телефон» сверху (особенно всяких «разнарядок» на выборы/субботники).
fireSparrow, система РЖД, к которой я косвенно имею отношение, стоит именно на том, что я описал — армия плачет, когда речь идет о беспрекословности выполнения приказов вышестоящих. И, как вы можете заметить, данная «компания» не только держится на рынке, но и неплохо развивается и процветает. А теперь самостоятельно приплюсуйте к ней всю инфраструктуру, благодаря которой это происходит — принципы там те же самые, даже если это прачечные, стирающие вагонные занавески. И все шикарно работает. И подобных примеров МАССА. Это мелочь всякая с числом работников 10-100, может 200-500, конкурирует между собой, а если в компании работает более десятка тысяч людей — нифига там нет связи между снятием начальника и его самодурством. Наоборот: если снимают, то, как правило, с повышением… Кстати, по слухам, мелкие предприятия, которые производят «низкоинтеллектуальную» продукцию (например, что-то типа гаражных ворот и т.п.) испытывают все вышеописанное мною плюс описанное вами: там дикая текучка кадров по этим причинам. Умные и гордые постоянно бегут от придурка-директора, а им на смену полно «здоровых конкурентов», что еще больше убеждает директора, что он ведет себя правильно, и позволяет держать «шибко умных» на минимально возможной зарплате. Исключения, разумеется, есть, все он них знают, все туда стремятся, но… на всех не хватает.
Am0ralist, никаких наездов с моей стороны нет. Просто я удивлен, как умные люди могут не видеть (не замечать) очевидного ВНЕ круга их постоянного обитания, только и всего. Я рассматриваю любую проблему философски, обобщая факты, разделяя и классифицируя их и потом делаю универсальные выводы. Ну, скажем честнее — я стараюсь так делать. Возможно, распространяя опыт «всех» на «конкретно ИТ» я ошибся — это не исключено… Но если существуют ситуации, описанные вами (столкнулся с наездом — повернулся и ушел), а компания продолжает «успешно» существовать и без вас, то есть далеко не нулевая вероятность, что я все-таки прав и в отношении «ИТ-индустрии», просто эти проблемы могут быть более завуалированы или отделены от большинства рядовых сотрудников… Ну а сами ИТ-шники слишком погружены в работу и слишком довольны зарплатой, чтобы обращать внимание на это — вот и создается впечатление… Может такое быть или я снова пальцем в небо ткнул?
Я всё-таки не вполне понимаю, какую мысль вы хотите донести.
Что в нашей стране вообще самодурство есть и его немало? Ну так с этим фактом никто и не спорит, мы все прекрасно об этом знаем.
Но зачем эту тему детально разбирать здесь? Это IT-ресурс, нам здесь интересно общаться про то, как оно всё в IT, а не про то, как оно всё в РЖД. Если кто-то захочет про РЖД почитать, то он может просто параллельно с хабром читать и какой-нибудь сайт железнодорожников (я сейчас погуглил — такие сайты есть, и их немало).
В IT, конечно, тоже бывают и конфликты внутри коллектива, и попытки начальников давить своей властью. Но это всё в гораздо-гораздо меньших масштабах, на уровне отдельных напряжных эпизодов, а не на уровне каждодневного ада.
Просто в IT-сфере очень большой процент высококвалифицированных специалистов, которых ещё нужно искать. И если такой специалист увольняется, то не получится на следующий день взять троих таких же.
Что в нашей стране вообще самодурство есть и его немало? Ну так с этим фактом никто и не спорит, мы все прекрасно об этом знаем.
Но зачем эту тему детально разбирать здесь? Это IT-ресурс, нам здесь интересно общаться про то, как оно всё в IT, а не про то, как оно всё в РЖД. Если кто-то захочет про РЖД почитать, то он может просто параллельно с хабром читать и какой-нибудь сайт железнодорожников (я сейчас погуглил — такие сайты есть, и их немало).
В IT, конечно, тоже бывают и конфликты внутри коллектива, и попытки начальников давить своей властью. Но это всё в гораздо-гораздо меньших масштабах, на уровне отдельных напряжных эпизодов, а не на уровне каждодневного ада.
Просто в IT-сфере очень большой процент высококвалифицированных специалистов, которых ещё нужно искать. И если такой специалист увольняется, то не получится на следующий день взять троих таких же.
UFO just landed and posted this here
И, как вы можете заметить, данная «компания» не только держится на рынке, но и неплохо развивается и процветает.
Ну, компания, может, и развивается, но мне крайне странно было получать от их специалистов ряд вопросов.
Я занимался поддержкой ряда ИТ-систем РЖД, и меня удивляли приходящие от них вопросы, ответом на которые было «откройте инструкцию на странице 2 и начинайте читать». То есть нет — ответом на которые была простая перепечатка инструкции, мы ж вежливые.
Нет, по одному-два человека на систему в РЖД (из тех, которые были в поле моего зрения) были прекрасные специалисты. Но там разведена целая прорва простых проксирующих исполнителей, не обладающих нужными компетенциями.
Меня крайне удивляло, что при выпущенном их безопасниками распоряжении о порядке работы с внешними подрядчиками я объяснял спецам РЖД, как и что они должны делать в своей бюрократии, чтобы моих ребят пустили к боевым серверам.
Меня крайне удивляло, что у ряда монолитных систем в РЖД нет ответственного за систему в целом. На Октябрьской дороге за софт отвечает Имярек1, на Свердловской — Имярек2, на Приволжской — Имярек3… За работоспособность самого железа — Имяреки4-120 по местам размещения. А вот чтобы за всю систему целиком — никого. Может, правда, все резко изменилось за последние пару месяцев. Кто знает.
Право слово, между «монополист на господдержке еще не навернулся» и «компания эффективно работает» есть очень солидная разница.
это не норма и в нашей стране. Но существует, к сожалению.
Перефразирую, есть много стран в которых не надо рассматривать возможность такого события
UFO just landed and posted this here
Этот хак должен быть СТРОГО выпилен в след версиях и это задача менджера, лида и т.д. следить за контекстом разработки.
Если такие вещи не выпиливать то да, потом юзеры будут «подрываться».
Если такие вещи не выпиливать то да, потом юзеры будут «подрываться».
непонятно как вообще «это» в релиз ушло? функциональные тесты в игноре или отсутствуют?
Вы обновили библиотеку HTTP запросов до самой последней версии в последнем релизе.Нда? А к «элегантной программе», «с точно требуемым количеством абстракций», «безупречны модулям» — тестирования не прилагалось?
И «самый почтенный по годам специалист компании» не станет произносить эту мудрую, но бессмысленную в данной ситуации фразу выделенную курсивом (ради которой, очевидно, и писался рассказ). А бросит коротко — «ну, что ж откатывайся, а потом действуй по своему плану». Еще может быть, для одобрения, пошутит вроде: «в этим мире нельзя никому доверять,… мне можно».
> Нда? А к «элегантной программе», «с точно требуемым количеством абстракций», «безупречны модулям» — тестирования не прилагалось?
Это ведь выдуманный рассказ как-никак. Ошибочки или нестыковки возможны. Да даже если это специально так придумано, подумайте — неужели вы считаете, что ваш код говно? Напротив, большинство из разработчиков считают свой код весьма продуманным, и менять его лишний раз не захотят.
> не станет произносить эту фразу
Ну, снова вы всё портите) это же рассказ, не стоит придераться, имхо. Это как щас Толкиену предъявлять, что Гендальф что-то там неправильно сказал, а должен был «вот-так» сказать. Это ведь авторская работа, а не тру-лайф.
Это ведь выдуманный рассказ как-никак. Ошибочки или нестыковки возможны. Да даже если это специально так придумано, подумайте — неужели вы считаете, что ваш код говно? Напротив, большинство из разработчиков считают свой код весьма продуманным, и менять его лишний раз не захотят.
> не станет произносить эту фразу
Ну, снова вы всё портите) это же рассказ, не стоит придераться, имхо. Это как щас Толкиену предъявлять, что Гендальф что-то там неправильно сказал, а должен был «вот-так» сказать. Это ведь авторская работа, а не тру-лайф.
Че QA сказал?
UFO just landed and posted this here
Так ведь ничего не сломалось, просто на несколько секунд увеличилась задержка. Тесты же обычно проверяют конечный результат, а не время его получения.
Если время отклика критично — еще как проверяют.
Если так случается — это большущий минус в карму QA. Я шестнадцать лет работал ведущим разработчиком в небольшой команде из нескольких человек и мы успешно выпускали довольно нетривиальный продукт. Сейчас проект перезапускается и над ним работает команда в несколько десятков человек. Это привело к тому, что каждый разработчик «видит» лишь малую часть проекта, над которой он работает, в результате даже в хорошо покрытый тестами проект просачиваются баги, похожие на описанный. В результате я ушёл из разраба в QA, оставшись консультантом, и теперь моя задача не пропускать такие баги. В этом мне помогает то, что я вижу весь продукт целиком, не вдаваясь в подробности, ну и предыдущий опыт в разработке. Ну и время от времени я сажусь в кресло UAT тестера и «коридорным» методом проверяю — чего там накодили. Кстати, одна из основных проблем бывает доказать менеджерам ещё на этапе тестирования, что такое поведение — это реальный баг (результат-то правильный), потому что драгоценное время на фиксы или доп. разработку тратить не хочется.
Истина всегда где-то посередине…
Восхитительный, ласкающий душу кофе — безо всяких ограничений
Прямо бальзам на душу, как и статья! Спасибо!
Вы были здесь прежде.
Пусть меня поправят знатоки английского, но, по-моему, фраза «You've been here before» переводится скорее как «С вами уже было/случалось такое». Похоже на какую-то идиому, но найти её значение не смог.
Идеального решения (или методики) не будет никогда. Всегда придется идти на компромисс.
А потом окажется что эта новая библиотека проверяла возможность продажи товара клиенту, бронировала конкретный товар с уникальным id — для того чтобы клиент купил именно то что увидел в описании.
И внезапно получается что клиент покупает что-то зелёное и круглое, а оно уже базах компании отмечено как красное и квадратное. Вот крику-то будет…
И внезапно получается что клиент покупает что-то зелёное и круглое, а оно уже базах компании отмечено как красное и квадратное. Вот крику-то будет…
Я чуть не заплакал, отличный атмосферный перевод, спасибо.
И посыл правильный!
И посыл правильный!
«Вы опять погружаетесь в источник.» Источник? Источник?! У меня ощущение, что я смотрю Матрицу.
Записки Кэпа. Вот вам еще: «Жизнь — череда компромиссов».
Вы опять погружаетесь в источник.
Magic Goody?
Давайте расскажу, как в такой ситуации действую я: со мной такое дважды случалось.
1. fork библиотеки, правка, коммит в свой репозиторий, указание своего репозитория в зависимостях проекта;
2. pull request в trunc;
3. hotfix release у себя;
4. кофе;
5. получение письма о том, что мой pull request принят, переключение обратно.
1. fork библиотеки, правка, коммит в свой репозиторий, указание своего репозитория в зависимостях проекта;
2. pull request в trunc;
3. hotfix release у себя;
4. кофе;
5. получение письма о том, что мой pull request принят, переключение обратно.
Мне кажется, у 99% практикующих программистов именно так и происходит.
Тут проблема в п.5 — PR могут мурыжить месяцами, а то и вообще отклонить. И придется либо самому поддерживать свой форк, либо как-то возвращаться на официальную версию.
Упустил этот момент.
А еще оригинальную библиотеку может купить Oracle, на голову может упасть кирпич, Скайнет может восстать, Роскомнадзор может запретить пользоваться интернетом.
Я предпочитаю решать проблемы по мере их поступления, и — о, чудо! — они решаются. В описанном в статье случае PR принимают фактически мгновенно, транк легко вливается обратно в мой форк, пока это происходит (потому что я умею писать код так, чтобы он мерджился без бубна), и через месяц все возвращается на круги своя.
И каждый раз где-то вокруг находится теоретик «правильного как надо» и выдумывает тысячу мифических причин того, почему все пойдет не так. И пока он с хмурым лицом ходит и рассказывает, что PR могут и не принять, а если и да, то через год, и так далее — все работает, код принимают и все довольны.
Привет.
Я предпочитаю решать проблемы по мере их поступления, и — о, чудо! — они решаются. В описанном в статье случае PR принимают фактически мгновенно, транк легко вливается обратно в мой форк, пока это происходит (потому что я умею писать код так, чтобы он мерджился без бубна), и через месяц все возвращается на круги своя.
И каждый раз где-то вокруг находится теоретик «правильного как надо» и выдумывает тысячу мифических причин того, почему все пойдет не так. И пока он с хмурым лицом ходит и рассказывает, что PR могут и не принять, а если и да, то через год, и так далее — все работает, код принимают и все довольны.
Привет.
UFO just landed and posted this here
Поэтому стоит немного изменить первый пункт — не форк библиотеки, а фикс патч, который накладывается в то время когда PR ожидает, и накатывается на каждый апдей библиотеки с помощью хуков (composer например), а если что-то обновилось и патч поломался — правится под новую версию.
В этом случае в форке не будет много merge origin/master и всегда актуальная версия библиотеки, даже если твой патч проходит месяцами.
iqiaqqivik прав — обычно PR принимают очень быстро, но не всегда, патч в проекте обычно более управляем и требует меньше телодвижений чем форк библиотеки.
В этом случае в форке не будет много merge origin/master и всегда актуальная версия библиотеки, даже если твой патч проходит месяцами.
iqiaqqivik прав — обычно PR принимают очень быстро, но не всегда, патч в проекте обычно более управляем и требует меньше телодвижений чем форк библиотеки.
> патч в проекте обычно более управляем и требует меньше телодвижений чем форк библиотеки
Это очень спорное утверждение, особенно, если вспомнить, что из форка патч — сделать можно, а наоборот — не всегда (имеется в виду, что в форке больше данных, диффеоморфизма нет). Кроме того, если вы не фиксируете версии сторонних библиотек, у меня для вас плохие новости. А если фиксируете — проще и дешевле при следующем апдейте, если надо обновиться, работать всеми инструментами, которые предоставляет для слияний git, чем ковыряться в текстовом файле невнятного формата.
Это очень спорное утверждение, особенно, если вспомнить, что из форка патч — сделать можно, а наоборот — не всегда (имеется в виду, что в форке больше данных, диффеоморфизма нет). Кроме того, если вы не фиксируете версии сторонних библиотек, у меня для вас плохие новости. А если фиксируете — проще и дешевле при следующем апдейте, если надо обновиться, работать всеми инструментами, которые предоставляет для слияний git, чем ковыряться в текстовом файле невнятного формата.
UFO just landed and posted this here
А что делать в случае отказа в pull request? (да, случалось в реальной жизни и такое, к сожалению)
Не знаю, мне никогда не отказывали пока. Может, код аккуратнее писать, чтобы ваш pull request прямо возлюбили майнтейнеры?
Бывает и так, что взгляд на проблему не совпадает…
Чтобы не быть голословным: мной был найден баг в библиотеке backbone.js (если в коллекцию попадала модель с id 'undefined', то коллекция начинала вести себя очень весело). Авторы не сочли это за баг, мол нечего сувать всякую гадость в id, хотя в документации писали, что id может быть любым string.
Чтобы не быть голословным: мной был найден баг в библиотеке backbone.js (если в коллекцию попадала модель с id 'undefined', то коллекция начинала вести себя очень весело). Авторы не сочли это за баг, мол нечего сувать всякую гадость в id, хотя в документации писали, что id может быть любым string.
Когда я в последний раз ковырялся в js, `undefined` не был «любым string». Пока я согласен со скелетоводами. Я бы тоже отклонил такой реквест, поскольку проверка на `undefined` может ощутимо просадить бенчмарки у и так не самого быстрого фреймворка.
UFO just landed and posted this here
Ага, не зря я употребил слово «пока» в моем предыдущем комментарии :)
Да, это некрасиво (но не баг, строго говоря!). Печально, что не удалось убедить разработчиков. Я покопался в коде (не особенно глубоко), там логика, похоже, вросла корнями в core и тянется очень издревле, поэтому тут ситуация другая: новая версия этой библиотеки поломать в существующем коде в этом месте ничего не сможет. Ну да, вы вскрыли недочет третьесторонней библиотеки: так бывает.
Если же поломалось все с апдейтом — то это недавно внесенная проблема, как правило — легко изолируемая, и с вероятностью около 100% ваш PR примут.
Да, это некрасиво (но не баг, строго говоря!). Печально, что не удалось убедить разработчиков. Я покопался в коде (не особенно глубоко), там логика, похоже, вросла корнями в core и тянется очень издревле, поэтому тут ситуация другая: новая версия этой библиотеки поломать в существующем коде в этом месте ничего не сможет. Ну да, вы вскрыли недочет третьесторонней библиотеки: так бывает.
Если же поломалось все с апдейтом — то это недавно внесенная проблема, как правило — легко изолируемая, и с вероятностью около 100% ваш PR примут.
Сидеть на своем форке первой версии до скончания веков. Ну либо раз в год мерджиться с официальной веткой, сохраняя свои изменения.
Подумал, что вводная и дальнейший сюжет никак не соответствуют друг другу.
Потом понял, что большая часть достоинств системы существует только в воображении разработчика, который руководствуется абсолютно непрофессиональной логикой "если ошибка в зависимости, то это не моя проблема".
Менеджер тоже ведет себя абсолютно контрпродуктивно — вместо того, чтобы спокойно объяснить, какие деньги теряются на этом баге, выплескивает эмоции, хотя в выпуске сырой версии он наверняка виноват побольше разработчика.
Хороший пост о фреймворках. Современное, хорошое спроектированное приложение позволило бы оставить всё как есть, а для конкретно этого запроса с корзиной прикрутить другую библиотеку.
Когда программист изначально пишет код, он закладывает в него некий запас гибкости. Эта гибкость — это ресурс, который можно использовать в критичных ситуациях, подобных этой. При этом, не надо тратить его попусту, иначе потом придётся делать долгий и дорогой рефакторинг.
Хм. За то немногое время что я писал программный код, я понял только одно! никто не оценит ваши «безупречно модульные модули», зато все оценят концепцию НажалКнопку = Профит!
«самый почтенный по годам специалист компании» скорее посоветует больше никогда не рассказывать менеджеру о подобных вариантах решения проблем и жёстко отстаивать позицию написания только качественного кода, без хитрых костылей и велосипедов. В противном случае, этот рассказ можно будет дополнить следующей историей, как этот «временный» хак, пришлось подпирать следующим костылём, чтобы корзина вообще работала, а его в свою очередь, следующим, чтобы система хоть как-то запускалась.
Я серьёзно изменил своё отношение к происходящему, когда у меня появился собственный проект с собственными всамделишными клиентами. И, на самом деле, если вот прямо здесь и сейчас надо подпереть стенку бомбой с часовым механизмом, за неимением ничего другого подходящего по размеру и весу, надо брать и подпирать — потому что иначе завтра вся конструкция потеряет свой смысл. Да, потом надо будет если не заменить бомбу, например, мешком с гантелями (наивно считать, что теперь туда влезет что-то стандартное без перестройки половины фундамента), то хотя бы перерезать провода таймера и, по возможности, выкрутить взрыватель и поставить пару тройку табличек «НЕ ТРОГАЙ!» для потомков. Но это всё потом, а сейчас — не с менеджером, а с разъярённым живым человеком на проводе и пальцами на клавиатуре надо очень быстро решить проблему любым доступным способом.
Я раньше поражался тому, как уродливы изнутри «взлетевшие» проекты. Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь. Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций. Авантюрист любезно раздаёт восторженным пассажирам талоны и бумажные пакетики.
Я раньше поражался тому, как уродливы изнутри «взлетевшие» проекты. Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь. Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций. Авантюрист любезно раздаёт восторженным пассажирам талоны и бумажные пакетики.
IMHO Жалобы от клиентов бы не было, если бы в организации помимо юнит-тестов кто-то занимался человеческим тестированием, как конечный пользователь, садился открывал у себя dev-версию сайта и делал покупки, следил за обновлением корзины и т.д. Не только разработчик должен этим заниматься, тут и «глаз замылился» и реальное поведение клиента отличается от того, что разработчик ожидает. В идеале должны быть отдельные тестировщики, но мог и тот же самый менеджер это сделать.
К сожалению, приходится встречаться с ситуацией, когда все верят, что разработчик допустить ошибку не может, а если что, сам все проверит и все недочеты увидит.
К сожалению, приходится встречаться с ситуацией, когда все верят, что разработчик допустить ошибку не может, а если что, сам все проверит и все недочеты увидит.
Вы также выводите в отдельную ветвь библиотеку, устраняете баг и посылаете её расположенному иерархически выше менеджеру по продукции.
Код уходит в релиз. А через несколько дней сервер магазина падает/вместо 1 пылесоса клиентам в корзину приходит 10/не проходит оплата и т.д.
Пользователи уходят, попутно расписывая вконтактиках какой плохой магазин. Манагер в ярости, программист лишается премии. Доводы «я же предупреждал» никого не волнуют. Компания несёт убытки. Сокращается штат. Опытный гуру сруливает первым в контрору-конкурент. Падает метеорит. FIN.
Извините за дремучесть, а что такое «восходящее слияние изменений» в списке идеалиста?
Очевидно, библиотека, виновная во всех бедах, хостится на github. Поэтому процедура описана в терминологии github, и перевести это пожалуй довольно сложно. «восходящее слияние изменений» в оригинале: merge upstream.
Вкратце: после того, как создаешь собственную ветку репозитария (fork repo — неудачно переведено как «Отсоединить библиотеку») и в ней производишь некоторые манипуляции, в то же самое время в оригинальном репозитарии могут происходить какие-то другие изменения. Ну и чтобы эти изменения из оригинального репозитория скопировать в свою ветку, т.е. синхронизировать свой репозитарий и оригинальный — нужно как раз выполнить merge upstream. См. https://help.github.com/articles/syncing-a-fork/
Вкратце: после того, как создаешь собственную ветку репозитария (fork repo — неудачно переведено как «Отсоединить библиотеку») и в ней производишь некоторые манипуляции, в то же самое время в оригинальном репозитарии могут происходить какие-то другие изменения. Ну и чтобы эти изменения из оригинального репозитория скопировать в свою ветку, т.е. синхронизировать свой репозитарий и оригинальный — нужно как раз выполнить merge upstream. См. https://help.github.com/articles/syncing-a-fork/
UFO just landed and posted this here
Прямо про меня история. Лет 12 назад писал я парсер (не важно чего). Первая версия парсера была кривенькая, мутная, но была плотно обложена тестами на все случаи жизни и работала (звалась, как сейчас помню, CrazyLogicParser :). Потом я отрюхал regexp и заменил весь этот говнокод одной строкой регекспа. Все стало вообще красиво.
Время шло, добавлялись новые компоненты, логика парсинга все усложнялась и однажды настал момент, когда я просто не смог поправить regexp так, чтобы не ломались старые тесты. Бился несколько дней — без толку. Тогда от отчаяния я взял свой старый кусок говнокода на циклах и ветвлениях и привинтил новый функционал туда, прогнал все тесты — все работало. Так оно и ушло в прод и, боюсь, так и работает до сих пор :)
Время шло, добавлялись новые компоненты, логика парсинга все усложнялась и однажды настал момент, когда я просто не смог поправить regexp так, чтобы не ломались старые тесты. Бился несколько дней — без толку. Тогда от отчаяния я взял свой старый кусок говнокода на циклах и ветвлениях и привинтил новый функционал туда, прогнал все тесты — все работало. Так оно и ушло в прод и, боюсь, так и работает до сих пор :)
That’s just the kind of stand-up employee you are.
Это — часть работы своего рода «кризисного» сотрудника, которым вы и являетесь.
Вот поэтому лучше сразу прыгать на оригинал.
А это вообще что-то:
“Our job is not to drink coffee and crap out code. Our job is to make software that works.”
«Ваша работа состоит не в том, чтобы пить кофе и уклоняться от написания кода. Ваша работа в том, чтобы делать программы, которые работают.»
Sign up to leave a comment.
Итак, менеджер попросил пофиксить баг…