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

СУХОЙ принцип

Не повторяйтесь (DRY) – это очень распространенная аббревиатура, используемая программистами для обозначения того, что программы создаются для автоматизации определенных повторяющихся задач, на которые люди не хотят тратить время и энергию. В случае, если вы повторяете одну и ту же командную строку в массиве кодирования, существуют методы, позволяющие уменьшить или полностью исключить повторение. Пример приведен ниже. Новички в программировании напишут следующую программу, если хотят отобразить таблицу умножения 7 в разных строках:

println(7 * 1);
println(7 * 2);
println(7 * 3);
println(7 * 4);
println(7 * 5);
println(7 * 6);
println(7 * 7);
println(7 * 8);
println(7 * 9);
println(7 * 10);

Предположим, кто-то хочет отобразить таблицу умножения до семи раз по сто, тогда это добавит в программу еще 90 строк!

Здесь на сцену выходит принцип DRY. Зачем повторять элементы строк в программе, если одну и ту же программу можно написать тремя строками, используя команду Цикл для n повторений. Следовательно, приведенный выше пример может быть записан следующим образом:

for (var i = 1; i < 11; i++) {
println(7 * i);
}

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

Существуют и другие применения принципа DRY, которые помогают создавать более чистое программирование.

  • Избегайте дублирования в комментариях к коду. Часто разработчик использует знаки //, * или #, чтобы объяснить функциональность кода, а затем приступить к написанию кода. Отсюда известное дублирование функций, которое отклоняется от принципа DRY. Когда из-за изменения требования или по любой другой причине необходимо изменить код, комментарий также должен быть изменен соответствующим образом. Этого можно избежать, используя компоновку кода в самой программе. Таким образом, нет дублирования и, следовательно, более низкий предел для ошибки или упущения.
  • Избегайте дублирования на основе данных/логики. Вы можете разработать лучший код на основе данных или логики, чтобы избежать дублирования. Например, если вы хотите создать игровую программу, в которой ваш курсор должен перемещаться в 4 направлениях, чтобы найти точку и получить очки. Вы можете написать четыре строки кода для каждого направления (север, восток, юг и запад) или использовать команду move(direction) для завершения программы в одной строке кода. Это то, что утверждает принцип DRY.
  • Избегайте дублирования алгоритмов. Этого можно легко избежать, проанализировав всю программу и ее цель. Например, у вас может быть программа: пойти в отель А, потом поесть, поспать и потанцевать, затем пойти в отель Б, потом поесть, поспать и потанцевать, затем пойти в отель С… и так далее. Вы должны быть в состоянии организовать посещение отеля следующим образом:

public void GoToHotel*(Action activity)
{
Eat();
Sleep();
Dance();
}

Это помогает применить принцип DRY к алгоритму.

Эти шаги помогут вам избежать программирования копирования и вставки.

Противоположность СУХОМУ — ВЛАЖНОМУ (Пишите все дважды, или Тратите время всех, или Нам нравится печатать). Сам антоним указывает на полезность принципа DRY в кодировании.

Принцип ПОЦЕЛУЯ

Термин Keep it Simple, Stupid (KISS) был придуман покойным Келли Джонсоном, авиационным инженером в корпорации Lockheed (теперь известной как Lockheed Martin). Этот термин Келли использовал, чтобы объяснить инженерам, насколько важно сохранять простоту конструкции самолета. Самолет нужно было быстро отремонтировать в боевой обстановке и человек в полевых условиях должен был уметь чинить самолет с помощью базовой подготовки и простой конструкции.

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

Как говорит известный французский писатель и летчик Антуан де Сент-Экзюпери:

Совершенство достигается не тогда, когда больше нечего добавить, а тогда, когда нечего убрать.

Несколько способов, с помощью которых программист может уменьшить сложность:

  • Имена переменных в программе должны хорошо служить своей цели. Они должны быть в состоянии правильно определить переменную
  • Название метода также должно соответствовать цели, для которой метод используется.
  • Как упоминалось в предыдущем примере принципа DRY, комментарии в методе следует использовать только тогда, когда ваша программа не может полностью определить метод.
  • Классы должны быть разработаны таким образом, чтобы нести единую ответственность
  • Удалите избыточные процессы и алгоритмы, как описано в процессе DRY.

Ниже приведены преимущества применения принципа KISS в кодировании:

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

Следующий пример на языке программирования SWIFT для iOS дает представление о применении принципа KISS:

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

if isSuccess {
label.textColor = .blue
} else {
label.textColor = .red
}

Та же самая логика может быть написана с использованием тернарного оператора, поэтому здесь применяется принцип KISS:

