Разработка программного обеспечения - это не только использование ваших навыков программирования для создания чего-либо. Быть разработчиком программного обеспечения означает больше, вы несете ответственность за многие вещи, например за качество кода. Независимо от того, масштабируется ваш код или нет, понятен ваш код или нет.

Если вы тот, кто не вошел в профессиональный мир, вам может быть интересно, какое это имеет значение. Но это очень важно, когда вы пишете код производственного уровня. Я вам все подробно объясню.

Вот 6 вещей, которые вы должны знать, как разработчик программного обеспечения, чтобы писать код производственного уровня.

1. Напишите осмысленное имя

Всегда давайте осмысленное имя всякий раз, когда вы объявляете переменную или создаете функцию или класс. Например, если вы создаете функцию, задачей которой является сложение двух значений, назовите ее «добавить».

Почему это важно?

Имя раскрывает назначение этой переменной, функции или класса. предположим, я создал функцию сложения двух чисел, но назвал ее «вычитание» или «rand_123», прочитав «вычитание», вы подумаете, что задача функции - вычесть два числа, и, прочитав «rand_123», вы ничего не поймете об этой функции.

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

Правила, которым нужно следовать:

  • Избегайте мысленного картирования: используйте имя, понятное каждому. Остальные должны понять намерение, прочитав имя.
  • Название класса. Название класса всегда должно быть существительным или существительным словосочетанием. Из класса мы создаем объект, поэтому это всегда должно быть существительное словосочетание.
  • Название метода / функции. Название метода должно быть глаголом или глагольной фразой. Метод / функция - это тот, в котором реализована основная функциональность, это тот, который выполняет свою работу. Вот почему глагольная фраза должна использоваться для названия функции / метода.
  • Доступное для поиска имя: используйте имя, по которому будет легко выполнять поиск. Это принесет пользу всем, предположим, вам нужно было отладить проблему в определенной функции. Но как вы найдете эту функцию в строке кода из 1000-х годов? Если вы начнете читать каждую строку, это займет много времени. Имя с возможностью поиска легко запомнить, и вы можете найти функцию в любой среде IDE, найдя ее функциональные возможности.
  • Не качайте: избегайте использования одного и того же слова в двух целях. Если вы используете одно и то же имя для нескольких целей, это вызовет путаницу, что повлияет на процесс разработки. Использование одного и того же термина для двух разных идей - это, по сути, игра слов.
  • Используйте доменное имя решения: человек, который будет читать код, будет программистом. Таким образом, вы можете продолжить работу с терминами CS, названиями алгоритмов и т. Д. Но если вы сделаете это для каждого такого имени, то это будет несправедливо по отношению к разработчику, поскольку он / она должен бегать туда и обратно к клиенту, прося концепция.
  • Используйте проблемное доменное имя: когда нет программиста для того, что вы делаете, используйте проблемное доменное имя. По крайней мере, другой разработчик, поддерживающий ваш код, может спросить эксперта в предметной области, что это означает.

2. Функции

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

Почему это важно?

В современном мире никто не хочет тратить свое время зря. Чем больше вы тратите время на понимание кода, тем задерживается доставка продукта клиенту.

Кроме того, это упрощает отладку и повторное использование функции снова и снова. Вы можете знать основы программирования, что никогда не следует повторять код.

Правила, которым нужно следовать:

  • Маленький: функция должна быть достаточно маленькой, чтобы поместиться на экране. Это примерно 20–30 строк кода. Существует так много вариантов размера экрана, поэтому, учитывая, что все типы 20–30 строк кода будут хорошей идеей для определения длины функции.
  • Блоки и отступы. Я встречал людей, которые не использовали блочные отступы. Это затрудняет чтение кода другими разработчиками. Где начинается и где заканчивается блок. Создание поблочного отступа упрощает чтение, а также упрощает отладку (особенно, если это синтаксическая ошибка).
  • Делайте одно. Функции должны делать одно. Они должны делать это хорошо и должны только. Назначение функции - делать только одно. Если ваша функция состоит из нескольких разделов с различными функциями, создайте отдельную функцию для функций этого раздела и вызовите эту функцию.
  • Оператор switch: если вы оператор switch / if, то пытается заменить его полиморфизмом. Вы познакомитесь с концепцией полиморфизма из объектно-ориентированного программирования. Вы можете создать несколько методов путем переопределения или перегрузки.
  • Аргументы функции: чем меньше аргументов, тем лучше. Если возможно, передайте в функцию только 1 аргумент. При макс передайте 3 аргумента, если вам нужно передать больше, тогда передайте это значение как объект или отдельные аргументы списка .
  • Разделение команд и запросов: функция должна либо что-то делать, либо отвечать на что-то, но не на то и другое одновременно. Как упоминалось в предыдущем пункте, функция должна делать только одну вещь. Точно так же функция должна либо изменить состояние объекта, чтобы вернуть некоторую информацию об объекте.

Как написать лучшую функцию?

  • Реструктуризация / Рефакторинг
  • Сделайте функцию маленькой
  • Функция должна делать только одно
  • Меньше аргументов в функции

3. Комментарии

По возможности старайтесь избегать комментариев. Комментарии - признак плохого кода. Сделайте код организованным так, чтобы не требовались комментарии для объяснения функциональности. Выразите себя в коде.

Комментарии не всегда плохи в использовании, поэтому нужно знать, когда они хороши, а когда плохи.

