Как решить, когда писать что-то, а не делать это вручную?
Иногда я чувствую, что мне нужно сделать что-то автоматизированное или ручное. Например, я просто запустил определенный скрипт 8 раз, делая небольшие изменения между каждым запуском. Я, конечно, мог бы написать скрипт, который бы автоматизировал это, но в этом случае я решил, что быстрее запускать его вручную каждый раз.
Но иногда я понимаю, что после того, как я потратил кучу времени на ручные работы, мне лучше было бы автоматизировать это.
Какие-нибудь предложения по эмпирическим правилам, которые помогут мне до начала какого-то повторного процесса решить, стоит ли тратить время на написание сценария для его автоматизации?
Для пояснения: я говорю о вещах типа sysadmin, таких как перемещение файлов, переименование и т. Д., И о вещах типа DBA, таких как запуск сценария SQL для импорта определенных данных (это то, что я делал сегодня). Обратите внимание, что я разработчик, а не системный администратор или администратор.
11 ответов
Причины, по которым у меня есть сценарии, включают
Когда:
ты делаешь это во второй раз
это становится больше чем один шаг
легко ошибиться
легко забыть как сделать это вручную
Я фанат правила " Три удара и ты автоматизируй", как описано по этой ссылке.
Не просто подумайте об экономии времени, которую вы можете или не можете увидеть в процессе автоматизации. Также учитывайте вероятность того, что запуск процесса вручную может привести к ошибкам.
Если все сделано правильно, автоматизированный процесс должен минимизировать вероятность ошибки. Это может привести к автоматизации, даже если это не приведет к экономии времени.
Конечно, обратная сторона: если процесс запускается автоматически, обязательно следите за ним, чтобы убедиться, что он не вышел из строя.
Помимо очевидного, одной из причин написания сценария является то, что сам процесс написания сценария более увлекателен, чем выполнение задания даже один раз - и вы можете чему-то научиться в процессе.
Для многих гиков, делать что-то умное, веселое и интересное перевешивает любую другую выгоду; поэтому в этом случае автоматизация задачи вполне может соответствовать этим критериям, даже если это занимает больше времени, чем выполнение задач вручную!
Если есть один трюизм системного администрирования, то это так: никакая простая задача системного администратора не может быть более двух раз интересной. Если вы выполняете простую скучную задачу более двух раз, автоматизируйте ее.
- http://www.ibm.com/developerworks/linux/library/l-punix.html
Это сайт для разработчиков.
Если вы думаете, что вам может понадобиться сделать то же самое снова, то автоматизируйте это прямо сейчас. Но не забывайте о таких законах, как YAGNI (вам это не нужно), и не тратьте слишком много времени на автоматизацию. Просто получите что-то, что работает для вас сейчас с небольшим уговором.
В следующий раз сделайте рефакторинг и улучшите его, но только немного. Помни ЯГНИ.
В третий раз попробуйте получить его в симпатичном небольшом пакете, где вы можете дать ему некоторые входные данные, и он будет работать до конца, делать разумные вещи в условиях ошибки и регистрировать ошибки.
И, надеюсь, вы используете не сценарии оболочки, а настоящий язык сценариев, такой как Python, где вы можете настраивать код и улучшать его при каждом использовании, пока он не станет полноценной средой автоматизации, способной удаленно работать и управлять тысячами серверов. от одного вызова.
Мое эмпирическое правило:
- если вам скучно, потратьте немного времени на размышления о том, как вы могли бы это автоматизировать, сколько работы и сколько труда это может спасти.
- Если автоматизировать очень просто или, очевидно, сэкономить много работы, начните автоматизировать прямо сейчас
- Если вы решили не автоматизировать, а делать это вручную становится утомительно, или если вы решили автоматизировать, но столкнулись с трудностями, подумайте еще раз, на этот раз дольше.
Автоматизация уменьшает источник ошибок, если это всегда тот же набор операций, который вы выполняете многократно.
Когда я начал работать с одним из моих проектов (asp.net) пару лет назад, у меня был процесс ручного выпуска, который охватывал 3 письменные страницы. Шаг за шагом я перенес эту работу в пакетный файл сборки (с параметрами командной строки и т. Д., Чтобы выбрать отдельные операции или все).
Как только сценарий был выполнен, он работал безупречно и сэкономил мне час ручной работы для каждого запуска.
А иногда это просто удовольствие от написания сценария;)
Мое правило простое: в конечном итоге, я сэкономлю время, делая это вручную или написание сценария.
Если вам нужно выполнить определенное задание только несколько раз, а потом уже никогда, возможно, не стоит писать сценарий. Но если вам нужно будет выполнить задачу несколько раз с небольшими изменениями, сценарии сэкономят ваше время.
Мое правило таково: создавайте сценарий, когда он становится чем-то, о чем вам больше не нужно думать. Если вы все еще делаете это осознанно, все еще изучаете что-то о процессе или все еще особенно заинтересованы в результатах, не пишите сценарий. Но если это стало чем-то, что вам просто нужно сделать, чтобы что-то сделать, и делать это - рутина, черт побери.
Хорошие программисты, как правило, ленивы, потому что они пытаются делать вещи с наименьшими затратами сил и времени. Так что, если это сэкономит время, оно может стоить того.