Когда мы должны прекратить работу и сделать инструмент?

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

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

Я «делаю инструменты», когда одно из них верно:

1. Задача меня раздражает
2. Риск человеческой ошибки в задании слишком велик

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

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

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

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

• Инструмент имеет более чем одну цель. Хороший шахматист выполнил за каждый ход две вещи: заблокировать фигуру противника и освободить слона. Новичку, вероятно, понадобится два хода, чтобы сделать это. Кроме того, я считаю, что если инструмент будет выполнять только одно, или с небольшими дополнительными усилиями сделать два, например, помочь исправить некоторые файлы необработанных данных, а также создать искусственные тестовые данные.
• Будущая полезность. Это может сэкономить мне время на работу этой недели, но может ли это сэкономить мне или кому-то время на новом проекте на следующей неделе?
• Это хорошее время, чтобы выучить новый язык, библиотеку, технику дизайна или что-то еще, и у меня есть время, чтобы сделать это. Инструмент является выгодным побочным эффектом от занятий чем-либо, используя время, уже выделенное для обучения.
• Когда у нас возникают серьезные проблемы с получением работы. Как и прыжки с парашютом без парашюта, вам действительно нужно потратить время на то, чтобы сделать или купить парашют. Если вы не можете получить какие-либо значимые экспериментальные результаты или новое веб-приложение не будет работать вообще, вам просто нужно остановиться, сделать или купить инструмент для измерения того, что вы не видите, управлять компонентами или заменить часть система. Когда работа полностью зависает от потребности в инструменте, меня не волнует будущее использование или многократное использование. Необходимость весит достаточно.

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

В данный момент я не делаю полноценный «инструмент», просто небольшой скрипт (обычно bash или python; тоже будет работать perl или даже PHP), который автоматизирует то, что я делал раньше. Это в основном применение принципа СУХОЙ (или принципа «Единого источника истины», который, по сути, одно и то же) - если вам нужно изменить два исходных файла в тандеме, должна быть общая истина, которой они делятся, и что Истина должна быть вынесена и храниться в одном центральном месте. Здорово, если вы можете решить эту проблему внутренне путем рефакторинга, но иногда это неосуществимо, и именно здесь появляются пользовательские сценарии.

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

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

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

И тогда есть риск сделать это слишком поздно: легко преобразовать три совершенно новых класса объектов данных в форму и написать скрипт, который генерирует для них веб-формы, и как только вы это сделаете, легко добавить еще 27 классов, которые также работать с вашим сценарием. Но написать сценарий практически невозможно, когда вы достигли точки, в которой есть 30 классов объектов данных, каждый с рукописными веб-формами и без какой-либо согласованности между ними (так называемый «органический рост»). Сохранение этих 30 классов с их формами - это кошмар повторяющегося кодирования и полуручного поиска-замены, изменение общих аспектов занимает в тридцать раз больше времени, чем нужно, но написание сценария для решения проблемы, который был бы легким перерывом на обед, когда проект начался, теперь это ужасный двухнедельный проект с ужасающей перспективой на месячные последствия, состоящий из исправления ошибок, обучения пользователей и, возможно, даже отказа от и возвращения к старая кодовая база. По иронии судьбы, написание беспорядка из 30 классов заняло гораздо больше времени, чем чистое решение, потому что вы могли все это время использовать удобный сценарий. По моему опыту, автоматизация повторяющейся работы слишком поздно является одной из основных проблем в длительных крупных программных проектах. потому что ты мог все это время ездить на удобном сценарии. По моему опыту, автоматизация повторяющейся работы слишком поздно является одной из основных проблем в длительных крупных программных проектах. потому что ты мог все это время ездить на удобном сценарии. По моему опыту, автоматизация повторяющейся работы слишком поздно является одной из основных проблем в длительных крупных программных проектах.

Я только что вспомнил это:

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

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

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

Я не забываю посещать обзоры кода, где ошибки заголовка привели бы к планированию другого обзора. Многие из них могли быть обнаружены инструментом. например, неправильный подсчет sloc, отсутствующее требование, ошибки форматирования. Мой инструмент, написанный на Perl, сгенерировал заголовок из предоставленного кода и подтвердил требования из базы данных Oracle. Это не было частью нашего «Процесса», поэтому в краткосрочной перспективе создание инструмента рассматривалось как задержка доставки.

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

Все остальные ответы хороши, но я бы добавил еще одну причину, по которой стоит тратить время на создание небольших инструментов (и настройку ваших .vimrc, .emacs и т. Д.):

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

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

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

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

Я использую 2 обоснования, чтобы поддержать это.

• Это расширение принципа СУХОЙ. Если мы хотим что-то повторить, ручные усилия - это наименее эффективное использование человеческих ресурсов.
• Это эффективный способ записать то, что я сделал, поэтому, если я что-то построил, то я (или кто-то еще), возможно, захочу вернуться к тому, как я это сделал, спустя недели или месяцы, и он будет вести журнал работы с проектом.

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