Які бар'єри на шляху прийняття передової практики? Як їх можна подолати? [зачинено]

Ми всі бачили (і більшість з нас написали) безліч погано написаних кодів. Чому? Що змушує нас застосовувати погані практики, а не добрі?

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

Опір змінам.

Це головний рушій невігластва, поганого управління тощо.

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

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

Нікколо Макіавеллі: Принц (1513)

ДеМарко та Лістер продовжують заявляти про мантру, щоб мати на увазі, перш ніж попросити людей змінитись:

Фундаментальна відповідь на зміни не логічна, а емоційна.

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

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

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

Для довідки, описані вище фази спочатку були визначені в моделі змін Сатіра (названої на честь Вірджинії Сатір ).

Петер Тьорк має рацію, але залишив важливий і оптимістичний момент:

• людям можуть подобатися зміни, в яких вони беруть участь, але вони майже ніколи не люблять змін, які просто з ними «трапляються»

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

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

Час, здається, великий, де я працюю.

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

(Це, очевидно, не закінчується)

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

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

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

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

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

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

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

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

Дві причини

• Невігластво.

• Зарозумілість.

Як їх можна подолати?

• Стимули.

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

Найкраща практика для мене - це програмне забезпечення, яке написала команда з 8 осіб. У нас не було письмових вимог, оглядів коду, тестування одиниць, документів щодо випуску формату. Ні тестування кінцевим користувачем, ні те, що всі книги говорять, що ми повинні були робити. Код був поспішним, баггі та просто неможливо підтримувати. Його відкинули через 3 роки після звільнення, це було так погано. Отже, що було в цьому так чудово. Через два роки після першого звільнення власник компанії (який фінансував розробку за допомогою іпотечного кредиту на власному будинку) пішов з 30 - 40 мільйонів доларів у задню кишеню.

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

Більшість практик "Кращої практики" не приносять прибутку. Ті, що роблять, повинні і є, широко прийняті. Ось чому «найкраща практика» не практикується.

Прийнятний ризик

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

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

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

IME - це поєднання сказаного іншими. Незнання ("Я тільки коли-небудь використовував DataSets, чому б це турбуватись з цими матеріалами LINQ?", Відсутність часу ("Шеф хоче, щоб це було зроблено якомога швидше, ми не можемо витратити на це багато часу"), відсутність розуміння ("Що не так з написанням всього мого коду в коді позаду?") все це сприяє.

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

Часто розробникам просто не виявляли кращої практики чи, що ще важливіше, переваги використання кращої практики (я починаю припиняти використання терміна "Найкращі практики" з різних причин).

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

Після того, як ви швидко покажете їм переваги кращої практики (наприклад, TDD або, скажімо, дотримання принципів SOLID), і що це фактично дозволяє їм бути кращим (але все ще «ледачим») розробником, ви схильні виявити, що опір тане. геть.

Це питання освіти :)

(Відсутність) знань та навичок + час інвестувати

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

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

Чорт, як я навіть пишу одиничний тест у XCode? Це щось інше, що мені потрібно витратити час на навчання.

@Zues та @Joshua Smith

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

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

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

Дві частини в більшості мого досвіду:

• час
• отримання достатньої кількості людей, щоб погодитись, які практики найкращі для поточної ситуації

"Кращі практики" ДУЖЕ суб'єктивні у багатьох ситуаціях реального світу. Якщо одна половина команди намагається зробити купу SOLID & TDD, тоді як інша половина працює 60 годин тижнів, щоб голити секунди від тривалості роботи тут і там будь-якими необхідними засобами, тому що ви пройшли повну точку, де вже пізно перепроектуйте щось, що не працює вчасно для наступного випуску, ви не збираєтеся далеко виходити.

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

Іноді ви виявите, що звичка також є головним фактором написання жахливого коду.

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

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

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

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

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