В какой момент «конструктивная» критика вашего кода становится бесполезной?

39

Я недавно начал как младший разработчик. Помимо того, что я являюсь одним из наименее опытных людей в команде, я также женщина, которая сталкивается со всеми своими проблемами, работая в среде, где доминируют мужчины. У меня были проблемы в последнее время, потому что я чувствую, что получаю слишком много необоснованной педантичной критики в отношении моей работы. Позвольте мне привести вам пример того, что произошло недавно.

Руководитель команды был слишком занят, чтобы продвигать некоторые ветки, которые я сделал, поэтому он не добрался до них до выходных. Я проверил свою почту, на самом деле не намереваясь выполнять какую-либо работу, и обнаружил, что мои две ветви были отклонены на основе имен переменных, что сделало сообщения об ошибках более наглядными и переместило некоторые значения в файл конфигурации.

Я не чувствую, что отклонение моей ветви на этом основании полезно. В выходные работало много людей, и я никогда не говорил, что буду работать. По сути, некоторые люди, вероятно, были заблокированы, потому что у меня не было времени, чтобы внести изменения и повторно отправить. Мы работаем над проектом, который очень чувствителен ко времени, и мне кажется, что бесполезно отвергать код, основанный на вещах, которые прозрачны для клиента. Я могу ошибаться, но кажется, что такие вещи должны обрабатываться в коммитах типа патча, когда у меня есть время.

Теперь я вижу, что в некоторых условиях это будет нормой. Тем не менее, критика не выглядит равномерно распределенной, что и приводит к моей следующей проблеме. Основой большинства этих проблем было то, что я находился в кодовой базе, написанной кем-то другим, и пытался быть минимально инвазивным. Я имитировал имена переменных, используемых в других местах файла. Когда я это сказал, мне прямо сказали: «Не подражайте другим, просто делайте то, что правильно». Это, пожалуй, наименее полезная вещь, которую я мог бы сказать. Если код, который уже зарегистрирован, является неприемлемым, как я могу сказать, что правильно, а что нет? Если основа путаницы исходила из базового кода, я не думаю, что

Я чувствую себя действительно выделенным и разочарованным в этой ситуации. Мне стало намного лучше следовать ожидаемым стандартам, и я разочарован тем, что, например, когда я реорганизую часть кода для проверки ошибок ADD, которая ранее отсутствовала, мне только сказали, что я этого не сделал сделать ошибки достаточно многословными (и ветвь была отклонена на этом основании). Что, если я никогда не добавлял это для начала? Как он попал в код для начала, если это было так неправильно? Вот почему я чувствую себя настолько выделенным: я постоянно сталкиваюсь с существующим проблемным кодом, который я либо имитирую, либо реорганизую. Когда я имитирую это, это «неправильно», и если я рефакторину это, меня упрекают за то, что я недостаточно делаю (и если я иду весь путь, внося ошибки и т.д.). Опять же, если это такая проблема, я не понимаю, как любой код попадает в кодовую базу,

Во всяком случае, как мне справиться с этим? Пожалуйста, помните, что я сказал сверху, что я женщина, и я уверен, что этим парням обычно не нужно беспокоиться о приличии, когда они пересматривают код других парней, но, честно говоря, это не работает для меня и это заставляет меня быть менее продуктивным. Я боюсь, что если я поговорю об этом с моим менеджером, он подумает, что я не справлюсь с окружающей средой и т. Д.

