Як переконати програмістів дотримуватися основних правил


20

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

  • Здійснення змін
  • Не записуйте проблеми з моделями в View або Controllers
  • Уникайте жорсткого кодування

Чи можете ви розповісти про свій досвід? Як вам це вдається?


2
Слід запитати на programmers.stackexchange.com. Ви робите огляди коду? Чи є у вас інструмент для перегляду коду, як Crucible? Я рекомендую зробити ретельний огляд коду та наполягати на вирішенні всіх питань, перш ніж проводити будь-яку іншу роботу.

15
Можна спробувати залишити голову коня на їх ліжку, який працював у Хрещеному батьку.
Гаурав

4
Я мав великий успіх з високою напругою. Ваш пробіг може відрізнятися.
Tim Post

2
@Tim: згорнута газета більш екологічна
Стівен А. Лоу

@Steven, я думаю, це було б. Спочатку ви повторно призначите газету, а потім повторно її циркулюєте. Я гадаю, що існує мистецтво зеленого залякування.
Tim Post

Відповіді:


6

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

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


1
+1 для вказівки на це питання культури і має вирішуватися з мотиваційної точки зору.
Алекс Фейнман

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

@ robertbristow-johnson - Гарний момент.
JeffO

14

Щоб мати змогу дотримуватися основних правил, вони повинні знати, що таке правила, і з ними потрібно погодитися.

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

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

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

Ці вказівки слід постійно змінювати, коли команда вважає, що є щось, що слід додати чи уточнити.


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

12

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

Це не буде чарівним перемикачем, який можна включити; це буде повільним процесом і ніколи не буде 100%. Такий мій досвід все одно.


1
Погодьтеся. Це політичне питання, а не технічне.

І будь-які стандарти коду повинні бути узгоджені хоча б частково групою. Такі засоби, як StyleCop, дуже допомагають.
Робота

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

@ 0101 Дуже правда. Потужність допомагає підштовхнути повідомлення. Повідомлення має бути створене таким чином, щоб воно було прийняте та дотримано.
RationalGeek

7

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

Ось кілька моїх тактик:

Здійснення змін:

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

Більшість розробників, яких я знаю, більш ніж раді перевірити код ЯКЩО:

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

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

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

Дотримання архітектури - не запитання проблем з моделями в представленнях та контролерах

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

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

Уникайте жорсткого кодування

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

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

В загальному

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

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

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


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

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

6

Перегляд коду. Приймайте лише добре написаний код, який не має помилок.


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

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

Домовились, люди просто повинні нести відповідальність і робити свою роботу, не кажучи про це. Перегляд коду після кожної зміни - це велика трата часу.
jmort253

5

Принаймні :

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

Крім того, вибирайте, що працює на основі вашої організації, розробників та вашої ролі в команді.

  • Нехай вони роблять виправлення помилок та регулярно змінюють запит
  • Пара програми з досвідченим розробником
  • Огляди коду конструктивно
  • Кодова інструкція
  • Почніть навчання, використовуйте книги, такі як Code Complete та Прагматичний програміст.

5

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

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

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


3
Якщо ваші активи настільки варті, можливо, ці питання не такі важливі? Ви повинні вибирати свої бої кілька разів.
JeffO

Моє запитання полягає в тому, щоб поліпшити те, що у мене є, це складніше, але ефективніше, ніж пошук і заміна
Llistes Sugra

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

@HLGEM - Якщо людина, яка не дотримується правил, просто ніндзя з кодом, яка може вирішити будь-яку проблему в організації. Доктор Хаус не дотримується правил, але якби лікарня звільнила його, було б багато вигаданих людей, які б померли. en.wikipedia.org/wiki/Gregory_House
jmort253

4

Існує 3 способи вирішення цього питання:

  1. Статичний аналіз вихідного коду для перевірки проблем із умовами кодування. Використовуйте такі інструменти, як cppcheck та інструменти від grammatech . У Вікіпедії є хороший список: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis . Зазвичай у більшості систем управління джерелами є гачки, за допомогою яких ви можете перевірити подібні проблеми безпосередньо під час реєстрації. Що стосується гачків CVS, перегляньте це посилання: http://goo.gl/F1gd2 . Недотримання правил означає невдалий заїзд, і більше 3 відмов означають, що розробник повинен пояснити себе команді.

  2. Під час самого процесу кодування прапор видає розробнику. Налаштування спеціальних сценаріїв, інтегрованих з обраним вами IDE, - це класний спосіб зробити це. Перевірте це посилання: http://goo.gl/MM6c4

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


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

Технічні рішення не допоможуть, якщо розробники не зобов’язані ними користуватися.
Роберт Харві

2

Ось мій тришаговий план:

  1. Запустіть програмістів
  2. Найміть деяких інженерів програмного забезпечення
  3. ...
  4. Прибуток!

: D

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


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

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

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

Зрештою, люди лише вчаться на помилках. НІКОЛИ не виправляйте проблеми, засновані на чужій впертості. Якщо це дійсно життєво важливо для проекту (тобто ваша компанія буде подана до суду, якщо ви не доставите її протягом N днів), тоді спочатку відкладіть їх від проекту.


Мені це подобається. Чудовий рецепт того, як змусити когось ненавидіти вас. ;)
Роман Зенька

@Roman Zenka: Можливо, так. Але якщо вибір полягає в тому, щоб ненавидіти і розчаруватися, тому що у вас є команда NNPP, я віддаю перевагу перший варіант;)
back2dos

У цей момент їх потрібно зняти із фонду оплати праці.
JeffO

Я фактично працював над цим! І вони мене не ненавиджу. Висновок - кожен зручний у своєму лайні. І це ускладнює це завдання.
Ллістес Сугра

1

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


1

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

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


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

@ jmort253, Якщо у мене є можливість, я б звільнив кожного програміста, який не зобов’язується регулярно контролювати версії. Зі слів автора, я розумію, що ВСІ програмісти дуже недосвідчені, і не хочуть вчитися та вдосконалюватись.
Костянтин Петрухнов

1

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


0

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

Або звільнити найгіршого злочинця, а решта нехай його потіють.


Eeep! У вас є єдиний тип оплати ДКС? Походи з століттям, чоловіче!
Девід Торнлі

0

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


0

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

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


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


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

0

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

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

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

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

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