![](https://habrastorage.org/webt/jj/xa/cl/jjxaclypbohglvia_ngy276b_-g.jpeg)
YAGNI, KISS, DRY, WET, SLAP, ASAP, YOLO — что все это вообще значит?
Аве, Кодер! Если ты когда-нибудь читал англоязычную литературу по программированию, проходил курсы на английском языке, работал с англоязычными коллегами-кодерами или просто даже переписывался с ними, ты наверняка встречал эти аббревиатуры и, когда один бородатый кодер говорил другому KISS — гарантирую, что твоя бровь хотя бы немного приподнималась.
В этой статье мы разберем, что означают эти популярные в среде англоязычных IT-шников словечки, а точнее аббревиатурки.
Визуалам сюда: youtu.be/ub0YtnSwqRA
![](https://habrastorage.org/webt/u-/pi/wa/u-piwa3lnwiktna-b9jgovpofyi.jpeg)
KISS («Keep it simple, stupid» )
Это не паттерн, не анти-паттерн и даже не рок группа из семидесятых, в данном случае, это один из самых популярных принципов или подходов к программированию чего-либо.
По сути, этот принцип требует, чтобы твой код был как можно проще, ведь нагромождение ненужных функций, дублирующих друг друга, и привычка чесать левое ухо правой рукой — не являются признаком профессионализма программиста.
Чем проще код, тем легче его понять, соответственно тем меньше шанс сжечь стул под человеком, который будет после тебя этот код разгребать.
Стив Макконел как-то сказал: «Пишите код так, как будто поддерживать его будет склонный к насилию психопат, который знает, где вы живете».
Поэтому лучше и вправду не усложнять вещи, которые этого не требуют.
![](https://habrastorage.org/webt/yo/yd/lr/yoydlrqsel3_yldaek7elzmxhew.jpeg)
DRY («Don’t repeat yourself»)
Принцип «Не повторяй себя» по своей природе очень похож на KISS. Это довольно просто и в то же время имеет широкое значение. Это довольно просто и в то же время имеет широкое значение — поняли шутку?
Копирование-вставка и дублирование фрагментов собственного кода как сколиоз или ухудшение зрения — со временем этим страдают все программисты. В этом нет ничего плохого. Каждому иногда нужно быстро что-то проверить (ожидаемое поведение или что-то еще), чтобы потом определить, стоит ли писать это правильно. Но, безусловно, недопустимо отправлять такой код в производство.
DRY напоминает нам, что каждое повторяющееся поведение в коде может и должно быть извлечено (например, внутри функции) для последующего повторного использования. Наличие двух фрагментов одного и того же кода в вашей кодовой базе — не очень хорошо. Это часто может привести к десинхронизации и другим ошибкам в вашем коде, даже не говоря об увеличении размера программы.
![](https://habrastorage.org/webt/vs/jy/kb/vsjykbwjgvnhh4fzgemh2gbs3me.jpeg)
WET («We enjoy typing»)
Решения WET широко распространены в многоуровневых архитектурах, где разработчику может быть поручено, например, добавить поле комментария в форму в веб-приложении. Текстовая строка «comment» может повторяться в метке, HTML-теге, в имени функции чтения, закрытой переменной, DDL базы данных, запросах и т.д. Подход DRY устраняет эту избыточность за счет использования платформ, которые уменьшают или исключают все эти задачи редактирования, кроме самых важных, оставляя возможность добавления новых переменных в одном месте.
![](https://habrastorage.org/webt/it/es/ql/itesqllsop9wxadjrwhrrudnt1q.jpeg)
YAGNI («You ain’t gonna need it»)
Тебе это не понадобится — это принцип, который может противоречить взглядам некоторых программистов, а также тех, кто добавил дециметры в школьную программу.
Быть готовым к будущему, как правило, хорошо, но не в программировании. Оставлять любой код, предназначенный только для расширения в будущем — так себе затея.
Но если ты по натуре киберплюшкин и от самой мысли оставить только необходимое начинает плавиться стул под твоими булками, то давай разбираться — это плохой подход к программированию или все же клиника по жизни?
Кодерские проекты — это не те вещи, которые имеют четкое окончание. Если автор не откажется от идеи (и не передаст ее кому-то другому), проект, по сути, продолжается. Поэтому всегда есть и будет место для улучшения, будь то концепция, архитектура или даже сам код.
Одно дело — как идеальный код выглядит у тебя в голове — без ошибок и костылей, другое дело — что происходит на самом деле.
Естественно, легкий налет грусти и апатии может постичь кодера промозглым осенним вечером и кодер может решить понаоставлять в программе, так называемые, «точки расширения» (места, предназначенные для легкого учета новых функциональных возможностей), если они не используются разумно или не являются обязательной функцией, то превращаются просто в памятник прокрастинации и добавляют ненужную сложность и увеличивает размер кодовой базы. Если подумать, это даже противоречит ранее обсужденному принципу KISS.
![](https://habrastorage.org/webt/g7/kq/ie/g7kqiesgzwh3djwtsv8dey1gbea.jpeg)
SLAP («Single level of abstraction principle»)
Принцип единого уровня абстракции (SLAP) определяет, как мы должны организовать свой код (функции, чтобы быть конкретным), дабы сохранить его поддерживаемым.
С длинными и сложными функциями трудно жить. Их трудно понять другим разработчикам и их затруднительно тестировать. Если совсем на пальцах, то, как только мы сталкиваемся с такой мерзостью, мы должны немедленно преобразовать ее в несколько небольших функций!
Как говорил Роберт Мартин: «функции должны делать только одну вещь, и они должны делать это хорошо».
Но как именно мы должны организовывать свои функции? По мере того, как ты, мой пушистый друг, будешь приобретать больше опыта в программировании, ты начнешь больше понимать практическую, эстетическую и функциональную составляющую программирования и принцип, называемый SLAP, который призван помочь.
Грубо говоря, твои функции должны делать только одно, или другими SLAP-словами, должны иметь только один уровень абстракции.
По сути, функция, которая, например, читает пользовательский ввод, не должна также его и обрабатывать. Вместо этого, нужно будет использовать отдельную функцию, которая находится на другом, более низком уровне абстракции. Чем более общая функция и чем больше других функций она использует, тем выше она в иерархии абстракций.
![](https://habrastorage.org/webt/jk/fv/gt/jkfvgt6iizid_zauxhkhobqtscy.jpeg)
FOOBAR (“F****d up beyond all recognition”)
Если перефразировать по-русски: «сломано так, что не восстановить».
Это чудесное выражение, пришедшее в IT из милитарного сленга, наряду с иными шедеврами, такими как, например, SNAFU — «Situation Normal — all fucked up»; это что-то вроде: «ситуация вполне естественная, но все оказалось напрасно».
По легенде, C-программисты использовали для переменных имена «foo» и «bar» в качестве, так называемых, «placeholder» или заполнителей места, особенно в учебных примерах. Так, их светлые головушки освобождались от бремени придумывания новых названий и могли сконцентрироваться на решении задач.
Со временем, это стало традицией и перекочевало из C во многие уже не такие древние языки, поэтому примеры таких имен можно встретить в учебниках повсеместно, а само слово «FooBar», применимое к проекту, означает, что можно начать подыскивать себе что-то другое.
![](https://habrastorage.org/webt/ym/4w/su/ym4wsueeu0ezxixekskwejbjvgi.jpeg)
ASAP («As soon as possible»)
«Так скоро, как только это возможно».
В последнее время стало трендом «As soon as reasonably possible» — «так скоро, как только это возможно, но в разумных пределах».
Вошло в обиход также из армейского сленга аж во время первой мировой. Активно используется по сей день, если данный акроним часто применяется в переписке с вышестоящими, то это может красноречиво указывать на уровень организации в компании или навыков управления и умения приоритизировать у начальства. Но бывают, конечно, и исключения, когда ситуация вышла из под контроля и вообще Foobar.
![](https://habrastorage.org/webt/lf/-9/nd/lf-9ndkzcck88s8b-j3uaand8j8.jpeg)
FYI («For your information»)
Официальное значение — «довожу до вашего сведения», а в вольном переводе: «чтобы ты знал». Встречается в переписке по мейлу повсеместно, особенно когда переписка ведется не лично с тобой, ясным солнышком, но тебя, все-таки, решили поставить в известность.
![](https://habrastorage.org/webt/1w/8o/it/1w8oitd6qlub8tymr6rolzmhov8.jpeg)
TL;DR («Too long; didn’t read»)
Аналог нашего «многабукв, неосилил». Такое можно частенько увидеть под длиннопостами, в которых автор раскрывает свою душу и срывает покровы, но читателю бывает лень вникать в сей опус.
![](https://habrastorage.org/webt/6u/n2/z2/6un2z27ns4r8e6uhizzgwphbtim.jpeg)
DIY («Do it yourself»)
Сделай сам. Происходит от названий небольших строительных лавок, продающих товары для, скорее, починки дома, нежели его постройки. Подразумевалось, что работа — мелочевка и ты можешь сделать это сам, без найма квалифицированного персонала.
Впоследствии, понятие перекочевало в IT и может подходить, к примеру, в ситуациях, когда специалисту нужно сделать работу из смежной области, но она настолько мелкая и тривиальная, что проще сделать ее самому.
![](https://habrastorage.org/webt/yh/y4/l3/yhy4l3fo101rq58c3o-jdaopxog.jpeg)
YOLO («You only live once»)
«Ты живешь только один раз». По аналогии с латинским «carpe diem» («лови момент»)- это призыв к полной жизни, даже к поведению, которое может нести некий риск. Является последним аргументом на границе с неразумным опытом или безудержным весельем, но порой может нести и более разумный посыл: глупо позволять страху верховодить твоими решениями, потому как ты живешь лишь раз.
И помни — YOLO, так что — KISS. Это был Ви. До встречи на канале! Аве!
Oxyd
А самое главное-то и забыли. RTFM!
avecoder Автор
RTFM настолько эпично, что про него отдельно.