Жизнь

29 распространенных реакций программистов, когда дела идут плохо

Просто люблю писать, переводить и давать людям возможность читать интересный контент. И пусть я не всегда идеальна — есть к чему стремиться!!!

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

Мы хотели бы поделиться с вами коллекцией фраз и идей, которые вы могли бы услышать от программистов, пытающихся исправить свой исходный код. Это все беззаботный юмор, срабатывающий, когда все становится слишком напряженным. Как правило, приложение будет (в конечном итоге) работать, а сам разработчик перейдет к следующей задаче.

Уверены, что многие веб-разработчики и программисты увидят себя или своих коллег в этой подборке.

1. «Я не знаю, удалить это или переписать»

Возвращение к старому исходному коду из вашего прошлого приводит к искушению переделать более крупные кластеры блоков. Уродливые логические выражения с многословным синтаксисом очень трудно читать! Но опять же, если код не сломан, не исправляйте его. Это борьба, с которой часто сталкиваются программисты, и она, несомненно, изводит многих разработчиков программного обеспечения.

2. «Я должен проверить Github для начала работы»

Уверены, что большинство разработчиков знают о Github и удивительных проектах с открытым исходным кодом, которые публикуются каждый день. Программисты, работающие на всех языках, присоединяются к сети, чтобы разветвлять существующие проекты, добавлять Вики-обсуждения или создавать собственные хранилища кода. Это отличный ресурс с крутыми плагинами и шаблонами, которые можно использовать в различных проектах.

3. «Зачем этому скрипту столько библиотек?»

Переходя, в частности, на более крупные языки, такие как Java и Objective-C, количество библиотек может стать чрезмерным. Это может быть очень заметно при построении на фреймворке, который требует большого обслуживания. Даже некоторые плагины для JavaScript могут нуждаться в несметном количестве дополнительных файлов. Иногда беспорядок будет раздражать – но, по крайней мере, это работает!

4. «Должно же быть решение где-то в Интернете»

Первая реакция на сложную проблему — это проверка Интернета. Многие программисты будут публиковать на форуах темы о своих проблемах, и они в конечном итоге будут решены и архивированы. Google отлично подходит для подбора ключевых слов, связанных с вашей проблемой, и указывает вам правильное направление этих полезных тем для обсуждения. К сожалению, иногда просто нет достаточной информации по какому-то конкретному вопросу.

5. «Есть ли плагин для этой функции?»

Зачем изобретать велосипед? Плагины — это отличный ресурс для расширения пользовательского интерфейса любой программы или сайта, которые могут предложить некоторые настройки и уникальные опции для разработчиков. Кроме того, если еще нет доступного плагина, почему бы не создать его самостоятельно?

6. «Сайт работает, но я опасаюсь за Internet Explorer»

Думаем, не нужно упоминать об испытаниях и невзгодах, которые произошли в истории рендеринга веб-страниц в Internet Explorer. Начиная с версии 5.5 и примерно до IE9-IE10 шла постоянная борьба за расширенную поддержку браузера. Веб-разработчики могут опасаться отладки веб-страницы, открывающей в IE6 кошмар рендеринга. К счастью, эти дни постепенно уходят в прошлое.

7. «Для логического оператора это выглядит не очень логично»

Существуют логические операторы для циклов if / else, для циклов while loops, do loops… список довольно длинный. При просмотре примера кода у некоторых возникают рецидивы, когда они пытаются понять, как должна работать их логика. От одного только количества операторов NOT и сравнительных знаков у вас может закружиться голова.

8. «Я потратил 30 минут на написание функции и два часа на то, чтобы заставить ее работать»

Разве это не программная история десятилетия? Вы напеваете себе под нос, просто прекрасно выстраивая то, что знаете, когда вдруг функция выдает фатальную ошибку. Так что теперь вам придется вернуться назад, удаляя блоки кода, пытаясь точно определить неисправный номер строки. Это может быть утомительным, но облегчение, когда вы, наконец, нашли виновника и раскрыли дело – просто невероятно.

9. «Прочитав несколько постов в блоге, я теперь понимаю, что все время делал это совершенно неправильно»

Многим нравится углубляться в темы со своими собственными идеологиями программирования, но это может привести к проблемам в будущем, когда дела идут не по плану. Бывают случаи, когда вы начинаете проект и сталкиваетесь с проблемами, а затем ищите посты в блогах и другие статьи для поддержки. В итоге обнаруживаете, что весь метод практически неверен, и было бы проще начать все сначала! Проведение небольшого исследования на раннем этапе, безусловно, сэкономит время в долгосрочной перспективе.

