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

Тому я працюю над новим проектом разом зі своїм керівництвом за останні 1 рік.

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

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

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

Аргументи вище 2 питань:

1. Не бажаючи застосовувати стиль кодування для людей.
2. Розглядається як мовна особливість, яка піддається коротшому / більш ефективному коду.

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

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

Я помиляюся? Чи я нав'язую свої особисті переваги?

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

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

Гідне керівництво повинно мати можливість бачити в цьому заслугу, але це питання, про які вони будуть (і повинні) дбати: чи не простіше це розробникам чи "не хочуть змушувати всіх працювати як робот" (який є смішним моментом, але не використовуйте його як больову точку до керівництва). Вони (повинні) дбають про постійну стабільність проекту.

За моїм коментарем вище:

Якщо він є керівником проекту, це, мабуть, означає, що це в основному його заклик.

То була моя думка. Якщо ви хочете змінити стандарт, але він не відступає від нього, або: а) з'ясуйте, як вийти на нього вище; забагато.

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

В основному:

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

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

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

Це також часто залежить від того, як ви запитуєте. Приклади:

Що ти хочеш:

зробити код гарнішим

Що не сказати:

ваш код смокче так, як є

Що сказати:

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

Що ти хочеш:

більше не перевірених попереджень

Що не сказати:

ваш код смокче так, як є

Що сказати:

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

І останнє:

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

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

Бічна примітка

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

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

Ми поговорили і домовилися не погодитися і передати це до вищого керівництва

Ніколи. Колись. Робити. Це. ВСЕ. Кожен раз, коли ви це робите, це ставить нас усіх на десятиліття. Ось як це вийде:

• Старший менеджер 1: "Нас попросили розібратися з цим питанням, бла, бла, щось про стандарти кодування та витрачання часу".

• Старший керівник 2: "І вони просять нас врегулювати їхні бойові війни за дерни?"

• Старший менеджер 3: "Тому що вони кричущі діти, які не вміють спілкуватися і не байдуже / розуміють, що таке цінність бізнесу?"

• Старший менеджер 2: "Це повинно бути. Хто займається гольфом?"

Потім настає час перегляду ви та вашого начальника:

"[старший керівник вашого начальника]: Вибачте, але є певна стурбованість тим, що ви не в змозі керувати своїми прямими звітами і, можливо, не дотримуєтесь кращих практик (хоча я навіть не маю уявлення, що ви робите, за винятком набору якоїсь мамбо джамбо що робить програмне забезпечення справним) "

"[старший керівник вам]: Вибачте, але є певне занепокоєння, що ви не ставитесь до своїх однолітків і не маєте проблем виконувати вказівки вашого безпосереднього керівника."

І тому ми здебільшого недооплачуємо порівняно зі значенням, яке ми створюємо. **

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

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

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

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

ІМХО, ти стикаєшся з розробником "він працює", а не тим, хто би піклувався про те, щоб наступний пішов за ними. Його аргументи просто марні.

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

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

Але я, швидше за все, відповім тобі щось:

Це працює, немає сенсу міняти

Моя порада: якщо він справді тупий і не хоче нічого очолювати, відпустіть це. Зачекайте, коли в його проекті відбудуться помилки / помилки / еволюція. Коли мова заходить, просто виправте і перепишіть частину коду, модифікованого / доданого належним чином; не йдіть до нього, щоб нічого про це сказати. Він не буде нав'язувати вам свій стиль кодування, оскільки ви все одно не робот ....

Працюючи над проектом, ви повинні встановити пріоритети.

Пріоритет №1 - це ладити з колегами. Пріоритет №1 супроводжується величезною прогалиною. Потім приходять пріоритети для таких речей, як код, який працює, перевіряється, перевіряється, документально підтверджується, підтримується і т.д.

І зміна існуючого коду на відповідність новим стандартам кодування дійсно мало в списку пріоритетів.

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

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

PHP - не сама елітна група в нашій професії. Насправді ви критикуєте його, ймовірно, важко виграну програмну систему. Ваш професійний стандарт вищий, ніж його.

Тоді, якщо у вас немає свободи для вдосконалення коду під свої обов'язки, існує лише одне рішення: рухайтеся далі .

Я не знаю про поточний ринок PHP у вас, але ви, можливо, спочатку дещо диверсифікуєтесь. Вивчіть також якусь мову hype або таку нішу, як C #.

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

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

Чи виправлення стилю бази коду найкраще використовувати ваш час саме зараз?

Я впевнений, що у вас є результати. Скільки часу буде коштувати пройти та вдосконалити стиль скрізь в іншій кодовій базі? Що робити, якщо ви вводите помилки, неправильно виправляючи стиль? Від дядька Боба:

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

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

Таким чином, кожна зміна:

1. Має ділову мотивацію на додаток до технічного перфекціонізму
2. Не буде розглядатися як велика інвестиція у часі (адже це не так!)
3. Встановлюватимуть добрі стилістичні звички саме тому, що ви та ваша команда це робите з часом
4. Не представлятиме великого ризику для кодової бази, оскільки ви не змінюєте занадто сильно відразу

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

Задайте ці питання щодо свого ведучого.

• Вони звикли працювати поодинці або з дуже маленькою командою?
• Вони в основному кодували в цьому одному магазині?
• Чи звикли вони приймати рішення?
• Вони звикли "просто робити це"?
• Вони написали більшу частину коду?

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

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

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

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

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

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

У вас є проблема людей, а не технологічна.

Вам доведеться перекваліфікувати керівництво, або вам доведеться відмовитися.

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

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

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

Поставтеся до його стилю всерйоз і заходьте всередину голови. Запитайте його про це. Чому він робить так, як робить? Що він бачить, коли читає? Як це взаємодіє з його інструментами? Як він рухається через код? Знання всіх цих речей дозволить зрозуміти та вирішити його заперечення.

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

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

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

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

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

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

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

Я помиляюся?

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

Тоді ви не помилитеся запропонувати вдосконалення стилю кодування.

Підсумок, а не код, з яким я хочу працювати

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

Чи я нав'язую свої особисті переваги?

Ні. Він керівник проекту, а ви - ні. Це його дзвінок, хоча в цьому випадку він "делегований вгору".

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

Однак, оскільки він каже: "Мені не подобається застосовувати стилі кодування", ви можете принаймні написати новий код у своєму бажаному стилі (і зробили це). У кінцевому підсумку це може призвести до можливості демонструвати об'єктивні переваги вашого стилю. Це був би хороший час, щоб зайнятися вашою справою.

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

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

[Мій менеджер каже, що він не любить застосовувати стилі кодування на людях [тому, що ми - не роботи.

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

Рано чи пізно у когось з’явиться причина повернутися назад і прочитати код. Можливо, їм потрібно буде це змінити, можливо документувати, можливо, повторно використати. Що б там не було. Це відбудеться, і з кодом буде набагато простіше читати та працювати з ним, якщо це все в послідовному стилі.

Навіть поганий стиль краще, ніж взагалі ніякий стиль.