Сегодня на ежедневном стендапе я произнес очень проникновенную речь перед командой о том, что мы пишем ПО для людей и никого не волнует, насколько красиво будет выглядеть код изнутри, если пользователю будет неудобно с ним работать.
Еще я говорил о том, что нельзя бесконечно шлифовать один и тот же кусок кода, схватив его в середине проекта, что главная ценность продукта — это бизнес-функции, а не код, и что движение вперед невозможно, если вы застревайте на месте и практикуйте перфекционизм.
И, конечно, я сразу вспомнил концепцию достаточно хорошо К.
Итак, вот его главный постулат: мы не стремимся сделать это идеально, мы не пишем как попало, мы делаем достаточно хорошо продукт. Что это значит? Это значит, что мы понимаем, что в любой системе есть ошибки, код и архитектура любой системы несовершенны, а функционал всегда можно дополнить.
Но мы миримся с этим и относимся к этим недостаткам как к неизбежному злу, не позволяя им перешагнуть определенный порог, критичный для такого типа приложений.
В этой статье я затрону понятие «достаточно хорошего» качества продукта, его кода и функционала.
Качество
Мы не страдаем юношеским максимализмом и не тратим бесконечное время, пытаясь свести количество ошибок к нулю.Да, это невозможно (если кто-то захочет, это можно доказать чисто математически).
Мы также понимаем, что в зависимости от назначения системы порог ошибки должен различаться.
Очевидно, что в системе обеспечения жизни пациента в больнице или в программном обеспечении аэродромного диспетчерского пункта имеются ошибки в жизненно важный части бизнес-логики не должны существовать.
Но к разработке и тестированию таких приложений применяется совершенно другой подход и на тестирование выделяется совсем другое время и бюджет. В обычном бизнес-приложении количество ошибок и недоработок может быть довольно большим.
Иногда ужасно большие.
И, тем не менее, система будет вполне успешной, если, конечно, в большинстве стандартных случаев использования не возникнут сбои.
Мы не будем считать такое программное обеспечение идеальным, но будем считать его достаточно хорошо .
Архитектура и код
То же самое относится и к коду.Код может быть не идеальным.
Попытки написать идеальный код всегда заканчиваются раздутым бюджетом.
Известное выражение «лучше потерять день, но потом долететь за пять минут» очень полезно для борьбы с халтурой, «пластилиновая» архитектура и сброс подсознания в коде (об этом я обязательно напишу позже) приобретает в этом контексте совершенно деструктивный смысл.
Мы день за днём оттачиваем своё летное мастерство, но никогда никуда не собираемся летать.
Мы не можем остановиться и сказать: «Всё! Теперь можно летать», потому что всегда есть еще парочка не освоенных до конца приемов полета: бочка, петля Нестерова и прочие (столь же ненужные в гражданской авиации) трюки.
Так что давайте ограничимся достаточно хорошо выполнение.
Никто даже не спорит, что могло быть лучше.
Но этот код также полностью удовлетворяет нашим требованиям по функциональности, он достаточно понятный достаточно хорошо масштабируется и меняет его достаточно Только.
Функциональность
Вы когда-нибудь задумывались, нужна ли «эта классная функция» вашим пользователям? К сожалению, большинство программистов склонны работать по принципу «чем больше, тем лучше».Продукт еще до выхода первой версии приобретает функции, как грибы после дождя.
Для дополнительных «улучшений интерфейса», «добавления возможности делать что-то еще» и создания «гибкой системы, позволяющей пользователям делать все», теряется основная идея, главная изюминка приложения, главный ключ к успеху.
Здесь, конечно, я не говорю о продуктах, главное преимущество которых — возможность пользователю «делать все».
Есть и такие вещи.
Например, один из наших продуктов (не буду конкретизировать, чтобы не быть анонсированным в рекламе ;) основан именно на этом преимуществе.
.
Посмотрите в Твиттере.
Его функциональность минимальна.
Она достаточный чтобы пользователи могли отправлять свои сообщения и читать другие.
Никакой возможности добавлять картинки в сообщения («как же без них», — подумают многие), никакого полноценного социального функционала (только подписаться и ответить), ничего лишнего.
Посмотрите в Гугле.
Он никогда не создавал категорий, которые были у всех поисковых систем того времени, и было сложно представить, как «можно без них».
Чем больше функций вы пытаетесь добавить к продукту, тем больше размываются его основные преимущества.
Поэтому функционал должен быть достаточный для выполнения основной задачи, для которой вы его создали.
Несколько строк в завершение
Итак, хотелось бы отметить очень важный момент: я ни в коем случае не призываю вас перестать внимательно писать и начать «колбасить».Товары, которые прослужат долго, никогда вам этого не простят. Я не сторонник выпуска ПО с огромным количеством ошибок в критических областях.
Я не говорю, что богатый функционал — это плохо.
Я лишь призываю вас избавиться от стереотипа о том, что ваша система должна быть идеальной.
Это фантазия и в погоне за ней можно потерять вполне реальное время, деньги и уникальные шансы выпустить действительно нужный, важный и интересный продукт именно тогда, когда в этом есть необходимость.
Теги: #достаточно хорошее программное обеспечение #достаточно хорошо #перфекционизм #совершенство #Идеальный код
-
Ошибка С Safari 3 Для Windows
19 Oct, 24 -
Yahoo Станет Гигантской Социальной Сетью
19 Oct, 24 -
Технический Анализ Поставок Ibs
19 Oct, 24 -
Huawei E5 Преобразует Сигнал 3G Gsm В Wi-Fi
19 Oct, 24 -
Как Подняться В Небо И Стать Пилотом
19 Oct, 24
