Когато бях начинаещ кодер, разбрах от наблюдението на по-опитни хора, че едно от най-важните умения, които един разработчик може да притежава, е способността за бързо решаване на проблеми. Но когато ги попитах как са успели да решат такъв и такъв проблем, те обикновено изпускаха дълга въздишка, след което ми казваха: „Просто идва от опит…“

Сега съм в момент, в който наставлявам начинаещи разработчици. Задават ми същия въпрос и по ирония на съдбата се улавям, че давам същия отговор.

Сега, когато имам повече опит, разбирам много повече стойността му. Но все още вярвам, че можем да дадем на начинаещите по-добри методи за решаване на проблеми от този безполезен отговор от един ред.

През 1945 г. унгарският математик Джордж Поля се опита да предостави такъв метод чрез книга, наречена Как да го решим. Първоначално написан за студенти по математика на ниво колеж, неговият метод може да се приложи към почти всеки проблем, особено тези за кодиране. Четирите основни принципа на неговия метод са:

  1. Разберете проблема
  2. Направете план
  3. Изпълнете плана
  4. Помислете за успеха/неуспеха на плана и какво бихте могли да направите по-добре

Много по-лесно да се каже, отколкото да се направи! По-долу е даден списък на моите собствени стратегии (много вдъхновени от тази книга), които наскоро споделих с един чирак тук в 20spokes.

При отстраняване на грешки

Когато попаднете на неприятен бъг, запитайте се (преди да потърсите проблема в Google)...

  1. Наистина ли идентифицирах проблема? Мога ли ясно да заявя този проблем на колега?
  2. Разделил ли съм проблема на най-малките му части? Мога ли да реша някоя от тези части поотделно?
  3. Изброих ли всички възможности за това какъв може да е основният проблем? Опитайте се да изолирате тези възможности. Ако е необходимо, създайте някакъв код за изхвърляне, за да изолирате сценарий.
  4. Необходими ли са неизвестни, за да се реши този проблем? Елиминирайте възможно най-много неизвестни.
  5. Проверих ли въведеното? Каква е моята очаквана продукция?
  6. Проверих ли потока си през приложението? Постигам ли всички функции/точки на приложението, които очаквам да постигна? Използвайте инструменти като Pry за Ruby или Debugger за Javascript, или просто добрия старомоден console.log.
  7. Търсил ли съм на правилните места за потенциални улики, като конзолата на браузъра, сървърни регистрационни файлове или мрежови регистрационни файлове?

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

Относно общата стратегия

Когато изграждат решения, разработчиците постоянно се сблъскват със сценарии, които нямат нито един правилен отговор. Тези въпроси могат да бъдат толкова малки, колкото „как да нарека тази функция?“ или голямо като „Как да моделирам тази база данни?“

В тези случаи е въпрос на претегляне на възможностите ни. Това може да бъде плашеща перспектива за начинаещи и често срещан първи импулс е да попитате по-опитен разработчик какво биха направили.

Докато да питате хората за мнението им като цяло е добро нещо, ще спечелите уважение много по-бързо като разработчик, ако вече сте обмислили потенциални решения преди да попитате някой друг. Разговорите ви ще бъдат по-малко едностранчиви и другият човек няма да чувства, че е използван да решава вместо вас. Ето моите общи насоки за определяне дали даден избор е „правилният“:

  1. Как това решение може да се промени с времето?
  2. Това решение СУХО ли е (не се повтаряйте)? Ще поставя ли подобна функционалност на няколко места? Искам да избягвам това, доколкото е възможно.
  3. Това решение има ли единствен източник на истина? Например, ще търся ли едни и същи данни на различни места?
  4. Поддържа ли се това решение от други разработчици? Как нов разработчик на този проект би интерпретирал този код? Ще разберат ли името на тази функция?
  5. Проучвал ли съм въпроса онлайн, за да видя как други хора подхождат към подобни проблеми? (Разбира се, не искате да приемате нито един стар отговор, който виждате онлайн. Приложете същия метод към тези намерени решения.)
  6. Проверил ли съм документация(и), за да проверя дали определени решения са възможни/невъзможни? („Проверил ли съм документите“?)

Опитът позволява на разработчика по-бързо да си представи възможните опции, да види какво ще бъде трудно или лесно за постигане. Опитните разработчици са „научили по трудния начин“. Но е наистина рядко да се намери опитен разработчик, който да не се придържа към някакъв метод за решаване на проблеми или архитектурни решения. Просто става по-интуитивно за тях и по този начин по-трудно да се изрази с думи.

Големият ми съвет към начинаещите е да се доверят на методите и да вярват, че следвайки тези методи, опитът ще дойде с времето.