«Не баг, а фича». 17 непонятных слов из IT-сленга, которые мы всё чаще слышим в обычной жизни
IT-специальности стабильно занимают первые строчки в списке предпочтений сегодняшних абитуриентов, а слова из жаргона программистов все чаще попадаются на глаза. Разберемся, что значат некоторые из них — тем более что встретить их можно в самых разных сферах.
От англ. agile — «гибкий, подвижный». Так называют гибкий подход к разработке программного обеспечения, применяемый как в небольших командах, так и в больших организациях. Аджайл предполагает, что работа над проектом делится на итерации — циклы по две-три недели, по итогам которых получается мини-продукт, готовый к самостоятельному запуску.
Впрочем, термин «аджайл» уже давно применяется для описания рабочих процессов и за рамками IT: этот метод подразумевает высокую скорость создания готовых продуктов и быструю реакцию на изменения и новые обстоятельства в любой сфере. Условно говоря, можно год разрабатывать новую школьную учебную программу и внедрить ее единовременно, а можно в течение года поэтапно вносить изменения и нововведения в существующую программу и смотреть, эффективны ли они, как на них реагируют учителя и школьники, стоит ли придерживаться изначального плана изменений или нужно двигаться в другом направлении.
При аджайле люди важнее процессов, результат важнее документации, гибкость важнее плана.
«Баг» — это программная ошибка, дефект. Дословно английское bug переводится как «жук» или «клоп», а отчет, содержащий информацию об ошибке, называют bug report. Отдельного упоминания стоит фраза «не баг, а фича», означающая, что все работает так, как и было задумано. «Фичей» (от английского feature, «характеристика, свойство») называют дополнительную, специально придуманную (и, возможно, неочевидную) опцию программы. В разговорной речи «багом» можно назвать любой сбой в работе электроники (да и не только).
От англ. front-end и back-end. Эти профессионализмы относятся к «архитектуре» программного обеспечения: фронтендом называют его клиентскую сторону, а бэкендом — внутреннее функционирование. Иначе говоря, фронтенд — это всё, что вы видите на экране девайса, а бэкенд — все, что функционирует где-то там на сервере, на стороне разработчика и продавца услуги.
Профессия бэкенд-разработчиков считается одной из наиболее сложных в сфере IT.
Например, вы делаете новые сайт или приложение. После разработки они проходят довольно долгую процедуру корректировок и тестирования. Когда же их наконец-то «выкатывают», они становятся общедоступными для пользователей. Кроме того, сайт или приложение можно «накатить» (внести изменения, запустить новую версию) и «откатить» — вернуть к предыдущей версии, ликвидировав все внесенные изменения.
От англ. to deploy, «развертывать, приводить в действие». Этим термином называют публикацию рабочей версии приложения, сайта на месте его функционирования. Иными словами, деплой — это процедура переноса сайта на сервер, состоящая из ряда взаимосвязанных действий и являющаяся частью жизненного цикла программы.
Этими словами обозначают грейд (иначе говоря, ранг) в иерархии IT-специалистов (а теперь и наемных работников вообще): система грейдов существует в большинстве крупных корпораций. От грейда зависят компетенции работника и его стоимость на рынке труда.
Джун (от англ. junior, «младший») решает простые задачи под присмотром опытных коллег, мидл (от англ. middle, «средний») разрабатывает более крупные части проекта, но под наблюдением старших, а синьор (от англ. senior, «старший») обладает обширными навыками и отвечает практически за весь процесс, а также за мидлов и джунов.
В IT-сфере коммитом (от англ. to commit, «совершать, связывать себя обязательствами») называют сохранение и фиксацию изменений программного кода в архиве или репозитории — месте для хранения и поддержки каких-либо данных. Соответственно, скоммитить — значит выполнить коммит, сохранить код в репозитории. А коммиттер — специалист, выполняющий коммиты.
Впрочем, в офисах часто можно услышать глагол «закоммититься», не имеющий отношения к программированию. Закоммититься — значит договориться, подтвердить свое участие во встрече. «Мы с ним закоммитились на три часа дня» — совершенно обычное выражение в бизнес-среде.
В программировании костылем называют способ исправления несовершенств хромающего кода без серьезного вмешательства в него.
Это быстрое и не всегда красивое решение проблемы, которое следует впоследствии заменить более долгосрочным и ресурсоемким исправлением.
Фреймворком (от англ. framework, «каркас, структура») называют готовые модели, заготовки или шаблоны для программной платформы, на основе которых пишется собственный код. Этот инструмент разработки состоит из типовых решений с целью упрощения работы программиста.
От англ. stack — «стопка, куча, насыпь». Сейчас в IT-среде стеком называют набор инструментов или список технологий, используемых при работе над проектом. В их число входят языки программирования, системы управления базами данных, фреймворки (шаблоны) и прочее. Стек — это как бы инвентарь программиста в работе над конкретной задачей.
Тимлид — это сокращение от англ. team leader, то есть руководитель команды разработчиков, соединяющий в себе качества опытного программиста и менеджера. Тимлид одновременно обладает как пониманием идейной и технической стороны проекта, так и хорошими управленческими навыками.
Ну а вообще слово «тимлид» так же распространено в бизнес-среде, как «аджайл» или «синьор», — строгой привязки к сфере IT у него нет. Тимлид, то есть менеджер с командой в подчинении, — это должность, а не профессия, поэтому стать им можно в только в результате получения опыта и профессиональной компетенции.
Ещё больше весёлых и полезных карточек о русском языке — в «Грамотности» на «Меле» во «ВКонтакте». Подписывайтесь, чтобы всегда говорить и писать правильно!
Иллюстрация: maybealice / shutterstock / fotodom
Не баг, а фича. Что это значит и откуда появилась эта фраза?
Велик и могуч язык программиста. Иногда этот язык наполнен таким количеством сленговых слов, что его трудно понять не то чтобы простым пользователям, а даже молодым и начинающим программистам. Сегодня мы разберем, что значит довольно популярное выражение: «Это не баг, а это фича» и когда оно применяется.
«Не баг, а фича!»
Это довольно частое выражение, и услышать его можно в диалоге «заказчик-разработчик» или «разработчик-разработчик».
Связано оно с тем, что разрабатываемая программа работает не так, как изначально запланировано. Обо всем по порядку, а пока давайте разбираться, когда используется выражение: «Это не баг, а это фича». А для этого давайте выясним различия между словами «баг» и «фича», и тогда все станет понятно.
Что такое «баг» в программировании?
Это довольно частый вопрос, потому что слово «баг» не всегда связано с программированием. В программировании «баг» — это ошибка в программе или в приложении, которая приводит к тому, что программа или приложение не работают как следует. Само слово «баг» происходит от английского слова «bug». По причине воздействия бага на программу мы получаем продукт, при работе которого происходит нежелательный конечный результат.
Баг имеет широкую градацию по способу собственного возникновения и влияния на конечный продукт. Сегодня мы не будем на этом останавливаться, отметим лишь, что все возникающие баги объединяют следующие свойства:
- баги находят при тестировании или уже в процессе запуска или даже жизни программы;
- в основном они возникают случайно из-за ошибки и невнимательности программистов;
- баги нужно исправлять, чтобы программа работала так, как надо.
Что такое «фича» в программировании?
Фича в программировании — это некая новая функция или особенность программы, которая ранее не была оговорена, но в результате не нарушает функциональность программы, а приносит какое-то дополнение в ее работу. Фича происходит от английского слова «feature». Ее цель — улучшить характеристики программы или просто привлечь внимание пользователей своей необычной функцией.Понятие «фича» существует не только в программировании, оно уже часто употребляется и в обыденной жизни. К примеру, фичами в быту именуют нестандартные функции или дизайн какого-нибудь устройства.
Фича в программировании — это контролируемый результат, который создается специально руками программиста, чтобы улучшить разрабатываемую программу или просто удивить пользователей или заказчика. Фичи часто не нужно исправлять, потому что они очень органично приживаются с самой программой.
Когда употребляется выражение: «Это не баг, а это фича»?
Мы можем предположить, что такое выражение может употребляться в качестве оправдания разработчика перед заказчиком, когда тот обнаружил баг в программе.
У заказчика есть некий образ программы, того, как она должна работать. Поэтому любое отклонение от этого «образа» в глазах заказчика будет багом. Но в то же время программист в процессе своей работы может заметить варианты того, как улучшить функциональность программы. Времени на объяснение и согласование с заказчиком нет, поэтому программист внедряет такое небольшое улучшение самостоятельно.
Естественно, что при тестировании продукта такое «улучшение» будет замечено заказчиком и для него оно будет багом. Вот тут как раз и время парировать разработчику, что это не баг, а фича, и объяснять, почему это так.
Для себя можно обобщить, что, если в программе есть ошибка, которая нарушает ее функциональность, — это баг. А если эта же самая «ошибка» не нарушает функциональности программы, а наоборот, улучшает или придает ей некую «изюминку», то это, скорее всего, фича.
Связано оно с тем, что разрабатываемая программа работает не так, как изначально запланировано. Обо всем по порядку, а пока давайте разбираться, когда используется выражение: «Это не баг, а это фича». А для этого давайте выясним различия между словами «баг» и «фича», и тогда все станет понятно.
Но часто это совсем не так.В чем разница и чему отдать предпочтение?
В этом посте вы узнаете, в чем разница между ошибкой и функцией и какие из них должны быть приоритетными для вашей команды.
Вы также узнаете, почему разработчики предпочитают создавать новые функции, а не исправлять ошибки.
Давайте углубимся.
- В чем разница между ошибкой и функцией?
- Ошибка или фича: чему отдать предпочтение?
- Стоит ли исправлять ВСЕ ошибки?
- Что делать, если ваши разработчики хотят работать над новыми функциями?
- Заключение
В чем разница между ошибкой и функцией?
Основное различие между функцией и ошибкой заключается в том, что функция является преднамеренной, а ошибка — случайной.
Ошибки — это ошибки программирования
В программном обеспечении ошибка — это сбой, который не позволяет продукту работать должным образом. Ошибки обычно возникают из-за человеческой ошибки: недостатка дизайна или ошибки программирования.
Ошибки могут привести к сбою программного обеспечения. Они могут привести к нарушениям безопасности. Они могут помешать клиентам завершить пользовательский поток.
Не все ошибки существенны. Ошибка, из-за которой кнопка разбивается на две строки текста на небольших экранах, неприятна. Но это не влияет на функциональность продукта.
Пример ошибки (фото Маркуса Списке)Функции — это то, что может делать программа
Функции определяют, как работает продукт.
Могут ли пользователи комментировать сообщения друг друга?
Могут ли они использовать Apple Pay?
Могут ли они использовать продукт в автономном режиме?
Это все примеры функций.
Функции созданы специально. Баги случайные. (нажмите, чтобы твитнуть)
Идеи функций могут исходить от самой компании или от самих конечных пользователей. Они собираются, управляются и расставляются по приоритетам в программном обеспечении или электронных таблицах запросов функций.
Слишком большое количество функций может усложнить продукт и саботировать взаимодействие с пользователем. Вот почему хорошие продакт-менеджеры думают о желаемых результатах, прежде чем разрабатывать новые функции.
Могут ли баги быть фичами?
Иногда ошибки могут выглядеть как функции и наоборот. Это может привести к тому, что ошибки станут частью продукта.
Сара и ее команда выпускают последнюю версию продукта XYZ. Они ожидают, что это будет работать определенным образом. Но когда он запускается, что-то работает не так, как должно.
Но клиенты не знают, что это ошибка. На самом деле, они думают, что так и должно было быть. И они это любят. Итак, Сара позволяет этому быть и называет это особенностью.
Если пользователям это не нравится, то ошибка — это просто ошибка. И Сара должна что-то с этим делать.
Ветка Reddit о функциях, которые начинались как ошибки (полная ветка)Ошибка или функция: чему отдать предпочтение?
Еще в 2000 году Джоэл Спольски создал тест Джоэла, список из 12 шагов для лучшего кодирования. Шаг 5 в списке — « исправить ошибки перед написанием нового кода ».
Джоэл заходит так далеко, что говорит, что успешная разработка программного обеспечения зависит в первую очередь от исправления ошибок. Он иллюстрирует с Microsoft.
Менеджеры по продукту!
Получайте подобные полезные статьи на почту раз в месяц. Смотрите прошлые выпуски.
Когда Microsoft отдавала предпочтение функциям продукта, а не исправлениям ошибок, их команды получали катастрофические результаты. Поэтому они изменили свой подход и приняли «методологию нулевых дефектов».
Многие программисты в компании хихикали, так как это звучало так, как будто руководство думало, что они могут уменьшить количество ошибок по распоряжению руководства. На самом деле «ноль дефектов» означало, что в любой момент времени высшим приоритетом является устранение ошибок перед написанием любого нового кода.
Джоэл Спольски в The Joel Test
Приоритизация исправления ошибок также означает, что ваш продукт всегда готов к отправке.
Время выполнения заказов сокращается, а ваша команда становится более гибкой.
Скажем, вам нужно создать функцию в крайнем случае. Поскольку в вашем продукте нет ошибок, вы сможете выпустить новую версию сразу после того, как завершите работу над новой функцией.
Исправление ошибок в качестве вашего первого приоритета имело смысл в 2000 году и по-прежнему имеет смысл сегодня.
Следует ли исправлять
ВСЕ ошибки?Что делать, если рассматриваемую ошибку трудно исправить и она затрагивает не многих людей? Вы можете возразить, что лучше создать функцию, которая поможет сотням пользователей, чем исправлять ошибку, которая беспокоит десяток.
Если вы будете применять эту логику снова и снова, вы получите продукт, полный дефектов. У ваших пользователей будет ужасный опыт, и они уйдут.
Ваш продукт намного лучше с несколькими пуленепробиваемыми функциями, чем с кучей шатких. Они будут хорошо спроектированы, хорошо протестированы и усилены благодаря тщательному исправлению ошибок.
Функции привлекают новых пользователей. Баги отталкивают существующих пользователей. (нажмите, чтобы твитнуть)
Что делать, если ваши разработчики хотят работать над новыми функциями?
Исправление ошибок, когда запросы функций наводняют вашу доску отзывов, разочаровывает. Это жестокая реальность разработки программного обеспечения.
Начинающие продакт-менеджеры часто предполагают, что создание функции — это быстро. Они недооценивают, сколько времени займет поиск и исправление ошибок в функции.
Ваши разработчики, скорее всего, отдадут предпочтение новым функциям, а не исправлениям ошибок. Это потому, что запуск новой функции доставляет разработчикам больше удовольствия, чем поиск ошибок.
Часто можно услышать шутку разработчиков: «Это не ошибка, это фича!»
Но менеджер по продукту должен постоянно следить за тем, чтобы ошибки получали приоритет.
Заключение
Вы хотите создавать программное обеспечение, которое обожают ваши пользователи? Затем расставьте приоритеты над исправлениями ошибок над новыми функциями.
Вы исправили все свои ошибки и хотите знать, какие новые функции добавить? Тогда попробуйте Feature Upvote.
Вы получите доску, на которой ваши клиенты и члены команды смогут добавлять идеи продуктов и голосовать за них. Лучшие предложения поднимаются вверх, давая вашей команде понять, что делать дальше.
История «Это не ошибка, это особенность»
Мы никогда не узнаем, кто сказал это первым, и говорил ли фальшивомонетчик застенчиво или гордо, злобно или лукаво. Как это часто бывает с небрежными замечаниями, перерастающими в максимы, происхождение не баг, а фича туманно. Что мы знаем, так это то, что это выражение было популярно среди программистов в течение долгого времени, по крайней мере, с тех дней, когда Wang и DEC были популярными именами в области вычислительной техники. Файл жаргона , знаменитый словарь хакерского языка, составленный в Стэнфорде в 1975 году, а затем расширенный в Массачусетском технологическом институте, истолковывал эту пословицу следующим образом: на него можно пожаловаться, потому что он есть в руководстве), или даже просто заявив, что он хороший.
Когда изобретатели и инженеры 19-го века начали использовать ошибку как синоним дефект , говорили о механических неисправностях, а механические неисправности всегда плохи. Мысль о том, что жук на самом деле может быть чем-то желанным, никогда бы не пришла в голову Эдисону или Тесле. И только после того, как это слово вошло в словарный запас кодеров, оно стало скользким. Это не ошибка, это особенность — это признание, наполовину смешное, наполовину трагическое, двусмысленности, которая всегда преследовала компьютерное программирование.
В популярном представлении приложения и другие программы представляют собой «алгоритмы», последовательности четких инструкций, которые продвигаются вперед с точностью сержанта-инструктора. Но хотя программное обеспечение может быть логичным, оно редко бывает чистым. Программа — это социальный артефакт. Оно возникает в результате переговоров и компромиссов, являясь продуктом субъективных суждений и меняющихся предположений.
Кто действительно может сказать? В исследовании 2013 года группа ученых из немецкого университета просмотрела записи пяти программных проектов и оценила тысячи зарегистрированных ошибок кодирования. Они обнаружили, что отчеты об ошибках сами по себе содержали серьезные ошибки. «Каждая третья ошибка — не ошибка», — заключили они. Название их статьи никого не удивит: «Это не ошибка, это фича».
INABIAF — инициализм заслужил место в почтенной системе поиска аббревиатур — для программистов не только оправдание, но и крик души. Для остальных из нас поговорка приобрела зловещий оттенок. Не так давно мы нашли программное обеспечение ослепительным, полным волшебства и света.
Оставить комментарий