Который лучше: поставка ошибочной функции или не поставка функции вообще?

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

Что относительно того, чтобы иметь "закрытую бету" с "4 или 5 пользователями", которые предложили функцию во-первых?

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

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

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

Это сводится к очень реальному выбору путей: ошибка - что-то, что не работает правильно, который не был частью намеченного поведения и дизайна? Или действительно ли это - ошибка только если, если не работает в соответствии с намеченным поведением?

Я - твердый сторонник последнего; ошибки являются вещами, которые не прокладывают себе путь, они были предназначены для работы. Реализация должна получить дизайн, который должен получить бизнес-потребность. Если реализация используется для обращения к другой бизнес-потребности, которая не была покрыта дизайном, это - дизайн, который виновным, не реализация; таким образом это не ошибка.

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

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

Если спрос для функции NOW, а не функции, которая работает. Вам, вероятно, придется поставляться.

В этой ситуации, хотя:

• Удостоверьтесь, что Вы документируете ошибку (ошибки) и последствия (и пользователю и другим разработчикам).
• Обязательно добавьте ошибку (ошибки) к Вашей базе данных отслеживания ошибок.
• Если Вы пишете модульные тесты (Я надеюсь, что так), удостоверьтесь, что тесты записаны, которые выделяют ошибки перед поставкой. Это будет означать, что, когда Вы приезжаете для исправления ошибок в будущем, Вы знаете, где и каковы они, не имея необходимость помнить.
• Запланируйте работу для исправления ошибок как можно скорее. Вы действительно исправляете ошибки прежде, чем написать новый код, не так ли?

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

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

Если ошибки могут вызвать BSODs, затем очень осторожны относительно того, в кого Вы поставляете его.

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

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

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

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

Поставлйтесь рано, часто поставлйтесь, постоянный рефакторинг.

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

Неспособность разрешить wonkiness является знаком проблем в Вашей кодовой базе. Проведите больше времени, осуществляя рефакторинг, чем добавление опций.

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

Перфекционисты могут ответить, "не делают этого".

Деловые люди могут ответить, "делают это".

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

Есть ли какой-либо способ, которым можно получить бета-версию 4-5 людям, которые запросили функцию? Затем после того как Вы получаете их обратную связь, это может быть ясно который решение сделать.

Точно зарегистрируйте wonkiness и поставьте его.
Удостоверьтесь, что пользователь, вероятно, будет видеть и понимать Вашу документацию wonkiness.

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

Просто, потому что Вы не можете зафиксировать его теперь, не означает, что Вы не сможете в будущем. Вещи изменение.

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

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

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

Я предполагаю, что это зависит от Ваших стандартов. Для меня содержащий ошибки код не является готовым производством и так не должен быть поставлен. У Вас могла быть бета-версия с известным списком проблем, таким образом, пользователи знают, что ожидать при определенных условиях? Они извлекают пользу из использования новых функций, но также и знают, что это не прекрасно (используйте тот их собственный риск). Это может сохранить те 4 или 5 клиентов, которые запросили функцию, счастливую некоторое время, который дает Вам больше времени для исправления ошибок (если возможный) и выпуск к производству позже для масс.

Просто некоторые мысли в зависимости от Вашей ситуации.