Надихаєш колегу застосовувати кращі практики кодування?

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

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

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

Однак фактичний (C #) код, який я бачив, є поверненням до VB6 днів. Процедурна структура, угорська нотація, глобальні змінні (зловживання static), відсутність інтерфейсів, тестів, незастосування Generics, метання System.Exception... Ви розумієте.

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

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

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

Чи були раніше подібні ситуації інші люди, особливо провідні розробники? Які стратегії були успішними для стимулювання інтересу та створення позитивної динаміки групи? Які стратегії не були успішними, і краще було б їх уникати?

Роз'яснення:

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

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

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

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

• Згадка про "... глобальні змінні ... ніяких тестів ... метання System.Exception" мала на меті продемонструвати, що проблеми не просто поверхневі чи естетичні . Практики, які можуть працювати для відносно невеликих додатків CRUD, не обов'язково працюють для великих корпоративних програм, і насправді жоден з кодів до цього часу фактично не пройшов інтеграційні тести.

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

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

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

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

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

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

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

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

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

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

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

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

Це справді робота вашого менеджера

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

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

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

Для ознайомлення ознайомтеся з тим, як написані стандарти MISRA-C / C ++ та CERT C / C ++ / Java.

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

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

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

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

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

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

Зауважте, що дуже важливо, щоб це стало успіхом, і це швидко.

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

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

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

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

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

1. Опишіть поведінку, яку ви бачите. Це має бути конкретна поведінка. Приклад: "Я бачу, що ви використовуєте багато статичних змінних у своєму коді"
2. Опишіть, як це впливає на вас / вашу команду. Приклад: "Мені такий код важко підтримувати"
3. Запропонуйте розумне рішення. (можливі рішення згадуються в інших відповідях. Я пізніше буду справлятися з деякими проблемами згодом.)
4. Дайте йому можливість обговорити рішення. Запитайте його, що він думає про рішення. Візьміть його відповідь за номіналом. Ви висловили йому свою думку, і він вільний її прийняти чи ні. *

Швидкий ресурс зворотного зв’язку можна знайти, наприклад, на веб- сайті http://managementhelp.org/communicationsskills/feedback.htm (хоча в Інтернеті є плеторія подібних матеріалів)

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

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

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

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

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

Питання в розмірі 64 000 доларів полягає в тому, чи він вчасно доставляє свої проекти та відповідає вимогам функціоналу. Якщо так, він робить це правильно. Не існує об'єктивного правильного чи неправильного в розробці програмного забезпечення. Зрештою, це стосується вирішення проблем. І якщо проблеми вирішуються на задоволення клієнта / замовника, то за визначенням розробка програмного забезпечення проводиться правильно.

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

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

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

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

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

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

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

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

Ви не можете.

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

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