label.textColor = isSuccess ? .blue : .red

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

Еще несколько способов, предложенных в SWIFT, с помощью которых вы можете устранить сложность и применить принцип KISS в своем коде, приведены ниже:

  • Использование свойства Computed вместо сложного метода в качестве адекватной альтернативы. Вычисляемые свойства могут быть определены как особый тип свойств, которые не хранят никакого значения. Вместо этого они используются для вычисления значения на основе других свойств.
  • Использование синтаксических сахаров, таких как firstIndex(где: ), завершающие замыкания, if-let и т. д., чтобы избежать написания многословных кодов.
  • Использование функций высшего порядка, которые принимают одну или две другие функции в качестве аргументов и в результате возвращают более простую функцию. FlatMap, Reduce и Sorted — это примеры функций высшего порядка, которые упрощают код в соответствии с принципом KISS.

YAGNI (Вам это не понадобится)

Говоря простым языком, YAGNI как принцип означает удаление ненужной функциональности или логики. Основатель практики экстремального программирования (XP) Рон Джеффрис формулирует это следующим образом:

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

Часто программисты склонны заглядывать в будущее и перегружать программу ненужной логикой, алгоритмами, методами и кодами, которые никогда не будут использоваться. Некоторые делают это как бизнес-требование, а некоторые боятся, что не смогут включить его позже, когда возникнет определенная ситуация. Вот несколько ситуаций, когда программисту следует рассмотреть возможность использования YAGNI:

  • Если вас попросят выполнить проверку полей электронной почты и пароля с помощью программы, нет необходимости добавлять код для проверки поля имени. Возможно, вам это никогда не понадобится.
  • Если программиста просят связать различные базы данных онкологических больных больницы с приложением о здоровье, разработчик не должен рассматривать больницы, которые уже закрыты. Они могут никогда не открыться, а база данных пациентов уже должна быть перемещена в действующие больницы.
  • Некоторые программисты могут создавать абстракции, даже если у них есть только один четко определенный случай в ожидании добавления случаев. Итак, они пишут ненужные коды и делают предположения о дальнейших случаях. Этого следует избегать.
  • Использование логики «если-иначе», даже если часть «иначе» всегда будет отрицательной во всех встречающихся тестовых сценариях.

Есть несколько причин, по которым программисты предпочитают нарушать YAGNI:

  • Непонимание функции или бизнеса. Иногда программисты не знают полных бизнес-сценариев. Например, программист отдела продаж разрабатывает адаптивную логику для восьми различных бизнес-подразделений в организации, как указано в их миссии. Но он/она может не знать, что 3 из них могли быть закрыты. Следовательно, исключения и правила, рассмотренные для закрытых единиц, пропадают зря.
  • Слишком много видения будущего. Это может быть связано с недальновидностью бизнес-команд в передаче сценариев, которые им могут никогда не понадобиться. Всегда желательно планировать хорошо, чтобы иметь или обязательно иметь сценарии, но глупо программировать, мне могут потребоваться сценарии типа «один день».
  • В некоторых случаях, когда слишком дорого менять кодировку в будущем или нецелесообразно нарушать и без того громоздкую логику, разработчики могут пойти на нарушение принципа YAGNI.

Ключ к обнаружению кодов YAGNI и их подавлению на самой стадии разработки — это навык, который приходит только с опытом.

Твердый принцип

Принцип SOLID представляет собой объединение пяти различных принципов разработки программного обеспечения, как указано ниже:

1) Принцип единой ответственности (SRP)
2) Принцип открытого/закрытого доступа (OCP)
3) Принцип замещения Лискова (LSP)
4) Принцип разделения интерфейсов (ISP)
5 ) Принцип инверсии зависимостей (DIP)

Эта концепция была инициирована Робертом Мартином, также известным как «Дядя Боб». Он используется в течение последних многих лет.

Ниже приведены цели применения принципа SOLID в программном обеспечении:

  • Сделайте его более понятным
  • Легко поддерживать, даже если это делают другие программисты
  • Легко воспроизвести и повторно использовать
  • Легко проверить. Совместимость с автоматизированным тестированием
  • Гибкость для адаптации к изменениям в сценарии

Использование концепции SOLID отличает профессионалов от любителей. Крайне важно изучить концепции и применять их в нужном месте.

Вы можете узнать больше о Принципах проектирования SOLID в этом сообщении блога.

Разделение ответственности (SoC)

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

По словам пионера голландского компьютерного ученого Эдсгера В. Дейкстры,

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

