Як перетворити програміст копіювання / вставки / спагетті, щоб побачити світло?

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

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

У минулому я (та інші) запитували, як вам навчати ТОВ . Але зараз я думаю, що це не правильне питання. Справжнє питання полягає в тому, як ви підходите до такої людини / колективу і робите їх цікавими щодо кращого способу ведення справ? Як ти надихаєш їх на навчання? Без цього здається, що всі викладання, зустрічі, лекції, дискусії марні, якщо вони абсолютно щасливі повертатися до свого столу і робити те, що вони завжди робили.

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

Коли я доставляю роботу, у неї, як правило, менше помилок, і робота, якою я володів, ніколи не ставала 5000-лінійною жахливістю класу. Інші зауважували б такі коментарі, як "ваш код набагато чистіший і легший для читання, ніж наші речі", тому вони бачать різницю. Але в той же час я відчуваю, що вони вважають, що їм платять за 40 годин незалежно від того, що роблять, тому вони насправді не проти, якщо вони проводять 3 повні дні в QA, шукаючи помилку, яку не слід було б ввести в перше місце. Або що їм потрібно тиждень, щоб змінити один клас, тому що існує стільки залежностей, які вони в кінцевому підсумку торкаються. Хоча, "можливо, цей клас повинен був бути написаний інакше", схоже, ніколи не з'являється.

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

ПРИМІТКА. Коли я кажу "відсутність мотивації". Я не думаю, що це відсутність мотивації працювати чи робити гарну роботу, тому що вони просто перестали дбати. Більшість нашої команди насправді зовсім навпаки. Вони напевно дбають про продукт. У нас є хлопці, які будуть працювати ніч і вихідні. Частина, яку я намагаюся пройти, - це покращені звички та навички, їм насправді не доведеться так багато працювати. Я думаю, що "40 годин" річ зробила цю публікацію занадто негативною.

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

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

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

Що ми можемо зробити? Не надто багато. У всіх випадках обирати справді мотивованих не ви, а людські ресурси it's. І звільняйте людей, яких немає.

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

Ти можеш:

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

• Робота над вимогами, особливо нефункціональними . Як щодо вимоги, яка говорить про те, що конкретний проект повинен містити менше 5 000 рядків коду IL (ні, я не кажу про безглузді LOC ) ³? А що з необхідністю отримання конкретних результатів при цикломатичній складності або класовій зв'язку ?

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

• Використовуйте [більше] парне програмування . Це може допомогти покращити якість коду та мотивувати менш мотивованих співробітників.

• Використовуйте систему компенсацій, аналогічну тій, що використовується у Fog Creek.

