Стандарти кодування Python порівняно з продуктивністю


18

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

Одне, що мене хвилює в цьому проекті, - це те, що, на мою думку, є надмірна увага до стандартів кодування. Ми пишемо в python / django і використовуємо версію PEP0008, з різними модифікаціями, наприклад, довжина рядків може доходити до 160 символів, а всі рядки повинні проходити так довго, якщо можливо, відсутні порожні рядки між імпортом, правила обгортання рядків, які застосовуються лише до певних видів класів, багато шаблонів, які ми повинні використовувати, навіть якщо вони не найкращий спосіб вирішити проблему тощо.

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

Сьогодні я потрапив у серйозну проблему, бо забув поставити пробіли після коми в аргументі ключових слів. Мене буквально кричали двоє інших розробників та керівник проекту під час дзвінка по Skype. Особисто я вважаю, що стандарти кодування є важливими, але також думаю, що ми витрачаємо багато часу нав'язливістю з ними, і коли я вербалізував це, це викликало лють. Мене сприймають як проблему в команді, команду, яка шукає козлів відпущення за свої невдачі. З часу запровадження стандартів кодування продуктивність команди помірно скоротилася, однак це лише посилює одержимість, тобто провідний розробник просто звинувачує наше недотримання стандартів у відсутності прогресу. Він вважає, що ми не можемо читати код один одного, якщо не дотримуємось конвенцій.

Це починає ставати липким. Тепер я намагаюся змінювати різні сценарії, autopep8, pep8ify та PythonTidy, щоб спробувати відповідати умовам. Ми також запускаємо pep8 проти вихідного коду, але є так багато неявних поправок до нашого стандарту, що їх важко відстежити. Провідний розробник простий вибирає помилки, що сценарій pep8 не підбирає, і кричить на нас на наступній черговій зустрічі. Щотижня з’являються нові доповнення до стандартів кодування, які змушують нас переписувати існуючий, робочий, перевірений код. Дякую небесам, у нас ще є тести (я відмінив деякі зобов’язання і виправив купу тих, які він вилучив).

Весь час посилюється тиск, щоб дотриматись цього терміну.

Я вважаю, що принциповим питанням є те, що провідний розробник та інший основний розробник відмовляються довіряти іншим розробникам робити свою роботу. Але як з цим боротися? Ми не можемо робити свою роботу, тому що ми занадто зайняті, щоб все переписувати.

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


4
Пам'ятайте, що стандарти кодування призначені для збільшення довгострокової продуктивності. Це відбувається за рахунок короткострокової продуктивності, якщо існуючий проект тривалий час не дотримувався жодного стандарту.
Арсеній Муренко

1
Просто запрограмуйте Eclipse та PyDev для автоматичного форматування коду відповідно до стандартів кодування. Справа в заповненні кількох діалогових вікон.
user16764

1
@DemianBrecht - авторські стандарти кодування, які визначаються та погоджені всіма кодерами, є хорошою справою і може підвищити довгострокову продуктивність. Авторитарний стандарт кодування, накладений зверху, не купуючи команди, є величезною марною тратою часу і може приректи проект на стагнацію або навіть регресію, як, наприклад, так званий провідний розробник, який викидає тести, тому що код перетворився на Новий стандарт не зміг цих тестів. Чесно кажучи, WTF?
Марк Бут

1
@MarkBooth: Ви не можете порадувати всіх. Я погоджуюсь, що якщо це просто нав’язано зверху, то складніше отримати покупку у інших членів, але все одно це не "величезна трата часу". При застосуванні стандартів код повинен бути набагато послідовнішим, і тому ви зіткнетеся з меншим розмаїттям коду впродовж проекту, що збільшує читабельність. Але так .. Відкидання тестів через стандарти привело б мене до думки, що під капотом виникають більші проблеми.
Дем'ян Брехт

1
@Demian Brecht: Я впевнений, що основним моментом у цьому питанні є не стандарт кодування як такий, а те, що косметичні проблеми з кодом набувають більшого пріоритету, в основному, ніж будь-що інше в проекті, який запізнюється і має велике значення .
Бух

Відповіді:


27

Стандарти кодування не проблема. Проблема полягає в тому, що керівництво не може зрозуміти, в чому проблема. Це призводить до "Зроби щось ... будь-що!" режим. Ви шукаєте раціональне рішення, але це ірраціональна проблема. Найкраще, що ви можете зробити:

  • Надайте конструктивну критику їх ідеям, але як тільки рішення буде прийнято, не пишіть про це постійно.
  • Зробіть все можливе, щоб полегшити переписування.
  • Перестаньте напружуватись. Пропущені терміни - це проблема управління, а не ваша. Робіть все можливе, але не берете на себе відповідальність за свої погані рішення.
  • Якщо ви знаєте щось, що може допомогти, скажіть їм. Згадавши про стендів, це звучить так, ніби ви намагаєтеся зробити спритне, але решта не дуже спритно. Подивіться, чи можете ви раніше надати обмежений функціонал, а не намагатися дотриматись одного великого терміну. Створіть історії користувачів для переписувачів, щоб було зрозуміло, як вони впливають на відставання.
  • Почніть шукати іншу роботу. Серйозно. Компанії в такому стані недалеко від того, щоб почати звільняти людей.
  • Отримайте роздруковані футболки "так вам сказали" :-)

Хороші бали. Насправді я не проти стандартів кодування, наприклад, нове доповнення до стандартів під час останньої зустрічі полягало в тому, щоб наказувати доктрини для кожного класу та функції, що для мене має сенс, і я в основному це роблю. Гроші занадто гарні, щоб шукати іншу роботу. Я спробував переформатори коду, хоча я запропонував його команді, провідний розробник заборонив їх використання. Я працюю віддалено, і це правило неможливо застосувати, тому я знаходжу pep8ify саме той, який використовується, оскільки він змушує код просто пройти стандарт, тому він виглядає як редагування людини. Тобто це робить мінімальні модифікації.
Shroatmeister

