Записки IT специалиста

​​Самодеятельность, художественная и не очень

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

Как будто это что-то плохое, скажет иной читатель. Ну да как посмотреть, с какой точки зрения.

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

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

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

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

Далее сами скрипты. Очень многие скриптовые языки позволяют писать двумя способами: быстро, рационально, но нечитаемо или долго, неоптимально, но читаемо. Надо ли говорить, что чаще всего превалирует первый подход, особенно среди админов-«староверов», которые не используют современные среды разработки с синтаксис-помощниками и автодополнением, а ваяют скрипты буквально на коленках.

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

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

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

Причем наступить на эти грабли можно совершенно случайно. Для этого не нужно даже попадать под автобус. Достаточно уехать в отпуск и оказаться на некоторое время без связи.

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

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

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

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

Ну а мораль сей басни проста: если есть стандартные и общепринятые решения – то следует их использовать, даже если вы можете за пять минут левым задним копытом набросать скрипт «в 1000 раз лучше».

Ну или пишите и выкладывайте его на GitHub и когда его начнут включать в дистрибутивы и использовать массы – тогда можно будет использовать его как стандартное решение.

www.tgoop.com/interface31/4311

2.4K viewsMay 30 at 12:20

​​Самодеятельность, художественная и не очень

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

Как будто это что-то плохое, скажет иной читатель. Ну да как посмотреть, с какой точки зрения.

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

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

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

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

Далее сами скрипты. Очень многие скриптовые языки позволяют писать двумя способами: быстро, рационально, но нечитаемо или долго, неоптимально, но читаемо. Надо ли говорить, что чаще всего превалирует первый подход, особенно среди админов-«староверов», которые не используют современные среды разработки с синтаксис-помощниками и автодополнением, а ваяют скрипты буквально на коленках.

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

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

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

Причем наступить на эти грабли можно совершенно случайно. Для этого не нужно даже попадать под автобус. Достаточно уехать в отпуск и оказаться на некоторое время без связи.

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

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

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

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

Ну а мораль сей басни проста: если есть стандартные и общепринятые решения – то следует их использовать, даже если вы можете за пять минут левым задним копытом набросать скрипт «в 1000 раз лучше».

Ну или пишите и выкладывайте его на GitHub и когда его начнут включать в дистрибутивы и использовать массы – тогда можно будет использовать его как стандартное решение.

BY Записки IT специалиста