Коннер Глисон
С тех пор, как я начал программировать, я снова и снова сталкивался с простой идеей; и как бы я ни старался, мне может быть трудно получить доступ к уроку в нем. В конечном счете кодирование — это систематический и логический процесс, но при попытке создать виртуализированную версию концепции приложения в вашей голове объяснение трудностей этого процесса может быть каким угодно, но только не систематическим. Между вашими глазами как программиста, который превышает ваши текущие способности, концептуальное непонимание наборов инструментов, приемлемое форматирование элементов, когда кажется, что они просто не хотят хорошо играть, и даже простые опечатки, вызывающие более крупные и даже каскадные проблемы… ОГРОМНОЕ, что нужно обдумать, прежде чем увидеть ваш минимально жизнеспособный продукт в действии.
Что подводит меня к главному пункту этой статьи; мы все знаем, что эти проблемы будут возникать снова и снова, но как мы на самом деле готовы к циклическому характеру этих проблем по мере того, как мы развиваемся в наших навыках кодирования? Чтобы было ясно, процесс обнаружения и решения проблем всегда можно сделать так, чтобы он чувствовал себя полезным, особенно в области, где есть ощутимая и немедленная обратная связь от системы, которая позволяет создателю увидеть функциональную версию веб-сайта или приложения. каждое добавление рабочей функции. Но непосредственность этой обратной связи также сопряжена с недостатком мгновенного знания о неудачах кодировщика в удовлетворении его или ее собственных ожиданий.
Когда я теряю закрывающую скобку элемента или, как я недавно сделал, теряю символ при единичной инициализации функции, которая использовалась бесчисленное количество раз в моем приложении, система часто либо мгновенно отклоняет значительную часть моей работы, либо пытается придерживайтесь моей ошибочной логики, что иногда приводит к смехотворно непредвиденным последствиям. Это не новое знание для тех, кто часто программирует, но что постоянно застает меня врасплох, так это то, что это может сделать с вами психологически; столкнуться с простой ошибкой, которую вы видели тысячи раз, но в самый неуловимый момент в процессе создания, когда вы готовы увидеть результаты своей энергии и трудоемкой работы. Вероятно, поэтому так много программистов склонны в шутку предполагать, что их работа не сработает при первой инициализации, а затем беспокоиться о ее исправлении. Бесполезное беспокойство или раздражение действительно могут вызвать проблемы в процессе творчества. Я помню, как был парализован страхом и раздражением на раннем проекте из-за мысли о том, что многие часы тщательно спланированной работы над проектом (и последовательные хитроумные обходные пути) над проектом нужно было переписать, поскольку они вызывали дополнительные проблемы с другими запланированными функциями, которые я и мои партнер должен был еще обратиться.
Мы собирали данные о персонажах из Star Wars API, чтобы создать простенькую страницу в социальных сетях, чтобы поклонники сериала могли комментировать, сравнивать и делиться своими любимыми персонажами в сообществе Star Wars. Единственная проблема заключается в том, что эти данные, которые мы собирали, сначала оптимистично отображались в DOM, а затем отправлялись в базу данных, которую мы использовали для сохранения новых и популярных персонажей, и поскольку данные поступали без связанного идентификатора, с использованием идентификатора для обновления существующие и популярные персонажи динамически в нашем приложении становились все труднее. Понимая, что проблема именно в этом, но не зная, как решить ее с помощью нашей текущей системы, вместо того, чтобы предпринять очевидные шаги по реструктуризации способа прохождения данных через наше приложение с нуля, я убедил себя, что единственный способ доказать свою правоту собственное умение заключалось в том, чтобы моя работа что-то значила. Продолжать надстраиваться над ним, складывая дополнительные и ситуативно используемые HTTP-запросы, чтобы попытаться сгладить проблемы, которые я создал на этапе концептуализации работы приложения. И по мере того, как длина моих кодов росла, я все дальше и дальше отдалялся от воспоминаний о том, зачем вообще предпринимал эти шаги. Я не упрощал свою задачу в творческом ключе, я искал волну волнения и эмоционального вознаграждения, которые приходят с тем, что мне не нужно отступать, чтобы решить те самые проблемы, которые я создал.
Если бы я замедлился, потенциально не был бы так очарован своей собственной работой и идеей использования кода для решения проблем моего собственного кода, я бы увидел, что происходит, за милю. Что погоня за собственным хвостом может привести к тому, что вы поймаете его зубами. Я с гордостью продемонстрировал свою новую систему создания 5 различных экземпляров HTTP-запросов и нескольких функций для каждого типа данных одного типа и направления всей информации, предоставляемой нашему приложению, по этим различным путям в зависимости от различных условий моему хорошему другу, объяснив, что хотя все 5 этих запросов казались чрезвычайно избыточными, они на самом деле облегчили мне жизнь, поскольку информация контролировалась уникальным образом между каждым экземпляром. Единственным примером этого был умный обходной путь, когда я создал автоматизированный процесс для сохранения символов, которые ищет пользователь, в нашу базу данных, чтобы автоматически присвоить им идентификатор, а затем отображать данные этих символов на странице ИЗ базы данных. , прежде чем удалить персонажа из базы данных, чтобы предотвратить непреднамеренное сохранение персонажа до того, как пользователь сохранил его в базе данных…
Я думаю, вы можете начать видеть проблему здесь. Пока я разглагольствовал о своей гениальной стратегии продолжать украшать существующий код, мой друг задал очень простой вопрос: «Почему у вас есть 5 разных процессов рендеринга для одного типа данных?»
Вопрос хороший, и я был удручен тем, что вся проделанная мною работа просто затмевается простой идеей. Естественно, начала просачиваться моя неудовлетворенность собственным процессом и работой, и не только потому, что я чрезмерно усложнил простой процесс, но и потому, что на самом деле упрощение кода потребовало от меня вернуться и стереть часы моего собственного времени, потраченные на усугубление существующей проблемы. Когда все было сказано и сделано, я преобразовал все функции HTTP-запросов в единый процесс, который работал уникальным образом с каждым набором данных в зависимости от того, как и где я хотел его использовать, но за это время я сделал больше основных ошибок, чем раньше. в течение нескольких недель из-за стресса и разочарования от необходимости переделывать существующую работу, даже если эта работа, которую я переписывал, не делала того, что мне было нужно. Есть что-то ироничное в том, чтобы защищать код, который не выполняет свою работу по назначению, но еще более иронично то, что я не почувствовал бы этого эмоционального перекоса, если бы вернулся к своей работе, впервые осознав ее неэффективность. Я вырыл себе эмоциональную могилу, посвятив себя процессу расширения своего кода вместо того, чтобы писать хороший код, что привело к большему количеству ошибок и большему количеству времени, потраченному в целом на разочарование из-за моей собственной неспособности контролировать эти ошибки.
Этот опыт научил меня многому в том, что кодеры должны иметь отношения со своим собственным кодом, и как владеть процессом создания, а не позволять ему контролировать их. Пытаясь избежать повторения этого опыта, я наткнулся на терминологию, разъясняющую опасности, связанные с моей работой. В программировании существует понятие «задолженность по коду», которое идет рука об руку с тем, что я чувствовал во время этого процесса: непрерывное расширение неисправного или устаревшего кода с течением времени только когда-либо увеличивает работу программиста над проектом из-за увеличения «долга». ' к процессу. Разочарование просто неизбежно, когда человек удваивает ставку на плохо спланированные первоначальные инвестиции только для того, чтобы чувствовать себя эмоционально нищим и нищенским из-за каждой простой ошибки, возникающей в результате попытки искоренить этот долг.
Решение этого чувства состоит не в том, чтобы быть приверженным не своей собственной кодовой базе, а в том, чтобы стать приверженным своему процессу в достижении ваших целей. Некоторые инструменты, которые я обнаружил, которые могут помочь программисту инвестировать в свой процесс, а не в свой код, следующие:
- Блокирование времени для работы над идеями решения проблем. Чрезмерная приверженность решению проблемы с помощью собственных теорий и стратегий кодирования должна быть как минимум. Это можно смягчить, выбрав жесткие временные рамки для решения проблем с помощью собственных стратегий. Более чем вероятно, что если вы значительно превысите ожидаемое время, которое, по вашему мнению, может потребоваться для решения проблемы с помощью дополнительного кода, то вы чрезмерно усложняете фундаментальную проблему с вашей исходной идеей или базовым кодом. Предоставление себе реалистичных временных рамок для работы над любой отдельной проблемой поможет вам прийти к соприкосновению с реалистичными ожиданиями, которые вы можете возлагать на свое приложение, и сможете ли вы удовлетворить их в реалистичные сроки без корректировки базовой функциональности приложения.
- Не слишком привязывайтесь к своему коду. Иногда бывает трудно признать, что ваша тяжелая работа была не напрасной, когда вы возвращаетесь к своей работе. Когда мы так много посвящаем себя идее и заставляем эту идею работать, это может ощущаться как возвышающий опыт, а отказ от этой работы кажется предательством этой тяжелой работы. Однако на самом деле мы постоянно учимся на своих ошибках, и принятие этого факта позволит нам перенести уроки, извлеченные из удаленного кода, обратно в наш процесс, когда мы будем работать над его улучшением. Естественно расстраиваться из-за того, что использованная нами стратегия не сработала или могла быть написана лучше, однако это не должно нас расстраивать, поскольку каждый раз, когда мы рекурсивно изменяем нашу работу, мы все теснее соприкасаемся с идеей, почему приложение должно работать именно так, а не иначе. способ. Наши отношения с нашим конечным продуктом в конечном итоге будут очень ценными, учитывая, что мы предприняли важные шаги, чтобы коренным образом изменить его, чтобы сделать его в наилучшей форме, в которой мы могли бы его сделать, а не в лучшей форме, в которой он мог бы быть за одну попытку. при его изготовлении.
- Не будьте строги к себе. Эта поговорка о признанных кодерах, ожидающих, что вновь созданные приложения потерпят неудачу, может работать в нашу пользу. Вместо того, чтобы сбиваться с толку из-за того, что мы не достигли успеха немедленно, мы можем использовать каждый раз, когда мы впервые инициализируем приложение или функцию, как момент поздравления для себя. В конце концов, мы инициализировали его только потому, что думали, что он либо находится в достаточно хорошем состоянии, чтобы попытаться запустить его, либо что он достаточно хорош, чтобы увидеть, что произойдет в результате его запуска. Получение кода на странице в первый раз — такой же важный шаг, как и достижение любой другой цели рабочего проекта, и пренебрежение работой из-за того, что она не достигла желаемого результата сразу, означает, что мы лишаем себя возможности оценить процесс. перевод идеи в код, который в конечном итоге превращается в полезное приложение или инструмент. Ожидайте увидеть много ошибок и наслаждайтесь каждой из них как отдельными пробными версиями, которые в совокупности дополняют истинное величие ваших приложений.
- Используйте тщательное изучение своего кода в качестве медитации. Глядя на блок кода и ожидая, что потенциальные проблемы просто всплывут на нас, требуется много времени. Чем больше времени тратится на этот процесс, тем больше смущения и разочарования мы можем чувствовать, когда раскрываем эту простую проблему. Вместо того, чтобы доводить проверку кода до раздражения, мы можем попытаться внимательно прочитать наш существующий код в отношении любого нового кода, которым манипулирует или использует этот ранее существовавший код. То, что мы можем найти, может быть очень успокаивающими, логичными и разборчивыми концепциями, которые прекрасно играют таким образом, что позволяют нам читать функциональность наших приложений как запутанную историю цели. Каждая часть истории нашего приложения должна быть размещена соответствующим образом, чтобы вся история стала доступной для читателя, которым, как раз, и являемся мы. Когда некоторые элементы этой истории, кажется, не складываются, или мы, как читатели, не можем определить цель или форму какой-либо отдельной части этой истории, стоит подумать, используется ли этот фрагмент кода с максимальным потенциалом. Таким образом, мы можем обнаружить вещи, которые нам не обязательно нравятся в нашей собственной работе, но вместо того, чтобы заставлять нас исправлять их самым быстрым и управляемым способом, мы можем вместо этого рассмотреть, что на самом деле должно быть в приложении в его наилучшей форме. Проверка кода существует не только для того, чтобы заставить нас работать несколько раз, она существует, потому что наши приложения должны работать как единые чистые объекты, состоящие из сложных глав, очень похожих на книги. Рассмотрение процесса проверки кода в этом свете может дать нам необходимую мотивацию для того, чтобы сделать каждую главу отдельной и целенаправленной частью функциональности приложения и рассматривать строительные блоки приложения как отдельные проблемы, которые решаются индивидуально.
Я надеюсь, что уделив это время размышлениям о том, как «наклон» может действительно повлиять не только на ваше удовольствие от процесса кодирования, но и на вашу итоговую работу, вы помогли разобраться с мелочами решения проблем в кодировании. Я знаю, что над этими идеями я по-прежнему работаю каждый день, чтобы стать лучшим, на что я способен, а также получить столько же от опыта кодирования, сколько я вложил, независимо от обстоятельств. В следующий раз, когда вы столкнетесь с проблемой, которая, кажется, подталкивает вас к краю вашей зоны комфорта, уделите секунду и спросите себя, может ли это быть просто побочным эффектом вашего желания сделать вашу работу значимой, а затем поймите, что, оставаясь спокойный и счастливый перед лицом разочарования и никогда не отказывающийся от того, что вы уже уважаете работу, которую вы вложили в проект!
Источники:
Статья о понятии технического долга:
Статья о методах работы программиста по преодолению фрустрации:
