Issue что это в программировании

Вы отправили слишком много запросов, поэтому ваш компьютер был заблокирован.

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

Issues 2.0: Новое поколение

Система управления проектом: последний рубеж. Почти два года назад в этот день, GitHub запустил трекер задач (issue tracker). Некоторые люди его полюбили, некоторые люди возненавидели его, — но давайте не будем обращать внимание на прошлое (мы живем в будущем, так как наше настоящее в прошлом). Давайте поговорим о версии Issues, которые запускаются сегодня.

Анатомия задачи

Начнем с того, что из себя представляет Задача (Issue). Вот скриншот задачи на GitHub

Назначение ответственных, добавление этапов и прикрепление ярлыков

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

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

События

Всякий раз, когда открывается или закрывается какая-либо задача, мы покажем вам это.

Навигация по задачам

Issues 2.0 запущены с простым, отзывчивым и гибким интерфейсом навигации по задачам.

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

Допускается массовое редактирование на текущей странице: закрытие, открытие, добавление ярлыков, назначение ответственных и добавление в этапы проекта.

Поиск

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

Если быстрый поиск ничего не находит, вы можете перейти к странице полного поиска.

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

Коммиты + Задания

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

И, конечно же, вы можете закрыть задачу с сообщением коммита.

• fixes #xxx
• fixed #xxx
• fix #xxx
• closes #xxx
• close #xxx
• closed #xxx

Электронная почта + Задачи

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

Клавиатура + Задачи

Любите использовать клавиатуру для навигации по веб-страницам? Задачи имеют великолепную поддержку клавиатуры:

PJAX: Следующее поколение частичной загрузки страницы

Каждая ссылка в Issues 2.0 будет работать так как вы ожидаете от любой ссылки в интернете (открытие в новой вкладке, копирование и вставка URL), — но вы все равно получите безумно отзывчивый интерфейс (напоминает интерфейс старой школы AJAX). Это стало возможным благодаря PJAX — тому, что мы используем больше и больше на нашем сайте.

Вы получите преимущества PJAX только если вы используете Firefox 4 или Chrome — я настоятельно рекомендую обновиться.

• Homebrew’s Issues
• Most commented issues labeled feature and 1.x in bundler
• paperclip’s issues discussing s3

В чем разница между issue и bug в тестировании?

На работе разработчики не раз мне говорят «это не bug, а issue» , я им утверждаю, что баг — это несоответствие. Если есть маленькая опечатка в тексте — это все равно баг, если программа выглядит не так, как должна выглядеть по спецификации, это баг. Мало того, любое несоответствие записывается в багтрекерной системе как баг.

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

• Вопрос задан более трёх лет назад
• 7459 просмотров

3 комментария

Оценить 3 комментария

Называйте оба варианта фичей и будет вам счастье)))

«это не bug, а issue» например, в тз написано, что программа должны в портретной ориентации быть, а разработчик сделал и в портретной и горизонтальной,
тогда это вообще фича!

Cherry @ValentynaV Автор вопроса

Дмитрий Земсков: баг — это несоответствие актуального поведения программы с ожидающим. (это каждый тестировщик знает). В тз приписано, что ориентация должна быть такой-то, а получаем другое, вот и несоответствие. А вы тестировщик?

Решения вопроса 0
Ответы на вопрос 5

Программист

Баг — это когда вместо скидки к цене делается надбавка. А ишью — это когда у цены со скидкой слишком много цифр после запятой и она не влазит в отведенный ей контрол.

Ответ написан более трёх лет назад
Нравится 4 1 комментарий

А если цена со скидкой и слишком большим количеством цифр выравнивается по центру контейнера с overflow:hidden фиксированной длины и из-за этого пользователь не может увидеть итоговую цену?

Issue — это боль пользователя, которую он описал.
Например, пользователь забыл пароль, а система восстановления пароля не работает.
Пользователь заводит Issue, т. е. проблему, которую QA должен воспроизвести и перевести в задачу для разработчиков.

Bug — это дефект, который был обнаружен QA в процессе тестирования.

Ещё раз.
Баг — такого слова нет, есть дефект.
Любое несоответствие между работающей системой и ТЗ — это дефект.

Issue — это проблема конечного пользователя.

Ответ написан более трёх лет назад
Нравится 1 4 комментария
Cherry @ValentynaV Автор вопроса

Спасибо за ответ!! Нашла еще такое:

Bug — Any problem in existing functionality, or missing functionality. Defect in code or requirement, error which is not designed to be.

