Выпускать много ошибочных функций быстро ... или несколько действительно стабильных? - PullRequest
1 голос
/ 07 июля 2010

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

Ответы [ 7 ]

5 голосов
/ 07 июля 2010

Возможно, золотая середина может быть более подходящей.Ваш «бренд» сильно пострадает, если:

  • программное обеспечение, которое вы выпускаете, представляет собой кучу навоза (как в ваших предыдущих случаях);или
  • программное обеспечение не выпущено своевременно (как в вашем последнем случае).

В обоих случаях вы вряд ли останетесь в бизнесе дляlong.

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

Обслуживание программного обеспечения (в основном исправление ошибок и ответы на вопросы клиентов) являетсяважная часть нашего процесса разработки.

Кроме того, «стоимость» исправления ошибки возрастает по мере того, как обнаружение упомянутой ошибки перемещается от разработчика к клиенту.

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

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

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

3 голосов
/ 07 июля 2010

Это скорее зависит от желания руководства, чем от желания клиентов.Если у вас есть выбор: «у вас это может работать, или у вас это может быть в пятницу», средний любящий целевой и целевой менеджер предпочтет сделать это в пятницу.

Если у вас действительно есть выбор, пожалуйста, оставьтеэто пока не работает.Вы сэкономите себе и другим время и хлопоты.

Time(do it right) < Time(do it again) + Time(correct database) + Time(explain and apologise)

(Основной закон разработки программного обеспечения.)

3 голосов
/ 07 июля 2010

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

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

Если оно еще не готово, не выпускайте его.

2 голосов
/ 07 июля 2010
  • Вы должны тестировать и проверять код во время разработки, прежде чем функция будет завершена.
  • Перед тем, как перейти к производству, вы должны проверить работоспособность всей функции.
  • Вам следует часто выпускать небольшое количество функций, чтобы вы могли получать отзывы о них. Даже если эта функция работает отлично, она может не соответствовать желаемому пользователю, или вы обнаружите, что что-то можно улучшить, если эта функция используется на практике.
1 голос
/ 07 июля 2010

Это зависит от уровня боли и ожиданий ваших клиентов, а также от того, насколько хорошо ваши сотрудники, работающие с клиентами, могут управлять, к сожалению, «обратной связью».

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

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

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

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

0 голосов
/ 07 июля 2010

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

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

Одна сноска, однако, заключается в том, что вы должны знать, когда достаточно. Каждый программист может потратить целую вечность на каждую строчку кода, говоря: «Ну, если я перенесу это сюда, я смогу получить ускорение на 0,001%» или что-нибудь в том же духе. Поверьте, у меня тоже есть эта проблема, и я склонен к одержимости. Умение говорить что-то «достаточно хорошо» трудно усвоить, но, на мой взгляд, оно абсолютно необходимо.

0 голосов
/ 07 июля 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...