Это нужно знать каждому программисту (или ядреный кликбейт про кодерский сленг)

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


YAGNI, KISS, DRY, WET, SLAP, ASAP, YOLO — что все это вообще значит?

Аве, Кодер! Если ты когда-нибудь читал англоязычную литературу по программированию, проходил курсы на английском языке, работал с англоязычными коллегами-кодерами или просто даже переписывался с ними, ты наверняка встречал эти аббревиатуры и, когда один бородатый кодер говорил другому KISS — гарантирую, что твоя бровь хотя бы немного приподнималась.

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

Визуалам сюда: youtu.be/ub0YtnSwqRA



KISS («Keep it simple, stupid» )


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

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

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

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



DRY («Don’t repeat yourself»)


Принцип «Не повторяй себя» по своей природе очень похож на KISS. Это довольно просто и в то же время имеет широкое значение. Это довольно просто и в то же время имеет широкое значение — поняли шутку?

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

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



WET («We enjoy typing»)


Решения WET широко распространены в многоуровневых архитектурах, где разработчику может быть поручено, например, добавить поле комментария в форму в веб-приложении. Текстовая строка «comment» может повторяться в метке, HTML-теге, в имени функции чтения, закрытой переменной, DDL базы данных, запросах и т.д. Подход DRY устраняет эту избыточность за счет использования платформ, которые уменьшают или исключают все эти задачи редактирования, кроме самых важных, оставляя возможность добавления новых переменных в одном месте.



YAGNI («You ain’t gonna need it»)


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

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

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

Кодерские проекты — это не те вещи, которые имеют четкое окончание. Если автор не откажется от идеи (и не передаст ее кому-то другому), проект, по сути, продолжается. Поэтому всегда есть и будет место для улучшения, будь то концепция, архитектура или даже сам код.
Одно дело — как идеальный код выглядит у тебя в голове — без ошибок и костылей, другое дело — что происходит на самом деле.
Естественно, легкий налет грусти и апатии может постичь кодера промозглым осенним вечером и кодер может решить понаоставлять в программе, так называемые, «точки расширения» (места, предназначенные для легкого учета новых функциональных возможностей), если они не используются разумно или не являются обязательной функцией, то превращаются просто в памятник прокрастинации и добавляют ненужную сложность и увеличивает размер кодовой базы. Если подумать, это даже противоречит ранее обсужденному принципу KISS.



SLAP («Single level of abstraction principle»)


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

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

Как говорил Роберт Мартин: «функции должны делать только одну вещь, и они должны делать это хорошо».

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

Грубо говоря, твои функции должны делать только одно, или другими SLAP-словами, должны иметь только один уровень абстракции.

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



FOOBAR (“F****d up beyond all recognition”)


Если перефразировать по-русски: «сломано так, что не восстановить».
Это чудесное выражение, пришедшее в IT из милитарного сленга, наряду с иными шедеврами, такими как, например, SNAFU — «Situation Normal — all fucked up»; это что-то вроде: «ситуация вполне естественная, но все оказалось напрасно».
По легенде, C-программисты использовали для переменных имена «foo» и «bar» в качестве, так называемых, «placeholder» или заполнителей места, особенно в учебных примерах. Так, их светлые головушки освобождались от бремени придумывания новых названий и могли сконцентрироваться на решении задач.
Со временем, это стало традицией и перекочевало из C во многие уже не такие древние языки, поэтому примеры таких имен можно встретить в учебниках повсеместно, а само слово «FooBar», применимое к проекту, означает, что можно начать подыскивать себе что-то другое.



ASAP («As soon as possible»)


«Так скоро, как только это возможно».
В последнее время стало трендом «As soon as reasonably possible» — «так скоро, как только это возможно, но в разумных пределах».
Вошло в обиход также из армейского сленга аж во время первой мировой. Активно используется по сей день, если данный акроним часто применяется в переписке с вышестоящими, то это может красноречиво указывать на уровень организации в компании или навыков управления и умения приоритизировать у начальства. Но бывают, конечно, и исключения, когда ситуация вышла из под контроля и вообще Foobar.



FYI («For your information»)


Официальное значение — «довожу до вашего сведения», а в вольном переводе: «чтобы ты знал». Встречается в переписке по мейлу повсеместно, особенно когда переписка ведется не лично с тобой, ясным солнышком, но тебя, все-таки, решили поставить в известность.



TL;DR («Too long; didn’t read»)


Аналог нашего «многабукв, неосилил». Такое можно частенько увидеть под длиннопостами, в которых автор раскрывает свою душу и срывает покровы, но читателю бывает лень вникать в сей опус.



DIY («Do it yourself»)


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



YOLO («You only live once»)


«Ты живешь только один раз». По аналогии с латинским «carpe diem» («лови момент»)- это призыв к полной жизни, даже к поведению, которое может нести некий риск. Является последним аргументом на границе с неразумным опытом или безудержным весельем, но порой может нести и более разумный посыл: глупо позволять страху верховодить твоими решениями, потому как ты живешь лишь раз.

И помни — YOLO, так что — KISS. Это был Ви. До встречи на канале! Аве!
Источник: https://habr.com/ru/post/513442/


Интересные статьи

Интересные статьи

На работе я занимаюсь поддержкой пользователей и обслуживанием коробочной версии CRM Битрикс24, в том числе и написанием бизнес-процессов. Нужно отметить, что на самом деле я не «чист...
Несколько лет я держу у себя датчик CO2 и уже писал о том, какого качества воздух в разных помещениях, транспорте, ситуациях. А сейчас задался вопросом, какова связь между повышением ...
Те, кто собираются открывать интернет-магазин, предварительно начитавшись в интернете о важности уникального контента, о фильтрах, накладываемых поисковиками за копирование материалов с других ресурсо...
«Существует только два вида языков: те, на которые жалуются и те, которыми никто не пользуется», — Бьёрн Страуструп, создатель C++ Очень часто слышатся заявления о том, что JavaScript нужно за...
Последние 28 лет моей жизни представляли собой нескончаемую череду переездов с места на место. И почему-то эта тенденция медленно (хотя, может, и быстро) перетекла со мной на новое место работы в...