Issue (Impediment) — Any problem which might block the development process, example : a third party driver you identified as dependency is not releasing on time, so it is an issue in your development process.

Task — Any work which is planned as part of development of your project, either as result of bug, or issue or requirements, including requirement analysis or development, or testing. etc.

Cherry @ValentynaV Автор вопроса
Cherry @ValentynaV Автор вопроса

С прочитанной статьи я поняла, что ишью это когда нет проблем в коде. Например, заказчик хотел портретную ориентацию, разработчик сделал и портретную и горизонтальную, но все же работает.
Даже не знаю, какой документ взять за пример «моим» разработчикам. А то все называют ишью, в том числе неправильно написанный текст (хотя в minor bug и включают грамматические ошибки)

D’ @Denormalization

Cherry: есть проблема в понимании слова «bug» между разработчиками и QA.
Для разработчика «bug» — это что-то из разряда «всёпиздецконецсвета». Всё остальное это не баг, а фича.

xmoonlight @xmoonlight
https://sitecoder.blogspot.com

Bug — это невыполнение требований ТЗ или несоответствие реальных данных ожидаемым при тестировании продукта тест-кейсом.
Issue — это проблемы, выявленные тестером на любом этапе тестирования, не являющихся отклонениями для ожидаемых результатов во всех предыдущих тест-кейсах.
Производится принятие решение рабочей проектной группой: закрыть, нивелировать до низшего приоритета (оставить на потом), или превратить в Bug.
Всё остальное — это не баг.

Ответ написан более трёх лет назад
Cherry @ValentynaV Автор вопроса

Не соглашусь. Во-первых, далеко не всегда заказчик дает ТЗ. Во-вторых, заказчик не может знать все нюансы удобства пользования (если неправильно ввести что-то в поле или ничего не заполнить и кликнуть «ок» кнопку, выдается сообщение об ошибке). В-третьих, есть гайдлайны. А вы тестировщик? Так как меня интересует мнение опытных тестировщиков (но всеравно спасибо, что обратили внимание на мой вопрос). Я проходила курсы Портнова, человека, который создал школу тестировщиков в Америке, и как-то странно, когда мне разработчики говорят, это не баг. Есть баг удобства (в том числе, если при заполнении поля имейл не вылезает соответствующая клавиатура девайса), часто это записывается с приоритетом «minor», но все же, это баг.

xmoonlight @xmoonlight

Cherry: Валентина, еще раз давайте разберём на простом примере.
Вы заказали обычный чёрный фонарь с инструкцией (это Ваши требования или ТЗ).
Вам привезли товар и по факту вы получаете:
1. Фонарь светит красным — это баг.
2. Цвет корпуса фонаря зелёный (вместо ожидаемого чёрного) — это тоже баг.
3. Инструкция на жёлтой бумаге, вместо белой — это не баг.
Согласны?

Cherry @ValentynaV Автор вопроса

xmoonlight: для меня да, баг удобства) так как покупатель ожидает, что инструкция будет на белой бумаге, как всегда, а желтая вызывает подозрение о качестве продукции.
Так вы тестировщик?

Введение в GitHub от разработчика

Перевод статьи Флавио Копеса «A developer’s introduction to GitHub».

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

Короче говоря, это платформа для разработчиков ПО и построена она на основе Git.

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

Почему GitHub?

Поскольку вы уже знаете, что такое GitHub, вам может быть интересно, зачем вам лично им пользоваться.

Ведь этим проектом, в конечном итоге, рулит частная компания (статья написана до того, как этой частной компанией стал Microsoft, — прим. перев.), получающая доход от размещения чужого кода. Так есть ли причины использовать именно его, а не похожие платформы, например BitBucket или GitLab?

Кроме личных предпочтений и резонов технического плана, есть веский довод в пользу использования GitHub: им пользуются все, а значит, сетевой эффект огромен.

Большинство кодовых баз со временем перешли с других систем контроля версий на Git из-за его удобства. А GitHub, так уж исторически сложилось, вложил много сил в удовлетворение нужд open source-сообщества.

Поэтому сегодня, какую бы библиотеку вы ни искали, чаще всего вы найдете ее на GitHub.

Кроме open source-проектов многие разработчики размещают на GitHub приватные репозитории. Они делают это из-за удобства платформы.

Рассмотрим важные вещи, касающиеся GitHub, которые нужно знать разработчику.

GitHub Issues

GitHub issues это один из популярнейших баг-трекеров (систем отслеживания багов) в мире.

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