user15859
источник
18
Я парень, младший (в этой компании), и я чувствовал подобный двойной стандарт. Кодовая база часто выглядит как дерьмо, и все же я должен следовать гораздо более высоким стандартам. Ну, оказалось, что дерьмо попало туда из-за "маршей смерти", которые были сделаны в прошлом. Кроме того, по-видимому, я выгляжу на 5 лет моложе меня. Когда мои коллеги узнали мой настоящий возраст, я стал намного умнее за одну ночь. Люди - несовершенные обезьяны. Будет полезно, если вы поделитесь с ними обедом и посмеетесь над их шутками, но не переусердствуйте. Ребята ВСЁ интерпретируют как флирт.
Работа
4
@Job: Ну, если кодовая база дерьмовая, она должна быть лучше, поэтому ваши коммиты должны иметь более высокий стандарт. Иначе это стало бы еще более дерьмовым, верно? :)
Мак
@ Маркус, ты прав, но было бы очень полезно, если бы правила были четко сформулированы, и те же правила применялись ко всем. Кроме того, есть кое-что, что можно сказать о смешивании с теми же стандартами кода, о которых говорил аскер. Я видел, как младшего парня отпустили как козла отпущения. Руководство жаловалось, что инженеры выпустили слишком много ошибок. Инженеры не могли сделать достойную работу, потому что руководство дает им фиксированные сроки. Таким образом, когда что-то идет не так, всегда есть младший парень, у которого больше ошибок, чтобы обвинить и отпустить. en.wikipedia.org/wiki/Dedovshchina
Работа
3
Одна вещь, которая выделялась для меня: «Они привыкли к парням, поэтому они не используют приличия». Я бы сказал, что вам нужно смириться с этим, если это явно не проблема дискриминации. Вы бы пошли на стройку и ожидали, что к вам будут относиться иначе, чем к остальным разработчикам? Крепчать. Если вы работаете в среде, где доминируют мужчины, вы должны уметь справляться с различными социальными нормами и приспосабливаться к ним так же, как и они. Не будь таким "чувствительным".
Rig
1
Я знаю, что уже несколько лет поздно, но я думаю, что это важная тема для будущих читателей. Не исключайте, что ваша команда просто лучше знает; он, вероятно, старше и разработал интуицию для проблемных стилевых проблем - я призываю любого в этой ситуации воспринимать это как возможность учиться и расти. С уважением просите разъяснений по вопросам, которые вы не понимаете, и будьте осторожны, чтобы не ошибочно истолковать сухую личность коллеги как злую.
weberc2

Ответы:

41

Есть вероятность, что вас выделят как женщину, но также возможно, что вы просто начинающий разработчик и новичок в этой работе.

Проверка ошибок и выразительные сообщения важны. Если вы собираетесь добавить что-то в код, убедитесь, что оно соответствует стандартам команды. Точно так же, если вы модифицируете чужой код, постарайтесь улучшить его там, где это возможно - не перезаписывайте все это целиком, но постарайтесь сделать его немного чище, чем вы его нашли.

Существует ли письменная версия стандартов кодирования, которой руководствуется ваша команда? Если нет, то это может быть хорошей идеей записать все это. Вы можете возглавить усилия, записав сделанные ошибки и сформировав их в контрольный список, к которому вы можете обратиться, прежде чем отправлять изменения на рассмотрение. В качестве побочного эффекта вы можете использовать этот письменный стандарт для обжалования будущих отклонений, если они противоречат ему.

Похоже, что между вами и руководителем команды может быть непонимание. Для вас может быть полезно попросить о встрече с ним один на один и обсудить, что вы можете сделать, чтобы улучшить ситуацию. Вы можете привести что-то вроде: «Я чувствую, что мне все еще не хватает многих нюансов того, что я должен делать. Как младший разработчик, я хочу расти и совершенствоваться. Можете ли вы помочь мне в этом?» и посмотрим, что получится.

Адам Лир
источник
Ответы Анны, как правило, очень разумны. +1. Я думаю, что работа там, где ты работаешь, сведет меня с ума. Ваше руководство не заботится о соблюдении сроков? Если код работает, отправьте его. Убери это позже. Черт возьми, вы можете даже очистить его в понедельник и протолкнуть его в следующем выпуске. Такое поведение вашего менеджера никогда не повлияет на мое место работы, и я рад, что могу сосредоточиться на соблюдении сроков вместо политики. Надеюсь, что ваша ситуация улучшится и вы найдете решение. :)
jmort253
11
@ jmort253 Спасибо. :) Тем не менее, «если код работает, отправьте его» может быть опасным отношением. Рабочий код не всегда хороший код (хотя он, безусловно, лучше, чем неработающий код), и качество кода важно в долгосрочной перспективе. Очистка позже почти никогда не происходит, так как появляются другие сроки и появляются более неотложные вещи. Для этого есть термин - «технический долг».
Адам Лир
@ Анна, согласна с важностью соответствия кода. Я читал, что несоответствующего кода достаточно, чтобы Линус Торвальдс на месте отклонил представленный патч для Linux (но я не могу найти его прямо сейчас).
@ Anna / Thorbjorn - Иногда нужно просто делать то, что хочет клиент, хотя, если есть крайний срок. Ваш клиент не очень хорошо понимает, потеряет ли он / она доход от бизнеса в 15 000 долларов, потому что вы просто хотели устранить ошибки капитализации. К сожалению, попытка устранить 100% технического долга не всегда возможна. Это все равно, что ждать 40 лет, чтобы накопить достаточно денег, чтобы купить дом своей мечты, а не брать ипотечный кредит. Конечно, вы были бы свободны и ясны, но вы бы потратили всю свою жизнь на дело с теневыми помещиками.
jmort253
Проекты с открытым исходным кодом отличаются от коммерческих проектов. Многие проекты с открытым исходным кодом могут позволить себе иметь более жесткие стандарты, потому что не всегда есть прибыль, которую можно получить / потерять. Частные проекты имеют разные цели, и иногда эти бизнес-цели имеют приоритет. Я не говорю, что код не должен соответствовать, просто иногда вам просто нужно делать то, что вам нужно, и иметь дисциплину, чтобы вернуться и исправить проблему после развертывания.
jmort253
25