Хорошие комментарии:

  • Юридический комментарий: Заявления об авторских правах и авторстве - это разумные вещи, которые следует помещать в комментарий в начале каждого исходного файла.
  • Информационные комментарии. Иногда полезно добавить основную информацию в комментарии. Например, какой формат даты нужно отправить в функции.
  • Объяснение намерения. Иногда вам нужно объяснить, почему вы использовали определенную логику или условие. На этот раз вы можете добавить небольшой поясняющий комментарий (однострочный комментарий).
  • Уточнение. Иногда бывает полезно перевести значение непонятного аргумента или возвращаемого значения во что-то удобочитаемое.
  • Комментарии к ЗАДАЧУ. Разумно оставлять заметки о выполнении в виде комментариев // ЗАДАЧИ. Комментарии TODO объясняют, почему функция имеет вырожденную реализацию и каким должно быть будущее функции.

Плохие комментарии:

  • Избыточные комментарии: Если в вашем коде слишком много комментариев. Тогда комментарий, вероятно, займет больше времени для чтения, чем код, и будет полностью избыточным.
  • Шумовые комментарии. Комментарии, которые бесполезны и не содержат новой информации о коде.
  • Комментарии в журнале. Некоторые люди ведут дневник всякий раз, когда редактируют код. Раньше это было полезно, но теперь у нас есть система контроля версий, чтобы отслеживать это.
  • Закомментированный код. Хранить закомментированный код - плохое занятие. Вы можете подумать, что вернуть код будет легко. Но имейте в виду, что при выпуске производственной версии эти закомментированные коды должны быть удалены. Нет смысла оставлять это комментарии после того, как планируется выпуск продукции.
  • Слишком много информации. Не оставляйте в комментариях нерелевантную информацию, так как она бесполезна и занимает дополнительное место в хранилище.

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

4. Объекты и структура данных

Есть причина, по которой мы храним наши переменные в секрете. Мы не хотим, чтобы кто-то еще зависел от них. Мы хотим сохранить свободу изменения их типа или реализации по прихоти или импульсу.

Почему программисты автоматически добавляют геттеры и сеттеры к своим объектам, открывая свои частные переменные, как если бы они были общедоступными?

Абстракция данных

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

Закон Деметры

Закон Деметры гласит, что модуль должен знать внутренности объектов, которыми он манипулирует. Объекты не должны раскрывать свою внутреннюю структуру через методы доступа, потому что это должно раскрывать, а не скрывать свою внутреннюю структуру.

Точнее, Закон Деметры гласит, что метод f класса C должен вызывать только следующие методы:

  • C
  • Объект, созданный f
  • Объект, переданный в качестве аргумента функции f
  • Объект, хранящийся в переменной C

От:

objectA.getObjectB (). doSomething ();

To:

objectB = objectA.getObjectB ();

objectB.doSomething ();

Объекты передачи данных

Объект передачи данных - это объект, который используется для инкапсуляции данных и отправки их из одной подсистемы приложения в другую. DTO чаще всего используются уровнем служб в многоуровневом приложении для передачи данных между уровнями.

5. Обработка ошибок

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

Правила, которым нужно следовать:

  • Используйте выражения вместо кода возврата. Многие люди просто отправляют в ответ код ошибки. Но чтобы понять, что разработчик кода ошибки должен прочитать и проверить значение этого кода ошибки. Вместо отправки сообщения с кодом ошибки это была ошибка. Это будет легко понять.
  • Сначала напишите оператор Try-Catch-finally: всякий раз, когда вы создаете новую функцию, сначала напишите оператор Try-Catch-finally. Это самая важная задача, прежде чем приступить к реализации функциональности.
  • Определите классы исключений в соответствии с потребностями вызывающего: может быть другой тип ошибки, например ошибка проверки, ошибка программирования или что-то еще. Определите выброс ошибки в зависимости от типа ошибки.
  • Не возвращать значение NULL. Предположим, вы создали функцию, и ваше основное условие проверяет, не является ли аргумент значением NULL, но если аргумент имеет значение NULL, вы возвращаете значение NULL. Вместо возврата нулевого значения верните NullPointerException.
  • Не передавайте null: никогда не передавайте null в функции, если функция не ожидает, что вы передадите null. Лучше по возможности избегать этого сценария.

6. Классы

Класс в объектно-ориентированном программировании - это план или прототип, который определяет переменные и методы (функции). Объект в OOPS - это образец класса. Программные объекты часто используются для моделирования объектов реального мира, которые вы можете найти в повседневной жизни.

Классы должны быть небольшими

Размер класса мы измеряем, подсчитывая количество обязанностей. Больше обязанностей, больше размер класса.

Примечание. Мы должны уметь написать краткое описание класса примерно из 25 слов, не используя слова «если», «и». , «или» или «но».

  • Принцип единого репозитория. В SRP указано, что у класса или модуля должна быть одна и только одна, причина для изменения.
  • Сплоченность: класс должен иметь небольшое количество переменных экземпляра. Каждый из методов класса должен управлять одной или несколькими переменными. В общем, чем больше переменных обрабатывает метод, тем более связным он является со своим классом.

Организация изменений

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

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

Это 6 основных вещей, которые должен знать программист / разработчик, взятые из книги Роберта К. Мартина Чистый код. В этой книге вы можете изучить более сложные темы, такие как модульное тестирование, параллелизм, рефакторинг, запах кода и т. Д.