Як подолати програмування за збігом обставин? [зачинено]

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

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

Початкові зонди солдата для мін нічого не виявили, але це було просто щастило. Його привели до помилкового висновку - з катастрофічними результатами.

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

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

Редагувати:

резюме з ваших публікацій:

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

До речі, відповідь важко прийняти, це дуже важко. Усі відповіді справді чудові :)

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

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

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

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

Скоротіть цикл редагування / компілювання / тестування. Якщо ви додасте великий фрагмент коду і погано тестуєте, шанси на те, що він буде вести себе інакше, ніж ви думаєте. Тоді ви "фіксуєте" це якоюсь випадковою зміною, і ви отримали правильну відповідь на даний момент, але не маєте поняття, як це насправді сталося. Ви зараз програмуєте за збігом обставин. Але коли ви додасте 5 рядків і потім тестуєте, шанси на те, що ви отримали правильну відповідь, бо це працює так, як ви думаєте, що це працює набагато краще. Я можу сказати з досвіду, що 5 шматочків по 10 рядків кожен, індивідуально перевірений, - це зовсім інший звір, ніж 50 рядків коду, перевірених всі разом.

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

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

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

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

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

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

Не торкайся цього. Це працює. Ми не знаємо, як і чому, але це працює. ¹

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

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

¹ Щодо контексту, цей коментар з'явився в коді, який обробляє комутатори контексту в примітивній ОС. Код вже був у виробництві кілька років, коли я стикався з ним.

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

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

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

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

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

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

Занадто просто кодувати, тестувати та виправляти "на гоночній лінії". У вас є функціонал, який дає X & Y, створює Z. Але що робити, якщо X пошкоджений, а Y недоступний? Що робити, якщо ви не можете вивести Z? Постійно майте на увазі, що може піти не так, і запишіть це на цикл тестів.

Будьте рутини короткими та описовими - найкращий код вимагає декількох (якщо такі є) коментарів.

Змістовний метод, назви класів та змінних проходять довгий шлях до сприяння читанню.

Якщо ви натрапили на кодовий запах, тоді СТОПУЙТЕ. Цей запах навряд чи піде, і трохи зусиль тепер може врятувати вам величезну кількість горя.

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

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