10. «Хорошие люди в Stack Overflow, вероятно, могут мне помочь»

Вы можете подсчитать, сколько раз вы решали сложную проблему с помощью Stack Overflow. Сообщество полно хороших, умных людей, которые готовы помочь, если вы сделаете первый шаг. Из всех онлайн-форумов это определенно самая широко поддерживаемая сеть для программирования и веб-разработки.

11. «Столько хлопот из-за пропущенной закрывающей скобки»

Отладка — это последствия того, что вы делаете. Два шага вперед, один шаг назад, еще два вперед и так далее. Ощущение, что вы часами смотрите на код, просто ища какую-то ошибку в названиях функций или области видимости переменных, только чтобы найти недостающую скобку — это странное чувство. Все это время потеряно из-за незначительной синтаксической ошибки. Чувствуете себя одновременно гением и глупцом.

12. «Ну, кофе-брейк!»

Иногда вам просто нужно встать и уйти подальше от монитора. После нескольких часов зависания над клавиатурой, это определенно помогает разбавить рутину. Большинство руководств по здоровью рекомендуют делать перерыв каждые 30-60 минут. Но все зависит от ваших потребностей, и если вас больше раздражает остановка в середине программы для перерыва, чем его отсутствие.

13. «Я должен приостановить этот проект и разобраться с ним позже»

Альтернативой рабочим перерывам является уход от проекта вместо того, чтобы уйти от вашего компьютера. Может быть, есть и другая работа, которую нужно сделать, так что идите и займитесь ею вместо этого. Это было бы лучшим распределением времени и ресурсов, чем утомление при попытке решить проблему, которую вы рассматривали в течение пяти часов подряд.

14. «Интересно, будет ли классическая музыка стимулировать мои навыки программирования?»

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

15. «Возможно, сейчас самое время проверить теорию Пика Баллмера»

Думаем, что многие читатели знают о Пике Баллмера, который был придуман героем веб-комикса xkcd. Если говорить просто, теория утверждает, что программисты достигают пика способности кодирования после употребления определенного количества алкоголя. Это было приписано Стиву Баллмеру за его дурацкие выходки, которые могут быть истолкованы как бред пьяницы, хотя это несколько иронично, поскольку Баллмер никогда не был по-настоящему программистом в Microsoft. Думаю, нам придется подождать, пока кто-нибудь еще не опробует эту теорию.

16. «Кто-то возился с моим исходным кодом?»

Это звучит как бред и паранойя, но иногда вы просто должны задаться вопросом, кто пишет эту чепуху, когда вы заняты тем, когда вы заняты сном. Просматривая проекты прошлых недель или месяцев, вы можете почувствовать себя не в своей тарелке. Иногда вы находите вещи, которые вы никогда не вспомните — даже из проектов, которые вы только что просмотрели на прошлой неделе! Можно списать это на сумасшедшее, но никогда не знаешь ...

17. «Я понятия не имею, что это значит»

Худшая ситуация, с которой вы можете столкнуться — это изучить исходный код, абсолютно не представляя, что делать. Это может быть результатом ваших собственных проектов или чьих-то других, но это все та же проблема. Теперь вам нужно решить, стоит ли тратить больше времени на поиск альтернативы или анализ скрипта, чтобы узнать, как он работает.

18. «Мне нужно погуглить это сообщение об ошибке»

Google — лучший друг при устранении проблем. Сообщения об ошибках пытаются помочь, но если вы не запомнили, что означают разные коды, это больше похоже на переведенный компьютерный язык. К счастью, в Интернете есть большая поддержка для определения того, что именно означают эти сообщения об ошибках.

19. «Я должен остановиться и покончить с этим ​​… но я действительно хочу понять это!»

Мы все знаем это чувство полного разочарования, когда вы хотите сказать, что это конец, но в то же время кажется, что сдаваться — это не правильный выбор. Вы хотите продолжать двигаться вперед и попробовать новые решения для отладки. Но что, если это превращается в пустую трату еще одного часа? Это может быть ужасно удручающим.

20. «О, Боже, почему я не написал ни одного комментария?»

Когда речь идет о более простом интерфейсе HTML / CSS / JS, не всегда нужно оставлять комментарии. Но более сложные скрипты и программы потребуют какой-то организации, когда вы захотите оглянуться назад через несколько месяцев или даже через пару лет. Иногда вы забываете прокомментировать функции и их параметры, формат вывода и другие важные данные. Это, несомненно, приведет к путанице в будущем, когда начнут появляться ошибки, и вам придется отлаживать весь скрипт для решения проблемы. Если бы только были полезные комментарии…

21. «Это работало 20 минут назад…»

