Разработчики по-настоящему гордятся тем, что они делают, создают и программируют. Если вы тоже разработчик, вам может быть интересно сидеть перед светящимся экраном и работать без перерыва, будь то написание еще одной программы для разработки программы или создание безошибочного приложения.
Когда дело доходит до кодирования, возникает множество вопросов, поскольку каждый код, написанный разработчиком, гораздо хрупче, чем может показаться.
Программирование — это весело и круто, пока не начнутся кошмары, некоторые из вас могут думать о том, о чем мы говорим, а некоторые уже знают, о чем мы говорим. Написание кода для одних проще, а для других сложнее, все зависит от программы для программы и от разработчика к разработчику.
В этом блоге мы обсудим «ужасы кодирования разработчика», или вы могли бы назвать их их кошмарами, которых они определенно хотели бы избежать:
1. «Что, если я сломаю всю систему или, что еще хуже, сломаю каждый компьютер в центре обработки данных?»
Если кто-то не имеет технического образования, он может иметь мало или вообще не иметь представления о том, что может сделать простая строка кода. «Простая строка кода» способна привести к сбою всей системы компьютера, и были случаи, когда они приводили к сбою почти каждого рабочего стола в центрах обработки данных. Поэтому очевидно, что программисты боятся самого кода или программного приложения, которое они разрабатывают.
2. "Мы были на перемене!" Ну, были мы?
Функционирование программного приложения необходимо регулярно контролировать, чтобы оно было эффективным. Правильное использование предложения «break» так же важно, как и любая другая часть кода. Следует позаботиться о таких предложениях, как «если», «делать» и других, иначе их неправильное размещение также может привести к сбою кода.
Следите за обновлениями соответствующих приложений, иначе это может привести к хаосу, «Перерыву, который может никогда не закончиться».
3. Эксперимент, превращающийся в ошибку, причем необратимую!
Кто не любит эксперименты? В задачу разработчика входит создание новых программ, дизайнов и многого другого, для этого требуются довольно творческие навыки, не так ли? Творчество ведет к экспериментам, и вуаля, у вас есть новая программа… но подождите, что, если этот эксперимент окажется ошибкой? Это тоже необратимо? Впустую пропадут не только ваши усилия, но и время и энергия, а также ресурсы.
4. Если бы я только сохранил свою работу, когда мог!
Сохранение вашей работы очень важно, потому что, если даже из-за простой ошибки ваша система выйдет из строя, часы усилий пойдут насмарку, и вы будете очень утомлены, чтобы снова работать над ней с нуля. Так что никогда не теряйте файл просто потому, что вы «забыли» его сохранить.
5. Почему на исправление уходит больше времени, чем на сборку?
Исправление вашего кода занимает больше времени, чем сборка? Это может быть очень неприятно. Когда код сложен, его становится довольно сложно нарастить. Таким образом, создания программного обеспечения недостаточно, вы также можете найти ошибки или ошибки через несколько недель. Поэтому также важно убедиться, что вы эффективно делаете код без ошибок. Ознакомьтесь с источником ошибок по порядку.
6. Ошибки, которые не должны работать, но работают
Есть несколько инцидентов, которые можно было бы назвать «аномалиями», когда сработали ошибки, которые не могут работать или, по сути, не должны работать. Об одном таком инциденте рассказал Валдис Клетниекс, бывший старший инженер по компьютерным системам:
Он написал короткую программу на Perl, состоящую примерно из 150 строк, ее целью было автоматизировать несколько функций системы резервного копирования, которые программный пакет не обеспечивал разумным образом. Так что программа отлично работала 6–7 лет каждое утро.
Но затем должно было быть небольшое изменение, где фактическая строка кода была «если A равно B1, B2 или B3, сделайте это», которую нужно было изменить на «если A равно B1, B2, B3 , или B4, сделай это»
Внося необходимые изменения, он заметил, что еще одно выражение «если» несколькими строками ниже — наоборот. И это утверждение оказалось самым важным из всех 150 строк, и код не должен был работать и должен был дать сбой. Но как-то так за 6–7 лет!
Даже после того, как несколько сотрудников перепроверили код, все они пришли к одному и тому же выводу. И как-то на следующее утро ему сообщили, что код рухнул, как и должно было быть в самом начале.
Для него до сих пор остается загадкой, как этот код вообще работал, да еще и так долго, пока кто-то не рассмотрел его должным образом.
7. Ошибки, которые преследуют вас вечно!
«Всегда программируйте так, как будто парень, который в конечном итоге будет поддерживать ваш код, будет жестоким психопатом, который знает, где вы живете».
– Джон Вудс, программист и бывший продюсер компьютерных игр из Великобритании
Вы никогда не знаете, когда ваш код может потребоваться прочитать и изменить другому программисту, поэтому вы всегда должны писать легко читаемый и понятный код. Кроме того, есть ошибки, которые могут преследовать вас днями, месяцами, а может быть, и годами. Поэтому всегда будьте готовы не только разработать код, но и сделать его эффективным.
Надеюсь, этот блог был вам полезен, если не напугал. Это всего лишь несколько ситуаций, с которыми разработчики не хотят сталкиваться, чтобы узнать больше о таких инцидентах, вы можете присоединиться к нашему сообществу, социальной платформе под названием НАДОС. Здесь вы можете сотрудничать, взаимодействовать и общаться с опытными программистами и коллегами, а также с отраслевыми экспертами. Для получения дополнительной информации свяжитесь с нами. Посетите нас на Pepcoding.
Спасибо, что дочитали до этого места.
Автор: Седжал Шоу
Также читайте-