1
Додам, що термін буде пропущений, майже напевно. Це марш смерті, і хтось спробує звинуватити вас. Просто не забудьте документувати все: слідкуйте за тим, скільки часу ви витрачаєте на кожне завдання, архівуйте всі листи та / або журнали чату, щоб ви могли захистити себе.
coredump

7

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

Проблеми з пробілами після коми легко вирішуються засобом для введення коду. Знайдіть інструмент, який застосовує всі ваші умови кодування, та запустіть цей інструмент у всіх модифікованих кодах до того, як відбудеться збірка та тестування. Достойні IDE вже роблять це, поки ви пишете код.


Я знайшов pep8ify корисним для цього переформатування. Здається, що вони роблять мінімальні зміни, щоб відповідати стандартам, і код легко змінювати, хоча конфігурація командного рядка дещо обмежена.
Shroatmeister

4

Чи помиляюся я в питанні їх дотримання стандартів кодування?

Це залежить від групи. Особисто я вважаю, що все слід ставити під сумнів. Деякі люди сприймають це запитання як загрозу; що я їм не вірю.

Хто-небудь ще переживав подібну ситуацію і як вони успішно впоралися з нею?

Я запитав, як ці стандарти покращують продуктивність. Я виміряв час, який я витратив на вивертання, зі стандартами проти "отримання речі". Зрештою, повноваження, які вирішили дотримуватися стандартів. Це буває. Я скаржився на них голосніше, ніж зазвичай, коли вони стали причиною того, що я не робив справи, але в іншому випадку зосередився на тому, щоб виконати свою роботу. Боротьба з речами постійно не є корисною для продуктивності ...

Якщо, як ви кажете, все помітно гірше через стандарти, то дотримання стандартів повинне визнати аргумент ведучого і залишити своє. Якщо люди не можуть побачити, що (значною мірою) об'єктивна кореляція між впровадженням стандарту та падінням продуктивності праці, ви не можете зробити багато іншого. Навчіться боротися з цим, а якщо не можете, шукайте дещо менш бюрократичне.


3

Стандарти - це те, що не повинно бути впроваджено пізнім проектом із закінченням строку. Це щось, що повинно було бути застосовано на початку проекту або коли в графіку проекту буде відкладено час (бажано, після початкового відправлення) для (потенційно) великого рефактора коду.

Якщо це було насправді зафіксовано в проекті, то це помилка, зроблена вашим керівником (ІМХО).

Однак це не означає, що якщо ви не погоджуєтесь з вашими зусиллями, вам слід просто заздалегідь порушити заколот. Це ваша робота . Ви працюєте як команда . У вас є ведучий . Однозначно має бути певний рівень демократичності в колективі, але, зрештою, лідирує диктатор. Якщо він каже щось зробити, ти роби це.

Зрештою, виконуючи його запити та стандарти, ви не надаєте йому / їй легкого козла відпущення за пропущені терміни.

Також я величезний прихильник стандартів кодування (особливо, коли кількість команд зростає), але їх слід реалізовувати, коли це має сенс.


1

Ваше запитання було: "Чи помиляюсь у питанні їхньої дотримання стандартів кодування?". http://c0x.coding-guidelines.com/Introduction.pdf (для мови програмування на C) має ряд посилань на дослідження значення вказівки щодо кодування. Див. Розділ 9, починаючи зі сторінки 39.

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

По-друге, те, що хтось сказав, що стандарти реалізовані для «довгострокової продуктивності» - такі питання, як ремонтопридатність коду. Можливо, сталася якась подія, яка сильно повернула проект через плутанину та неправильне тлумачення.

Здається, що в обох сторін багато емоцій - спробуйте перейти до аргументованої дискусії.


1

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

Попросіть зустрітися між чотирма очима у свого головного розробника. Скажіть, що вам цікаво глибоко зрозуміти переваги бути настільки суворими зі стандартом кодування, і чому база даних кода була в такій поганій формі перед їх введенням. Дуже важливо, щоб ви тримали дуже відкрите і "я намагаюся вчитися" ставлення під час цієї дискусії. Ваш головний розробник, мабуть, вже більше підкреслений, ніж ви або хтось інший у вашій команді, і, ймовірно, буде дуже захисним, як тільки він відчує певну критику.

Спробуйте підштовхнути дискусію в бік спроб з'ясувати способи досягнення вашої спільної мети; оперативне забезпечення робочого та ремонтованого програмного забезпечення.

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

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


-2

Стандарти кодування хороші. Зміна стандартів кодування є дорогим (ну, і дорого, якщо ви робите їх менш дозволеними; якщо зміна стандарту залишає весь існуючий код ще сумісним, це не проблема), тому це слід робити лише при абсолютно необхідності.

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


-3

програмне забезпечення, яке може допомогти врятувати життя в надзвичайних ситуаціях, прискоривши розповсюдження їжі

Я вірю в хороші стандарти кодування, але я також вірю, що врятувати життя набагато важливіше.

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

Хороша новина: у вас є тести. Тести допоможуть вам відповідати стандартам кодування, не порушуючи функціональність, але це має відбутися після доставки , не раніше.


1
Що повинно статися після доставки? Відповідати стандартам кодування без порушення функціональності? Маєте тести?
Martijn Pieters

Після доставки він повинен працювати над дотриманням стандарту кодування.
Мохаммед Тейзер
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.