Это применимо ко многим аспектам программного обеспечения и дизайна, как указано ниже:

  • SoC для функций программирования. Если во время программирования вы понимаете, что используемая функция становится слишком объемной для обработки и обрабатывает слишком много аргументов одновременно, ее следует немедленно разделить на более мелкие компоненты. .
  • SoC для модулей: подобно функциям, на более высоком уровне функции должны быть сгруппированы таким образом, чтобы они выполняли желаемые задачи с логической взаимосвязью между ними. Группировка функций, выполняющих схожие функции, — это мантра.
  • Сплоченность. Когда функционально схожие коды группируются вместе, это называется усилением сплоченности. Примеры таких функций, как drawRectangle и drawSquare
  • Разделение. Иногда похожие по звучанию функции с совершенно разными целями и способами выполнения объединяются в коде. Желательно отделить их, чтобы добиться более чистой программы.

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

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

MVP — минимально жизнеспособный продукт

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

По словам Стива Бланка, разработчика, который популяризировал эту концепцию: "Вы продаете свое видение и предоставляете минимальный набор функций дальновидным, а не всем"

Некоторые люди путают минимально жизнеспособный продукт с прототипом. Однако есть несколько заметных различий между MVP и тем, что разработчик подразумевает под прототипом.

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

Термин MVP впервые был использован Фрэнком Робинсоном в 2001 году. Позже он был популяризирован Стивом Бланком и Эриком Рисом.

Подтверждение концепции (PoC)

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

Эта брошюра аналогична Proof of Concept. Это дает вам краткий обзор того, что вы можете ожидать, если вы закажете пиццу и съедите ее.

Доказательство концепции также иногда называют доказательством принципа, при котором предпринимаются действия, чтобы определить, является ли идея достаточно достойной, осуществимой или возможной для воплощения в реальность. Он также проверяет жизнеспособность программного продукта для решения бизнес-задач. По сравнению с прототипом или минимально жизнеспособным продуктом (MVP), Proof of Concept представляет собой документ, презентацию или демонстрацию начального этапа, подготовленный для описания характеристик и преимуществ (FAB) продукта и его функций. Прототип и, в конечном итоге, MVP следует за успешным доказательством концепции, должным образом принятым клиентом или конечным пользователем.
При создании PoC необходимо учитывать следующие факторы:

  • Определите сторонников (ключевой персонал). Сторонником дела может быть лицо, принимающее решения в организации-заказчике, специалист по процессам, технический руководитель или финансовый руководитель. PoC должен быть разработан в соответствии с аудиторией.
  • Факторы успеха. Определите цель нового требования, ожидания по сравнению с существующей настройкой, доступное время, задействованные деньги и т. д.
  • Совместная работа на каждом этапе.Совместная работа на каждом уровне и на каждом этапе помогает разработчику лучше понять и реализовать требования.
  • Понимайте следующие шаги в самом начале:Ясность следующих шагов всегда поможет в создании приемлемого PoC.
  • Непрерывное совершенствование благодаря обратной связи. Разработчик должен получать отзывы от своей организации в дополнение к отзывам клиентов при разработке PoC.

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

DIE (дублирование — это зло)

Это похоже на принцип СУХОЙ (не повторяйтесь), в котором рекомендуется воздерживаться от ВЛАЖНОГО (напишите все дважды). В частности, принцип DIE определяет правила дублирования кода. Ниже приведены причины, объясняющие опасности, связанные с дублированием кода:

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

При кодировании обычно наблюдаются следующие типы дублирования:

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

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

BDUF (Большой дизайн впереди)

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

Ниже приведены предположения перед взаимодействием с BDUF:

  • Мы знаем требования к дизайну и они не подлежат большим изменениям
  • Дизайнерское решение эффективно
  • Проблемы разработки могут быть решены, пока продукт все еще находится на стадии разработки.

Ниже приведены преимущества BDUF:

  • Легко составить бюджет, так как все расходы были учтены на самом этапе проектирования
  • Простота разработки, так как дизайн продукта уже сделан
  • Дизайн ведет развитие. Пользовательские требования уже заложены на этапе проектирования

Ниже приведены подводные камни использования BDUF:

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

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

GIGO - мусор на входе, мусор на выходе

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

Джорджу Фойкселю, программисту и инструктору IBM, приписывают популяризацию концепции GIGO.

По словам шотландского импрессиониста Рори Бремнера:

“ Если вы поместите мусор в компьютер, ничего не выйдет, кроме мусора. Но этот мусор, прошедший через очень дорогую машину, как-то облагораживается, и никто не осмеливается его критиковать», — Рори Бремнер

Первоначально опубликовано на https://www.geeksprogramming.com 27 марта 2022 г.