Несогласие с руководителем проекта по стандартам кодирования [закрыто]

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

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

Теперь, когда я являюсь ведущим разработчиком обоих подпроектов (команда собирается расти; он все еще выше меня), эти вещи беспокоят меня, и я хотел позаботиться о них, но мне было отказано:

1. Никаких фигурных скобок, заглавные функции, использование смешанных кавычек (двойные и одинарные с скрытой логикой), без использования ===, огромные классы с огромными функциями. Итог, может быть лучше.
2. Опора PHP на отключение уведомлений / предупреждений. Код полон непроверенного использования переменных и ключей массива. Переменные определяются внутри ifs.

Аргументы выше 2 вопросов:

1. Не желая навязывать стиль кодирования людям.
2. Рассматривается как языковая функция, которая предоставляет более короткий / более эффективный код.

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

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

Я ошибаюсь? Навязываю ли я свои личные предпочтения?

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

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

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

За мой комментарий выше:

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

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

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

В принципе:

• вы не нравится его стиль кодирования. Это твое право.
• он считает, что все в порядке, как он есть, и считает, что тратить дни / недели / больше на настройку стиля - пустая трата времени . Это его право.

Поставь себя на его место. Каковы преимущества вашей деятельности, помимо того, что она стоит компании много денег (ваша зарплата)? Он всегда такой придирчивый? Разве он не видит, что сейчас есть более важные дела?

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

Это также часто зависит от того, как вы спрашиваете. Примеры:

То, что ты хочешь:

делая код красивее

Что не сказать

ваш код отстой, как он есть

Что сказать:

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

То, что ты хочешь:

больше нет непроверенных предупреждений

Что не сказать

ваш код отстой, как он есть

Что сказать:

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

И наконец:

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

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

Примечание

Я думаю, что более старшие люди более снисходительны. Они знают, что код будет уничтожен через десять или два года (потому что технологии меняются, API тоже, команды, деловые партнеры, требования, глобальные решения, что угодно ...). У них меньше эго и они сосредоточены на том, чтобы оно работало, а не было идеальным. Хотя я сам стремлюсь к совершенству, я не могу их винить.

Это, вероятно, будет спорным, но ...

Мы поговорили и согласились не согласиться и передать это высшему руководству.

Никогда. Когда-либо. Делать. Эта. КОГДА-ЛИБО. Каждый раз, когда вы делаете это, это отбрасывает нас всех назад на десятилетие. Вот как это будет разыгрываться:

• Старший менеджер 1: «Нас попросили разобраться с этой проблемой, бла, бла, бла, кое-что о стандартах кодирования и напрасной трате времени».

• Старший менеджер 2: «И они просят нас разрешить их войны за ботаников, потому что?»

• Старший менеджер № 3: «Потому что это плаксивые дети, которые не могут общаться и не заботятся / не понимают, какова ценность бизнеса? *»

• Старший менеджер 2: «Должно быть, так. Кто за гольф?»

Затем наступает время проверки эффективности работы вас и вашего босса:

«[старший менеджер вашего босса]: извините, но есть некоторые опасения, что вы не можете управлять своими прямыми отчетами и, возможно, вы не следуете передовым методам (хотя я понятия не имею, что вы делаете, кроме ввода некоторого mumbo jumbo»). что делает программное обеспечение работоспособным)

«[старший менеджер для вас]: извините, но есть некоторые опасения, что вы плохо относитесь к своим сверстникам и не можете следовать указаниям своего непосредственного руководителя».

И именно поэтому нам в основном недоплачивают по сравнению с ценностью, которую мы создаем. **

Вам нужно либо А) преодолеть это, либо Б) перейти в магазин, где стандарты настроены немного ближе к вашему вкусу. FWIW, я бы сделал B (и надеюсь перейти к языку, который не допускает таких злодеяний). Но никогда не перерастайте технический спор в иски, если это не связано с чем-то незаконным или потенциально катастрофическим (зияющая дыра в безопасности). Просто раздражает не разрезать это ***.

* Ради людей, которые прочитают это и поймут неправильно, я не говорю, что ОП и его начальник такие (я понимаю, что качество / разборчивость кода напрямую влияет на итоги бизнеса), я говорю что они будут восприняты нетехническим руководством.

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

