Як сказати комусь, що він пише неправильний код? [зачинено]

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

Введіть питання, щоб вони зрозуміли, що те, що вони роблять, - це неправильно. Наприклад, задайте такі запитання:

Чому ви вирішили зробити цю глобальну змінну?

Чому ви назвали це ім'я?

Це цікаво. Я зазвичай роблю так, тому що [Вставити причину, чому ти кращий]

Це працює? Я зазвичай [Вставте, як би ви зробили їх дурними]

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

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

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

Почніть робити огляди коду або програмувати пар.

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

Як сказав @JesperE: зосередьтеся на коді, а не на кодері.

Коли ви бачите щось, на вашу думку, це має бути інакше, але інші не бачать це однаково, тоді почніть із запитання, що призводить до недоліків, а не вказувати на них. Наприклад:

Глобали : Як ви думаєте, ми коли-небудь захочемо мати більше одного з них? Як ви думаєте, ми хочемо контролювати доступ до цього?

Стан, що змінюється : Ви думаєте, ми хочемо маніпулювати цим з іншої теми?

Я також вважаю корисним зосередитись на своїх обмеженнях, які можуть допомогти людям розслабитися. Наприклад:

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

погані імена : я легко плутаюсь при читанні чіткого коду; коли імена вводять в оману, для мене немає надії.

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

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

Ви повинні пояснити, чому ваш шлях кращий .

Поясніть, чому функція краще, ніж вирізати та вставляти.

Поясніть, чому масив краще, ніж $ foo1, $ foo2, $ foo3.

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

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

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

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

Ще один варіант - принести технічні книги в офіс (Code Complete, Effective C ++, Pragmatic Programmer ...) і запропонувати позичити його іншим ("Гей, я закінчував це, хтось хотів би взяти його в борг?" )

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

Запропонуйте кращу альтернативу безконфліктним способом.

"Гей, я думаю, що і цей спосіб спрацює. Що ви думаєте, хлопці?" [Жест очевидно кращого коду на екрані]

Перегляньте код і почніть з перегляду ВАШОГО коду.

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

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

На прикладі. Покажіть їм правильний шлях.

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

Ідея кодового стандарту хороша.

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

У книзі Джеррі Вайнберга «Психологія комп’ютерного програмування» є кілька дійсно хороших порад - все його поняття «безпроблемне програмування» - це те, як допомогти людям сприймати критику свого коду як відмінну від критики себе.

Погані практики іменування: завжди невиправдано.

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

У мене був досвід роботи з кодером, який мав такі жахливі назви функцій, код був гіршим, ніж нечитабельний. Функції брехали про те, що вони робили, код був безглуздим. І вони були захисними / стійкими до того, щоб хтось інший змінив свій код. коли дуже ввічливо зіткнулися, вони визнали, що вона названа погано, але хотіла зберегти право власності на код і повернеться назад та виправить це "пізніше". Це вже було в минулому, але як ви вирішите ситуацію, коли вони помиляються НАПРЯМО, а потім захищають? Це тривало довгий час, і я не мав уявлення, як пробити цей бар’єр.

Глобальні змінні: Я сам не люблю глобальні змінні, але знаю декількох інакше чудових програмістів, які їм подобаються ЛОГО. Настільки, що я повірив, що насправді це не так вже й погано в багатьох ситуаціях, оскільки вони дозволяють зрозуміти, легко налагоджувати. . неможливо читати / підтримувати / виправляти код, який ретельно використовував належні шаблони. Може бути , є IS місце (хоча скорочення можливо) для глобальних змінних? Я розглядаю можливість переосмислити свою позицію на основі доказів.

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

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

Вкажіть на це всіх. Дозволити для зворотного зв'язку

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

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

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

Якщо у вас немає формату кодування, зараз би вдалий час встановити його. Щось на зразок відповідей на це питання може бути корисним: /programming/4121/team-coding-styles

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

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

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

"Кожен може написати код, який розуміє машина, але не всі можуть написати код, зрозумілий людині"

маючи це на увазі, в коді потрібно багато зробити;)

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

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

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

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

Терпіння. Еволюція, а не революція.

Удачі.

Я надягаю тогу і відкриваю банку сократичного методу.

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

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

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

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

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

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

• Власний досвід людей залишає сильніше враження, ніж щось, що ви скажете.
• Деякі люди не захоплені кодом, який вони виробляють, і не слухатимуть нічого, що ви говорите
• Парне програмування може допомогти ділитися ідеями, але перемикати, хто їздить, або вони просто перевірятимуть електронну пошту на своєму телефоні
• Не заглушуйте їх занадто багато, я виявив, що навіть постійну інтеграцію потрібно кілька разів пояснити деяким старшим дияволам
• Збудьте їх знову, і вони захочуть вчитися. Це може бути щось таке ж просто, як програмування роботів на день
• ДОВІЙТЕ ВАШУ КОМАНДУ, стандарти кодування та інструменти, які перевіряють їх під час збирання, часто ніколи не читаються і не дратуються.
• Видаліть власність коду, на деяких проектах ви побачите силосні коди або мурашині пагорби, де люди кажуть, що це мій код, і ви не можете його змінити, це дуже погано, і ви можете використовувати парне програмування, щоб видалити це.

Замість того, щоб вони писали код, нехай вони підтримують свій код.

До тих пір, поки їм не доведеться підтримувати свою пару спагетті, вони ніколи не зрозуміють, наскільки вони погані в кодуванні.

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

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

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

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

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

1. Обговоріть.
2. Покажіть їм чому
3. Навіть не думай, що ти завжди правий .. Іноді навіть вони навчать тебе чомусь новому.

Ось що б я зробив, якби я був ти: D

Можливо, трохи пізніше після ефекту, але ось де узгоджений стандарт кодування - це добре.

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

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

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

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

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

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

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

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

Удачі в цьому. Я відчуваю твого болю брата.