Звучит так, как будто вы воспринимаете это слишком лично. Не; такого рода вещи случаются постоянно.

Причины отказа от регистрации (именование переменных, качество комментариев, расположение конфигурации) кажутся мне достаточно стандартными.

Время было выбрано решением вашей команды, и я не стал бы беспокоиться об этом на вашем месте. Если кто-то заблокирован на выходных, руководитель группы может разрешить регистрацию и попросить вас исправить ее после этого. Если он счел целесообразным отбросить его назад, даже если это может заблокировать некоторых других разработчиков, это его обязанность.

Что касается руководства команды, говорящего вам не подражать другим, а делать то, что правильно, похоже, он пытается дать вам некоторую инициативу, чтобы улучшить базу кода. Это хороший знак. Он доверяет вам использовать свое суждение, поэтому продолжайте и делайте то, что, как вы знаете, правильно. Это не значит, что вам нужно менять код других пользователей, но это означает, что вы должны взять на себя ответственность за качество написанного вами кода.

Эрик Кинг
источник
2
+1 Вы ориентируетесь на отношения и эмоции. Программисты, с которыми вы работаете, звучат очень сухо, но они просто сосредоточены на проблемах с кодом. Это довольно распространено в среде программирования, в которой я работал. Кстати, я видел это независимо от пола.
Майкл Даррант
14

Дополнение к другим ответам:

Как ведущий разработчик, я обычно более требователен к младшим разработчикам, потому что они гораздо более податливы, чем люди, которые работали в течение нескольких лет. (Мои навыки работы с людьми не так хороши ... пока.)

Очень трудно изменить человека, который некоторое время работал (и зарабатывал приличную зарплату) и был доволен уровнем своего кода (хотя качество можно было бы улучшить). Этим парням все равно, если вы попытаетесь направить их в становление лучше / лучше программистов. Они счастливы, работая на фабрике кодов.

Новые парни, как и вы, OTOH, обычно жаждут руководства и знания, что правильно, а что нет. Кроме того, они могут поглощать обратную связь и изменять свои пути к лучшему. Они не установлены по-другому.

Если вы примете эти советы близко к сердцу и сделаете их частью своей повседневной жизни, вы обнаружите, что в мгновение ока вы будете писать код, превосходящий большую часть существующей кодовой базы.

Так ...

... возможно, вы получаете больше отзывов только потому, что у вас есть потенциал, чтобы что-то из этого сделать. :)

Маке
источник
Это поднимает много хороших моментов.
sevenseacat
13

Вполне возможно, что вас выделяют, потому что ... вы младший разработчик.

Из вашего описания звучит так, будто вы не следовали стандарту, так как руководитель команды это воспринимает .

Решение простое:

  • Если это стандарт, следуйте ему.
  • Если вы не понимаете стандарт, попросите разъяснений.
  • Если ваша интерпретация стандарта или инструкций отличается от руководства группы, попросите разъяснений

Не делайте из этого битву; если вы попытаетесь заставить команду вести себя «неправильно», то даже если вы выиграете, вы проиграете. Выучите соответствующий урок и продолжайте расти.