^{Ось що стосується співбесіди: перед тим, як наймати вас, людські ресурси повинні мати на увазі не тільки ваш технічний рівень, але і мотивацію . На жаль, деякі компанії забувають про цю другу частину інтерв'ю і наймають людей, які не дуже сподобаються програмуванню. На щастя, у більшості випадків робота в цих компаніях ніколи не приємна, і тест Джоеля рідко перевищує 2.}

^{² Їм насправді все одно, навіть якщо вони заробляють менше грошей. Я досить близький до одного зі своїх клієнтів (я фрілансер), який вважає, що його робота полягає у розробці веб-сайтів для власних клієнтів. У нього також є дизайнер. Я багато разів розповідав їм про те, як вони можуть збільшити свою продуктивність на 2 і більше. Якби вони просто найняли когось грамотного, вони збільшили свої доходи щонайменше на 3. Але у них є достатньо грошей, і їх не хвилює якість або скільки вони коштують необізнаним клієнтам, порівняно з кимось продуктивним.}

^{³ Що я маю на увазі - це кількість рядків коду IL, яку ви бачите в « Метриках коду» у Visual Studio , метрика якої насправді щось означає. Реальний LOC не має значення , і ви не повинні виміряти; це одна з найдурніших показників коли-небудь. Забезпечення рядків коду IL означає, що розробники будуть змушені фактично рефакторний код, а не просто згортати десять рядків коду в один нечитабельний рядок.}

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

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

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

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

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

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

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

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

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

• Вони думають, що вони занадто зайняті, щоб навчитися чомусь новому, або вони думають, що новий спосіб виконання справ (наприклад, написання всіх цих тестів) займе у них більше часу, і вони не мають на це часу. Тоді очевидною відповіддю було б: приділіть їм більше часу. Вивчити щось або спробувати щось на кшталт TDD, коли ви завжди робили речі по-різному , знадобиться більше часу в перші кілька разів. Якщо у ваших програмістів цього часу немає, ви не можете звинувачувати їх у тому, що вони не намагалися.
• Вони по-різному сприймають власні навички, тобто вважають, що вони дуже хороші програмісти, які виробляють високоякісний код. Це складний психологічний напрямок, оскільки руйнування цієї віри може бути дуже демотиваційним. Можливо, якась неформальна конкуренція може допомогти (хто видає найменше дефектів / особливості? Найкоротший код? Найменший WTF / хвилина в огляді коду?).
• Може виникнути актуальна проблема з мотивацією (тобто вони просто хочуть "провести свій час і залишитись у спокої" до закінчення часу). На щастя, це занадто загально / не пов'язано з програмуванням, тому що я справді не маю на це відповіді.
• Вони початківці, і вони не знають краще. У цьому випадку можуть допомогти навчання, перегляд коду чи "книжковий клуб", де член команди повинен щомісяця обговорювати нову технічну книгу.
• Раніше вони бачили срібні кулі (і були гірко розчаровані), і думають, що те, що ти намагаєшся продати, - це ще одна нова модна фраза, яка теоретично звучить добре і мало корисна на практиці. У цьому випадку демонстрація переваг під час огляду коду та сеансів програмування пар може працювати. Намагайтеся не бути тотальним ноу-хау, коли ви це робите.

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

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

Це воно! Це справді справжнє питання.

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

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

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

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

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

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

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

PS: Просто випадково я опублікував відповідь тут https://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034 - і я отримав усе баламученість; насамперед більшість людей вважають, що якимсь чином бізнес не може дозволити собі витрачати ресурси! Я впевнений, що ця відповідь може отримати подібне лікування тут. Але правда полягає в тому, що змусити людей працювати і змусити їх повірити у те, що вони роблять хорошу роботу, є предметом психології людини над тим, як опрацювати програму курсу.

У будь-якому випадку завдання, яке ви описуєте тут, означає запалення внутрішньої пристрасті до великих змін. І чим більше система тим складніше стає. Почніть з молодших товаришів, які все ще вбудовані з духом i-not-to-do-good-job та киньте виклик статусу кво.

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

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

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

Я думаю, що до цього є дві частини - освіта та практика роботи.

• Навчання ви можете розпочати один обід на тиждень - всі їдять разом, ви проводите 20–30 хвилинну презентацію із Q&A. Ви починаєте з бажаних основ - SOLID може зайняти перші 2–4 тижні - з часом ви змусите команду говорити в ротації, і ви зможете вирішити, як вирішити, хто говорить про те, що між вами. Дозвольте динамікам деякий час підготовки протягом роботи. Крім цього, заохочуйте відвідувати місцеві групи користувачів (якщо це можливо, принаймні частково соціальне)
• Практика роботи ... ну це залежить від того, чим ви зараз займаєтесь та якими інструментами володієте, але ви можете поглянути на узгодження стандартів кодування, запровадивши огляд кодового коду (чи це твердо), одиничне тестування (не обов’язково попереднє тестування) , запуск сервера безперервної інтеграції та перегляд більш автоматизованого тестування (крім одиничних тестів). Але їх потрібно суттєво ввести за згодою / згодою (а не на сервер build / CI!), І ви повинні хотіти, щоб як команда рухалася вперед. Завжди є речі, які можна вдосконалити (Kaizen)

Також варто поглянути на Kanban (який розглядається як драйвер змін / удосконалення).

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

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

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