Если вы откроете issue (вопрос по проблеме) в чьем-то проекте, то он останется открытым, пока вы сами его не закроете (например, если вам удалось разобраться с этой проблемой), или пока собственник репозитория его не закроет.

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

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

Social coding (социальное программирование)

Несколько лет назад логотип GitHub содержал пометку «social coding». Что это означало и действует ли это до сих пор? Определенно действует.

Подписка

На GitHub вы можете подписаться на определенного разработчика или репозиторий. Для этого нужно пройти в профайл пользователя и кликнуть «follow» или нажать кнопку «watch» на репозитории.

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

Звезды

Одно из важных свойств GitHub это возможность дать звезду репозиторию. Это действие помещает его в список репозиториев, которые вы отметили звездами («starred repositories»). Благодаря этому вы можете отслеживать проекты, которыми заинтересовались, и находить похожие проекты.

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

Крупные проекты могут набирать десятки тысяч звезд.

На GitHub также есть страница с трендами, куда попадают репозитории, получившие больше всего звезд за ограниченное количество времени (например, сегодня, на этой неделе, в этом месяце).

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

Fork (ответвление)

Последний заметный сетевой показатель проекта это количество ответвлений (форков).

Это ключ к работе GitHub, поскольку форк это основа пул-реквеста (Pull Request, PR) – предложения внесения изменений. Любой человек может сделать форк вашего репозитория, внести какие-то изменения, а затем создать пул-реквест, чтобы попросить вас смерджить, слить воедино эти изменения.

Иногда человек, сделавший форк, может так никогда и не попросить вас мерджить что-нибудь. Он может сделать форк просто потому что ему понравился ваш код и он решил добавить что-нибудь поверх него. Ему не нужно, чтобы эти изменения коснулись оригинального репозитория. Также пользователь мог исправить баги, с которыми столкнулся и которые проявились только у него.

Популярный значит лучший

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

Пул-реквесты (Pull requests)

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

В проекте могут быть сотни PR. Обычно, чем популярнее проект, тем больше пул-реквестов в нем будет. Вот пример React:

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

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

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

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

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

Управление проектами (менеджмент проектов)

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

Например, Projects (Проекты). Это новинка в экосистеме и довольно редко используется, но это доска Kanban, которая помогает упорядочивать возникшие проблемы и необходимые работы.

Wiki представляет собой документацию для пользователей. Один из самых впечатляющих вариантов использования Wiki, которые мне доводилось видеть, это Go Programming Language GitHub Wiki – справка по языку Go.

Еще одним вспомогательным инструментом для менеджмента проектов является система отметок этапов (milestones). Это часть раздела issues. Вы можете привязать вашу проблему к определенной метке (например, номеру релиза), что сужает круг поисков.

Раз уж речь зашла о релизах, GitHub усовершенствовал функционал тегов Git, введя релизы (releases).

Тег Git это указатель на определенный коммит. Если все сделано последовательно, то это помогает вам откатиться на предыдущую версию вашего кода, не ссылаясь на конкретные коммиты.

Релиз GitHub основывается на тегах Git и представляет собой полный релиз вашего кода, вместе с Zip-файлами, примечаниями и бинарными цифровыми объектами, которые могут представлять полностью рабочую версию конечного продукта вашего кода.

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

Сравнение коммитов

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

GitHub дает вам возможность делать это с помощью compare view (просмотра изменений). Просто добавьте /compare в конце адреса, после названия репозитория.

В этом примере я сравнил React v15.x с v16.0.0-rc, последней версией на момент написания этой статьи, чтобы посмотреть, что изменилось:

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

Вебхуки и сервисы

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

Вебхуки (Webhooks)

Вебхуки позволяют пинговать внешние сервисы, когда в репозитории происходят определенные события, например, когда пушится код, делается форк или создается/удаляется тег.

Когда происходит событие, GitHub отсылает запрос POST на указанный нами URL.

Распространенным вариантом использования этой функции является пингование удаленного сервера для доставки последнего кода с GitHub, когда мы пушим обновление с нашего локального компьютера.

Мы делаем пуш на GitHub, GitHub сообщает об этом серверу, а сервер забирает его с GitHub.

Сервисы

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

Например, вы можете настроить test runner, чтобы тесты запускались автоматически каждый раз, как вы запушите какие-то новые коммиты (используется TravisCI).

Вы можете настроить непрерывную интеграцию с использованием CircleCI.

Можно создать интеграцию Codeclimate для анализа кода и предоставления отчетов о «техническом долге» и покрытии тестами.

Выводы

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