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

в 0:03, , рубрики: it-эмиграция, аббревиатуры, английский язык, заказчик, изучение языков, клиенты, сленг, сленг айтишников, фриланс

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

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

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

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

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

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

KISS («Keep it simple, stupid» )

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

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

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

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

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

DRY («Don’t repeat yourself»)

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

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

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

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

WET («We enjoy typing»)

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

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

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

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

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

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

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

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

SLAP («Single level of abstraction principle»)

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

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

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

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

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

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

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

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

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

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

ASAP («As soon as possible»)

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

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

FYI («For your information»)

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

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

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

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

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

DIY («Do it yourself»)

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

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

YOLO («You only live once»)

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

И помни — YOLO, так что — KISS. Это был Ви. До встречи на канале! Аве!

Автор: avecoder

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js