Стивен А. Лоу
источник
1
Попытка следовать некоторому «стандарту» к «Т», когда кто-то имеет дело с придурками, как она описывает, не принесет много пользы. Это будет бесконечный спор по поводу определений и семантики.
MrDatabase
4
@MrDatabase Они не похожи на придурков для меня. Возможно, немного придирчиво, но дьявол часто в деталях, и как только вы начнете снижать свои стандарты, все ваше приложение может быстро падать.
Адам Лир
3
Это правда, что стандарты должны соблюдаться. Однако она ясно демонстрирует, что это не совсем стандарт (предыдущие разработчики не придерживались этого). Следовательно, ее коллеги, навязывающие ей «стандарт» (не говоря что-то вроде «эй, смотри… мы знаем, что это кажется непоследовательным, но мы действительно пытаемся улучшить нашу кодовую базу»), лицемерны и бесполезны. Когда коллеги ведут себя таким образом, вы должны придерживаться другого, более разумного подхода.
MrDatabase
@ user15859: если вы ссылаетесь на мой ответ, это вовсе не было моим намерением. Мне кажется, я сказал то же самое, что сказала Анна в своем ответе. Не было обид. Нарушения стандартов, которые вы упомянули, важны для долгосрочного обслуживания, и любая неясность в области применения стандартов должна быть решена с вашим руководителем группы. Если бы вы были ленивыми, вы бы не разместили здесь. Если бы ты был некомпетентен, тебя бы это не волновало. Я не верю, что вы один из тех.
Стивен А. Лоу
1
Я думаю, что она ссылается на то, что сказал Woot4Moot, когда он использовал «лень и некомпетентность» в качестве фразы в своем комментарии. Я думаю, что ваш ответ в порядке, поскольку он дает ОП некоторый выход и возможность принять меры на основе ее интерпретации того, что на самом деле происходит.
jmort253
10

Примечание автора

Несколькими годами позже; Я отредактировал это, чтобы более точно отразить, что я чувствую к ситуации. Я добавляю больше нюансов в свой ответ, потому что я больше узнаю о нюансах в этих ситуациях. Легко требовать «черного или белого» ответа, но мы все знаем, что это не так просто. Мой ответ теперь отражает это.

Из того, что вы описали; поведение, которое вы испытываете, никак не связано с вашим полом. Это не значит, что вы не подвергаетесь лечению по половому признаку (надеюсь, что нет), только то, что вы описываете, похоже, не связано с полом.

Когда я был руководителем команды, я относился ко всем одинаково. В технологиях нет места плохому отношению к кому-либо из-за его пола. Я не знаю, как с этим справиться, если это происходит с вами.

Важно, чтобы вы верили, что руководитель вашей команды одинаково относится к мужчинам и женщинам. Если есть доказательства того, что его нет, тогда применяется старое изречение: «Измени свою среду или измени свою среду».

В равной степени я имею в виду, что он относится ко всем одинаково, без уважения к полу. Если он делает свою работу правильно, вы не должны видеть его критиковать кого-либо еще; и они не должны видеть, как он критикует тебя. Перед другими очень важно, чтобы лидер команды проявил уверенность, даже если он просто провел последние пять минут, прежде чем исправлять поведение наедине.

Теперь к вопросам, которые вы подняли:

Вы зарегистрировали код, который не соответствовал установленному им стандарту, поэтому он отклонил вашу ветку. Если бы я был на его месте, я бы не сделал то же самое таким же образом, но я бы позаботился о том, чтобы мои подчиненные (странное слово; потому что я не считаю лидера «превосходящим» людей, которых они вести, но он точно (неадекватно) описывает ситуацию) знает, что правильно делать. Если они не знают, каковы стандарты, это моя вина как лидера. Это до меня, чтобы исправить это. В этом случае вы, возможно, допустили ошибку, но сам факт того, что это произошло, означает, что вы либо 1) не сказали, что нужно делать, либо 2) не получили должного наставничества. Ни ваша вина.

Одна из самых важных частей работы программиста - это понимание того, что кодовая база, над которой вы работаете, должна поддерживаться многими разными людьми. Любые переменные или другие вещи, которые отвлекают от возможности читать код , не прозрачны для клиента , потому что для устранения проблем в коде, который труднее читать, требуется больше времени.

