Хороші інстинкти кодувальника в кінцевому підсумку «вдарять вас по зубах»

image

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

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

Але інтуїції недостатньо. Я зіткнувся зі стіною. І ніякої інстинкт кодувальника не допомагав мені крізь неї пробитися. Далі Bill Sourour поділиться з нами інформацією про те, як не зупинятися на досягнутому. Кому-то ці міркування, безумовно, здадуться очевидними. Ну, а комусь знадобляться.


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

image

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

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

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

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

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

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

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

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

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

Прочитайте чортову інструкцію!
Прочитайте інструкцію, в кінці кінців! Підхід RTFM полягає не тільки в цьому, але навіть діти вміють читати.

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

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

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

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

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

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

Розберіть і збирати заново
Прибирайте компоненти покроково до того моменту, поки все не почне працювати, а потім зберіть все заново, і ви знайдете неробочу частину.

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

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

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

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

Тут вам допоможе Розробка Через Тестування (TDD). Якщо ви використовуєте TDD, тоді ви повинні мати у своєму розпорядженні кілька фіктивних об'єктів (Mock-об'єктів).
Фіктивні об'єкти симулюють контрольоване поведінку реальних об'єктів. Програміст, як правило, створює макет об'єкта для перевірки поведінки якогось іншого об'єкта. Це багато в чому подібно до того, що робить автомобільний дизайнер використовуючи краш-тест манекена для моделювання динамічної поведінки людини під час автомобільного події. — Вікіпедія
Підказка: якщо в ході експериментів з об'єктом помилка зникла, значить, швидше за все, проблема саме в цьому об'єкті.
Використовуйте «Saff Squeeze»
Існує техніка, яка називається «Saff Squeeze » («лещата Саффа»), її автор і творець Кент Бек. І це щось середнє між попередніми двома варіантами.

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

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

Примітка: Джим Батлер надав нам цю посилання для кращого розуміння техніки «Saff Squeeze».

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

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

А що ж з інстинктами?
Тепер, коли ви вивчили ці техніки, це означає, що ви повинні користуватися ними, а не довіряти власним інстинктам? Ні, зовсім не так.

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

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

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

P. S. Рекомендуємо ще одну корисну статтю по темі роботи над собою — Подолання трудових марафонів: 3-кроковий метод підвищення продуктивності, що дозволяє уникнути роботи по ночах.

Автор перекладу — Давиденко В'ячеслав, засновник компанії TESTutor.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.