Правило 90–10: не тратьте 90% времени на беспокойство об оставшихся 10%.
Другими словами, не тратьте большую часть своих усилий на достижение 100%. Это почему? Две причины.
Первая причина - это Закон убывающей отдачи, который применим не только к разработке программного обеспечения, но и практически ко всему остальному. Возьмем, к примеру, команды разработчиков программного обеспечения. Увеличение размера команды разработчиков с одного разработчика до пяти, вероятно, увеличит продуктивность на 500%. Что будет, если мы продолжим добавлять разработчиков в команду? После определенного момента производительность увеличится лишь незначительно (например, с 7 до 8 разработчиков) или даже начнет снижаться (например, при наличии одной команды из 20 разработчиков).
Вторая причина заключается в том, что если вы слишком сосредоточитесь на одном аспекте разработки программного обеспечения, вы, вероятно, в конечном итоге пренебрежете другими. Например, производительность обычно достигается за счет простоты и / или стоимости. Чем больше тестов вы напишете, тем больше времени займет разработка.
Я приведу вам несколько примеров того, как я применяю правило 90–10.
Выбор правильной технологии
Скажем, например, что каждый в вашей компании имеет большой практический опыт работы с конкретной базой данных. Пришло время начать новый проект. Какую базу данных вы бы выбрали? Та, с которой у всех есть опыт, или более новая, более многофункциональная база данных? Мой первый выбор всегда заключался бы в использовании базы данных, с которой у всех есть опыт, даже если есть другая база данных с большим количеством и лучшими функциями.
Требуются годы реального практического опыта, чтобы овладеть базами данных, фреймворками, языками программирования и т. Д. Вот почему ваши первые несколько проектов, вероятно, были отстойными, а ваши новые намного лучше. Многие архитекторы и менеджеры программного обеспечения не осознают этого, но усилия и затраты на переход с известной технологии на новую чрезвычайно высоки, и в большинстве случаев дополнительные преимущества незначительны.
Код
Должен ли код быть понятным и удобным в обслуживании? Определенно. Должен ли код быть безупречным и в нем больше нет места для улучшений? Не обязательно.
Если ваш текущий код сложно поддерживать, то его улучшение обязательно окупится в будущем. Но если код уже хорош или достаточно прост, реальная выгода, которую вы получите от его улучшения, вероятно, будет очень небольшой, и вы даже можете усугубить ситуацию.
Представление
У вас есть узкое место, и вам нужно улучшить время отклика или производительность? Обычно самые большие улучшения происходят от простейших изменений. Вы можете получить 200% или даже 500% улучшений с помощью простых изменений. После этого для дальнейших улучшений обычно требуются очень сложные изменения, и прирост производительности будет незначительным. Для большинства приложений, вероятно, не имеет смысла тратить месяцы усилий разработчиков, чтобы получить, скажем, еще 10% повышения производительности.
Тестирование
Тестовое покрытие - прекрасный пример применения закона убывающей доходности. После определенного момента, когда у вас будет достаточно большое количество тестов и покрытия, усилия, необходимые для добавления дополнительного покрытия, того не стоят.
Обучение и самосовершенствование
В первые дни моей карьеры мне так хотелось учиться, что я часами просматривал лекции, посещал курсы или читал книги о разработке программного обеспечения. Если вы сделали то же самое, то, возможно, заметили, что через некоторое время становится очень трудно найти полезный контент и действительно узнать что-то новое, просто потребляя чужой контент.
Если ваша цель - учиться, я думаю, что вы узнаете больше всего, запачкав руки и получив реальный опыт. Получив интересную работу, на которой вы осваиваете новые навыки и методы, вы сможете сократить количество читаемых курсов, книг и лекций.
Последние мысли
Я обычно замечаю, что разработчики склонны чрезмерно зацикливаться на качестве кода и лучших практиках (особенно после прочтения чистого кода!), Архитекторы - на производительности, а менеджеры - на показателях и внедрении лучших практик (TDD, Agility, охват тестированием и т. Д.).
Правило 90–10 не имеет ничего общего с посредственностью или поощрением лени. Речь идет о проведении логического анализа затрат и выгод, чтобы вы могли сосредоточиться на том, что действительно важно; это не сделает вас лучшим разработчиком или архитектором программного обеспечения, но поможет найти правильный баланс между всеми различными, а иногда и противоречивыми аспектами разработки программного обеспечения.
