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

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

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

Код, мабуть, неправильний.

Однак це може не мати значення.

Швидкий і брудний може бути правильним шляхом у ситуаціях, коли:

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

Іноді не важливо, щоб код був надійним і обробляв усі можливі дані. Іноді просто потрібно обробляти відомі вами дані.

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

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

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

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

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

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

Я багато разів боровся з колегами з цього приводу. ЗАВЖДИ є ще одна настройка, щось інше, що "слід" зробити, щоб воно було "правильним". Ви завжди можете це знайти. У якийсь момент у реальному світі достатньо хорошого просто має бути достатньо хорошим. Жодне реальне, фактичне, програмне забезпечення для доставки не є ідеальним. Немає. У кращому випадку це досить добре.

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

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

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

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

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

Одиничні тести . Це єдиний спосіб впевненості в будь-якому коді (брудному чи ні).

На бічній записці;

короткі скорочення створюють тривалі затримки (Піппін)

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

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

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

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

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

Ось історія про швидкого і брудного програміста, якого я знаю.

Я знав людину, яка вважає, що одиничні випробування втрачають час. Після довгих аргументів він нарешті написав один. Він складався з одного довгого методу, посипаного && та || і повернув булеве ствердженняTrue. Запис охоплює 20 рядків. Потім знову він написав клас, де кожен метод мав один рядок, а основний - понад 1000 рядків без пробілів. Це була стіна тексту. Коли я переглянув його код і вставив нові рядки, він запитав "чому". Я сказав: «Через читабельність». Він зітхнув і видалив їх. Він помістив коментар вгорі "Не чіпай, це працює!"

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

Крім того, він вважає, що читати програми та блоги програмування марно. Він каже: "просто починай програмування". Він робив це протягом 12 років, і він вважає відмінним програмістом. / facepalm

Ось ще кілька.

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

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

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

Один розробник дав усвідомлюючу відповідь, коли я попросив його використовувати код бібліотеки: "Це не обман? Мені довелося написати весь власний код у школі".

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

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

Продукт поставляється.

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

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

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

Я особисто не ставив за мету розвивати навичку "писати брудний код" і бути впевненим у його правильності. Я б швидше писав правильний код перший раз.

Звідки вони знають, що вони зрозуміли правильно? Тестування - це проста відповідь.

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

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

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

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

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

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

На мою думку, навчитися оцінювати Q&D-код для коректності - це не навичка, яку варто розвивати, оскільки це лише погана практика. Ось чому:

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

З погляду оригінального звіту CHAOS чітко видно, що питання Q&D не є хорошою ідеєю і згодом вб'є бюджет (або на технічне обслуговування, або під час розширення). Навчитися оцінювати правильність коду питань та питань - це марна трата часу. Як сказав Пітер Друкер, "немає нічого такого марного, як робити ефективно те, чого не слід робити взагалі".

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

"Брудні" означають різні речі для різних людей. Для мене це здебільшого означає покладатися на речі, на які ви знаєте, що, напевно, не слід покладатися, але які ви також знаєте, що можете розраховувати працювати найближчим часом. Приклади: припускаючи, що кнопка має висоту 20 пікселів замість обчислення висоти; жорстке кодування IP-адреси замість вирішення імені; розраховуючи на сортування масиву, оскільки ви знаєте, що він є, хоча метод, який забезпечує масив, не гарантує його.

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

Загрожуючи звучати трохи суперечливо, я б стверджував, що ніхто по-справжньому не знає, що їх код 100% правильний і 100% без помилок. Навіть коли ви маєте дуже гарне тестове покриття і жорстко застосовуєте хороші методи BDD / TDD, ви все одно можете розробити код, який містить помилки, і так, це може навіть містити побічні ефекти!

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

Важливим моментом є те, що добре обгрунтований і добре перевірений код дозволить ДІЯМИ мати впевненість у вашому коді, що в більшості випадків важливіше, ніж ваша впевненість.

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

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

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

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

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

2) Проект стає відомим як неоптимальне рішення, і його використання починає перешкоджати, на користь нового рішення або рефакторингу, який коштує так само дорого, як і нове рішення.

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

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

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

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