Стандарты Python Coding против производительности

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

В этом проекте меня беспокоит то, что я считаю чрезмерным акцентом на стандартах кодирования. Мы пишем в python / django и используем версию PEP0008 с различными модификациями, например, длина строки может доходить до 160 символов, и все строки должны идти так долго, если это возможно, без пустых строк между импортами, правила переноса строк, которые применяются только к определенным видам классов, множество шаблонов, которые мы должны использовать, даже если они не лучший способ решить проблему и т. д. и т. д.

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

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

Это начинает становиться липким. Теперь я пытаюсь изменить различные скрипты, autopep8, pep8ify и PythonTidy, чтобы соответствовать соглашениям. Мы также запускаем pep8 для исходного кода, но в нашем стандарте так много неявных поправок, что их сложно отследить. Lead dev simple выбирает ошибки, которые не распознает сценарий pep8, и выкрикивает нас на следующем совещании. Каждую неделю появляются новые дополнения к стандартам кодирования, которые заставляют нас переписывать существующий, работающий, проверенный код. Слава Богу, у нас все еще есть тесты (я отменил некоторые коммиты и исправил кучу тех, которые он удалил).

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

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

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

Стандарты кодирования не являются проблемой. Проблема в том, что руководство не может понять, в чем проблема. Это приводит к "Делай что-нибудь ... что-нибудь!" Режим. Вы ищете рациональное решение, но это иррациональная проблема. Лучшее, что вы можете сделать, это:

• Дайте конструктивную критику их идей, но как только решение будет принято, не жалуйтесь постоянно.
• Делайте все возможное, чтобы облегчить переписывание.
• Прекратите подчеркивать. Пропущенные сроки - это проблема руководства, а не ваша. Делайте все возможное, но не берите на себя ответственность за свои плохие решения.
• Если вы знаете что-то, что может помочь, скажите им. Ваше упоминание о standups звучит так, будто вы пытаетесь сделать Agile, но все остальное звучит не очень гибко. Посмотрите, сможете ли вы предоставить ограниченную функциональность раньше, вместо того чтобы пытаться уложиться в один большой срок со всем Создавайте пользовательские истории для переписывания, чтобы было ясно, как они влияют на отставание.
• Начните искать другую работу. Шутки в сторону. Компании в таком состоянии не за горами, чтобы начать увольнять людей.
• Распечатайте футболки с надписью "так вам" :-)

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

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

Я ошибаюсь, ставя под сомнение их приверженность стандартам кодирования?

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

Кто-нибудь еще сталкивался с подобной ситуацией и как они успешно с ней справились?

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

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

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

Если это на самом деле было внесено позднее в проект, то это ошибка вашего лидера (ИМХО).

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

В конце концов, соблюдая его требования и стандарты, вы не предоставляете ему легкого козла отпущения за несоблюдение сроков.

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

Ваш вопрос был «Я ошибаюсь, ставя под сомнение их приверженность стандартам кодирования?». На сайте http://c0x.coding-guidelines.com/Introduction.pdf (для языка программирования C) приводятся некоторые исследования, посвященные ценности руководящих принципов кодирования. См. Раздел 9, начиная со страницы 39.

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

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

Похоже, что с обеих сторон много эмоций - попробуйте перейти к обоснованному обсуждению.

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

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

Постарайтесь подтолкнуть дискуссию в направлении поиска путей достижения вашей общей цели; своевременная поставка работающего и обслуживаемого программного обеспечения.

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

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

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

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

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

Я верю в хорошие стандарты кодирования, но я также считаю, что спасение жизней гораздо важнее.

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

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