Если ваша команда написала руководство по кодированию, следуйте им. Если они этого не делают, тогда должно быть какое-то соглашение сообщества для вашего языка (для .NET и C # у Microsoft есть стандарт, которому следуют многие компании).

Спросите своего руководителя группы, где находятся руководящие принципы кодирования, чтобы вы могли убедиться, что вы следуете им. Проведите две проверки на своих собраниях, где два других разработчика не всегда следовали рекомендациям, поэтому, когда он говорит, что их нет, вы можете указать, что у других, похоже, тоже есть проблемы с этим, и всем будет полезно иметь эти руководящие принципы.

Если он будет относиться к вам справедливо, то он это увидит, и это должно быть на вершине его списка дел. Если он не относится к вам справедливо, то у вас есть боеприпасы, если они продолжают происходить.

Сказать «я доберусь до этого позже» - плохо. Позже никогда не бывает. Потратьте время, чтобы сделать это правильно. Там нет позже в программировании.

Трудно, когда ты младший разработчик. Вы чувствуете себя вынужденным выступать, и многие люди смотрят на вас, и каждая ваша ошибка всегда связана с вашим именем в системе контроля версий.

Джордж Стокер
источник
1
Я добавлю комментарий о том, что "я доберусь до этого позже". Если бы у меня был никель за каждый раз, когда я это слышал, я бы не стал здесь печатать этот комментарий. :-)
Эрик Кинг,
Для .Net есть стиль полицейского. Включите его, чтобы код не создавался до тех пор, пока StyleCop не будет счастлив. Это устраняет человеческую субъективность - запугивание рабочей силы. Видите ли, технологии могут помочь вам решить, был ли Майкл Фелпс № 1 или № 2. Однако в фигурном катании ... figurekating.about.com/od/famousskaters/tp/scandals.htm Быть лидером команды не должно быть связано с отключением силы. В команде не должно быть фаворитов. Надо быть осторожным, чтобы такое впечатление не складывалось. Хороший способ сделать это - включить правила, которые будут проверять код и давать вам объективный ответ.
Работа
3

Нигде в вашем посте вы не упоминаете, как к окружающим относятся. Вы повторяете, что «чувствуете», что вас «выделяют», потому что вы «женщина».

Я думаю, что с вами обращаются как с младшим программистом, независимо от вашего пола, и вы должны быть благодарны за это, потому что это означает равенство. Я также чувствую, что вы сильно суетитесь из-за незначительных 5-минутных эстетических изменений кода, которые вас просят сделать сейчас, вместо того, чтобы помещать их в список дел и никогда не обходить их.

Нигде в вашем посте вы не упомянули, что вам приказали делать эти вещи на выходных. Это может быть прекрасно, чтобы проверить исправления в понедельник утром.

Ваш руководитель команды может быть немного педантичным на мой вкус, но из вашего поста я не вижу ничего плохого в его или ее просьбах.

Пожалуйста, перестаньте разыгрывать пол карты бесплатно . Я чувствую, что это недостойно и подрывает концепцию гендерного равенства.

idoby
источник
1

Я не чувствую, что отклонение моей ветви на этом основании полезно. В выходные работало много людей, и я никогда не говорил, что буду работать. По сути, некоторые люди, вероятно, были заблокированы, потому что у меня не было времени, чтобы внести изменения и повторно отправить. Мы работаем над проектом, который очень чувствителен ко времени, и мне кажется, что бесполезно отвергать код, основанный на вещах, которые прозрачны для клиента. Я могу ошибаться, но кажется, что такие вещи должны обрабатываться в коммитах типа патча, когда у меня есть время.

Трудно сказать что-нибудь полезное, потому что кто-то, кто не видел ваш код и не знает что-то о графике ваших проектов. Но если ваш ведущий ведет себя ответственно и хорошо выполняет свою работу, он знает, что другие действительно не были заблокированы, и спринт не опоздает. Так что не беспокойся об этом. Возможно, вы переоцениваете влияние на ваш коммит. В противном случае: если ваш проект критичен ко времени и проходит все тесты, было бы слишком придирчиво отклонять код, который можно исправить после выпуска в мгновение ока.

Сделать это сделать сделать это правильно сделать это быстро

Так что, если ваш лидер принял решение отклонить ваш коммит, как профессионал он должен знать, чем он занимается.

Теперь я вижу, что в некоторых условиях это будет нормой. Тем не менее, критика не выглядит равномерно распределенной, что и приводит к моей следующей проблеме. Основой большинства этих проблем было то, что я находился в кодовой базе, написанной кем-то другим, и пытался быть минимально инвазивным. Я имитировал имена переменных, используемых в других местах файла. Когда я это сказал, мне прямо сказали: «Не подражайте другим, просто делайте то, что правильно».

Будучи младшим, трудно найти какой-либо путь в кодовую базу компаний.

Лучше всего: есть документированные стандарты кодирования - и вы, надеюсь, научитесь их контролировать.

Обычно: существуют недокументированные стандарты кодирования - и вы должны учиться методом проб и ошибок, или я должен сказать commit и _reject? Это часто бывает больно (как в вашем случае). Иногда это опасно с точки зрения качества кода и может привести к программированию культового груза , где нужно не только имитировать именование переменных, но и добросовестно копировать и вставлять структуры и шаблоны из базы кода, это должно быть сделано именно так. Не делай этого! Даже не копируйте существующие имена переменных.