*** Да, я понимаю, что технический долг может накапливаться до такой степени, что может затопить бизнес. Я просто не думаю, что фигурные скобки спасут вас (при этом я никогда не опускаю скобки и настоятельно предпочитаю, чтобы другие тоже не делали).

ИМХО, вы сталкиваетесь с «работающим» разработчиком, а не с тем, кто будет заботиться о следующем, преследующем их. Его аргументы просто бесполезны.

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

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

Но я, скорее всего, отвечу вам чем-то таким тоном

Это работает, нет смысла менять

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

Когда вы работаете над проектом, вы должны установить приоритеты.

Приоритет № 1 - ладить с коллегами. Приоритет № 1 сопровождается огромным разрывом. Затем идут приоритеты для таких вещей, как код, который работает, тестируется, тестируется, документируется, поддерживается и т. Д. Затем появляется еще один огромный пробел, а затем появляются стандарты кодирования.

А изменение существующего кода в соответствии с новыми стандартами кодирования действительно находится в списке приоритетов.

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

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

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

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

Я не знаю о текущем рынке PHP у вас, но вы могли бы сначала немного диверсифицировать. Выучите также немного рекламы или нишу, подобную C #.

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

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

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

Я уверен, что у вас есть результаты. Сколько времени будет стоить пройти и улучшить стиль повсюду в другой кодовой базе? Что делать, если вы вводите ошибки, исправляя стиль неправильно? От дяди Боба:

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

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

Таким образом, каждое изменение:

1. Имеет бизнес-мотивацию в дополнение к мотивации технического перфекционизма
2. Не будет рассматриваться как большие затраты времени (потому что это не так!)
3. Устанавливает хорошие стилистические привычки именно потому, что вы и ваша команда делаете это со временем
4. Не будет представлять большой риск для базы кода, потому что вы не меняете слишком много сразу

Через несколько месяцев вы увидите и заметите, что «ужасный пакет» уже не так уж плох, и ваш начальник увидит, что его команда счастливее. Но поскольку это не было прямой конфронтацией, это уже будет сделано, и ему не на что будет жаловаться, потому что вы не потратили время (по его мнению), добавив большой проект по рефакторингу в список дел. Скорее всего, он никогда не скажет вам, что вы были правы, но в любом случае это не цель (верно?).

Задайте эти вопросы о своем руководстве.

• Они привыкли работать в одиночку или с очень маленькой командой?
• Они в основном закодированы в этом магазине?
• Они привыкли принимать решения?
• Они привыкли "просто делать это"?
• Они написали большую часть кода?

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

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

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

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

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

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

У вас проблема с людьми, а не технологическая.

Вам придется переучить свое лидерство, или вам придется бросить.

Переход к управлению является последним средством . И по причинам, указанным @JaredSmith, и потому, что вы проиграете. Этот парень годами зарабатывал для них деньги. Он написал свою компанию. Он потушен в многочисленных пожарах. Для вас он ковбой шеф-повар делает спагетти. Для них он герой, который построил и спас компанию.

Для переподготовки вам придется ...

• Завоевать его доверие.
• Выясни, как он думает.
• Устраните его страхи по поводу перемен.
• Сделай переодевание проще
• Покажите, как это лучше для него .

Относись серьезно к его стилю и проникни в его голову. Спроси его об этом. Почему он делает то, что делает? Что он видит, когда читает? Как это взаимодействует с его инструментами? Как он перемещается по коду? Знание всех этих вещей позволит вам понять и устранить его возражения.

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

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

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

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

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

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

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

Я ошибаюсь?

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

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

Итог, а не код, с которым я хочу работать

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

Навязываю ли я свои личные предпочтения?

Нет. Он руководитель проекта, а вы нет. Это его призыв, хотя в этом случае он «делегирован вверх».

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

Тем не менее, поскольку он говорит: «Мне не нравится применять стили кодирования», вы можете, по крайней мере, написать новый код в своем предпочтительном стиле (и сделали это). В конечном итоге это может привести к возможности продемонстрировать объективные преимущества вашего стиля. Это было бы хорошее время, чтобы еще раз попытаться сделать ваше дело.

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

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

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

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

Рано или поздно у кого-то появится причина вернуться и прочитать код. Может быть, они должны будут изменить это, возможно, чтобы документировать это, возможно, чтобы использовать это снова. Без разницы. Это произойдет, и код станет намного проще для чтения и работы, если все будет в едином стиле.

Даже плохой стиль лучше, чем отсутствие стиля вообще.