Возможно, самая неприятная часть создания программы — это когда она переходит от работающей к неработающей — без ЛЮБЫХ обновлений ЛЮБОЙ части кода! Серьезно, такое происходит. И это не имеет никакого смысла — может быть, другая программа запускала кэшированную версию? Тогда бывают случаи, когда обновление одного крошечного фрагмента кода приводит к сбою всей программы при ошибке и она просто прекращает работать полностью. Вернитесь к самой последней рабочей копии и продолжайте двигаться вперед дальше.

22. «Ты забыл одну паршивую точку с запятой, и вся программа рушится»

Почти каждый язык программирования, который используется, будет нуждаться в символе для завершения строки. Не все из них, но это определенно распространено в семействе C / C++. Если вы забыли добавить одну завершающую точку с запятой, это будет честной ошибкой! Но парсер не понимает этого и выдает фатальную ошибку. Теперь вам придется потратить еще 20 минут на поиск кода для технической неисправности, когда все время пропускалась точка с запятой. Ах, радости отладки программного обеспечения.

23. «Интересно, сколько будет стоить заплатить кому-то, чтобы он исправил мои ошибки?»

Подавляющая мысль о найме другого разработчика заманчива, но, очевидно, далеко не финансово жизнеспособна. Кроме того, как бы вы учились на всех этих ошибках, если бы не пачкали свои руки? Это может быть чем-то приятным, когда вы, наконец, поняли концепцию программирования после нескольких неудачных попыток. Но все же это не мешает подобной мысли частенько приходить вам в голову, правда?

24. «Как у этого API нет документации?!»

Самое разочаровывающее в использовании плагина или фреймворка с плохой документацией — это то, что вам нужно самому глубоко изучить исходный код. Почти все обожают проекты, где разработчики тратят время на то, чтобы специально разработать удобную страницу документации. Все параметры и опции объяснены, возможно, даже используются в некоторых примерах кода. Но, к сожалению, это не всегда так. Легче держаться подальше от плохо документированной работы и избавить себя от проблем.

25. «Надеюсь, я сохранил резервную копию этой базы данных…»

При написании и отладке кода не всегда возникают мысли о резервной копии. Тем не менее, резервные копии данных предлагают отправную точку, чтобы вернуться назад во времени до внесения определенных изменений. Это особенно полезно в живой серверной среде, где изменения реализуются немедленно. Не забудьте сохранить локальные копии файлов вашего сайта и баз данных на случай чрезвычайной ситуации! Это может быть раздражающей задачей, но не такой раздражающей, как восстановление поврежденной базы данных SQL.

26. «Каково самое быстрое решение, чтобы заставить это работать должным образом?»

После нескольких часов суматохи в поисках нестандартного решения становится совершенно ясно, что вам может понадобиться новый подход. Программисты хотят, чтобы функциональность работала в первую очередь, прежде чем создавать красивый интерфейс вокруг нее. Определите самое быстрое и точное решение и внедрите его, чтобы оно работало в лучшем случае 100% времени. Тогда легче перейти к красивой эстетике.

27. «Держу пари, что обновление моего программного обеспечения исправит эту проблему»

Командам, которые управляют зависимостями и плагинами для языков программирования, не нужно очень часто публиковать релизы. Иногда обновление вашей версии PHP / Ruby / Python / SQL может решить проблемы с отладкой при передаче файлов с вашего компьютера на работающий сервер. Локальные обновления очень редко помогают исправить ошибку в исходном коде, если только ваша версия безнадежно не устарела. Эй, это стоит попробовать!

28. «Мне следовало бы быть более организованным и изучить Git… но я займусь этим на следующей неделе».

Пакет управления версиями с открытым исходным кодом Git чрезвычайно популярен среди программистов. Он предлагает более легкую кривую обучения, чем другие конкуренты, и он используется во многих онлайн-хранилищах, таких как Github и Bitbucket. Разработчики откладывают в сторону эту идею, потому что у нее определенно крутая кривая обучения начального уровня для начинающих. Однако, как только вы поймете основные команды, Git станет легкой прогулкой. И это делает практику отладки с контролем версий намного понятнее.

29. «В мусор это, я начну все с нуля»

Иногда после нескольких часов попыток решения вам просто нужно переместить свои рабочие файлы в архивный каталог (или удалить их) и начать все заново с нуля. Это решение трудно принять, учитывая, что предыдущие часы были потрачены впустую на небольшую отдачу. Но когда вы в затруднительном положении, начать все сначала — это то, что вам нужно, чтобы довести проект до конца.

Всем успешной работы и творчества!

Источник

  • 2448