Придерживайтесь чистого кода . Это хорошая практика, которая позволяет легко защищать позицию. Если это читабельный, тестируемый и поддерживаемый код, вы в основном выиграли любое обсуждение.

И это приводит к другому (последнему) совету: следуйте правилу бойскаутов !

Всегда оставляйте кодовую базу в лучшем состоянии, чем было. Даже если окружающий код, с которым вы работаете, является неприятным, сделайте ваш чистый - и, если у вас есть время, исправьте окружение.

Томас Джанк
источник
0

Потратьте немного времени, чтобы узнать различные нюансы личности ваших коллег. По моему опыту, вы можете избежать иррациональной, ненужной, непоследовательной или просто бесполезной критики, если вы работаете вокруг своих странных уловок.

Например, некоторые коллеги могут быть похмелья по понедельникам. Они могут быть очень раздражительными и чрезмерно стремиться отклонить определенные ветви кода или коммиты. Если вам нужно работать с кем-то вроде этого, постарайтесь не делать код по понедельникам.

С другой стороны, похмельный коллега может быть слишком глуп, чтобы заботиться о многословности сообщений об ошибках ... поэтому утро понедельника может быть идеальным временем для фиксации вашего кода :-p

Причуды личности в офисе или на работе буквально бесконечны. Надеюсь, вы сможете узнать, кого избегать и когда избегать их. Также не будьте слишком строги к себе :-) Вы всегда можете бросить и найти другую работу!

MrDatabase
источник
1
Найдите работу, прежде чем уйти, многие менеджеры по найму даже не будут брать интервью, если вы не работаете.
Woot4Moo
-2

Я никогда не работал в среде, где код отклоняется на основании того, что не соблюдаются определенные соглашения. Если бы я был на вашем месте, я бы соблазнился искать работу в месте, где у меня больше возможностей принимать правильные решения, и где клиент находится в центре внимания, а не код.

Я не говорю, что чистый код и стандарты не важны, но клиент и временные рамки продукта не должны страдать из-за орфографической ошибки в том, что ни один не технический специалист, клиент или руководитель никогда не увидит.

С учетом вышесказанного может показаться, что вы работаете в среде, где ожидания не ясны, или вы по каким-либо причинам не до конца понимаете требования.

Независимо от ситуации, вы должны взять под свой контроль и задать уточняющие вопросы. Будьте активны, если вы еще этого не сделали. Члены вашей команды и руководитель группы, скорее всего, будут уважать вас больше за то, что вы задали вопросы, чтобы уточнить правила регистрации. Вы также можете попросить «обзор после действия», где вы и ваша команда обсудите, что вы должны были сделать вместо этого и как вы может сказать разницу, насколько когда предпринять определенные действия, а когда нет.

Я бы посоветовал уделить время, так как вы новичок, чтобы посмотреть, сможете ли вы преодолеть любые препятствия и решить эти проблемы с помощью опыта, общения и изучения стандартов. Однако, если по прошествии нескольких месяцев ситуация не изменилась, и обстановка все еще страдает от двусмысленности, возможно, пришло время искать работу в другой компании.

Не каждая организация такая драконовская, и вы можете найти другие рабочие условия, более подходящие для вашей личности, стиля и требований к общению.

jmort253
источник
2
Это не кажется "драконовским"; непротиворечивость является важным компонентом ремонтопригодности, ремонтопригодность является важным компонентом качества, а качественное программное обеспечение имеет гораздо больше шансов на своевременную доставку и с меньшими затратами, чем «компромиссный код». Может быть обнадеживающим, что около 80% компаний-разработчиков программного обеспечения стремятся поставить под угрозу качество и пострадают от последствий, поэтому, похоже, нет недостатка в «не драконовских» возможностях трудоустройства. :)
weberc2
1
Я не хотел бы работать в среде, где основные соглашения не соблюдаются. Если проект отказывается от защиты своих принципов кодирования, он обречен стать в дальнейшем недостижимым. В частности, присвоение имен переменам не является мелочью: независимо от того, насколько существующий код называется определенной матрицей A, я никогда не приму коммит, который вызывает другую матрицу Bдля согласованности. Конечно, я не знаю, что именно ОП подразумевал под «имитацией [...] имен, используемых в других местах», однако, учитывая качество некоторого кода, который я видел, он может быть в этом направлении.
Мастер