Можно ли использовать язык, который не поддерживается вашей компанией для некоторых задач?

Я работаю в компании, которая поддерживает несколько языков: COBOL, VB6, C # и Java.
Я использую эти языки для своей основной работы, но я часто нахожу себя для программирования некоторых второстепенных программ (например, скриптов) на Python, потому что я считаю, что это лучший инструмент для задач такого типа.

Например: аналитик дает мне сложный CSV-файл для заполнения некоторых таблиц БД, поэтому я бы использовал Python для его анализа и создания сценария БД.

В чем проблема?
Основная проблема, которую я вижу, состоит в том, что несколько частей этих быстрых и грязных скриптов постепенно приобретают важность и:

1. Моя компания не поддерживает Python
2. Они не контролируются версией (я поддерживаю их другим способом)
3. Мои коллеги не знают Python

Аналитики даже начали ссылаться на них по электронной почте («запустите скрипт, который экспортирует ...»), поэтому они нужны чаще, чем я изначально думал.

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

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

Это общий сценарий? Я делаю что-то неправильно? Что мне делать?

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

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

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

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

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

После этого вам просто нужно посмотреть, как другие люди реагируют на это.

Я столкнулся с аналогичными проблемами, где я работаю. Я слышал "Что такое PHP?" несколько лет назад. Они не понимают или не хотят изучать что-либо за пределами стека MS. Если python является подходящим инструментом для работы, я просто расскажу об этом своим руководителям и буду готов к множеству сравнений и объяснений того, почему python был правильным выбором. Это будет неприятно, но я думаю, что большинство согласится с тем, что python - хороший выбор для манипулирования текстом.

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

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

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

Я думаю, что это, вероятно, хороший случай

Проще просить прощения, чем получать разрешение.

Звучит так, будто вы выполнили свою работу, но теперь вам придется столкнуться с последствиями.

Мое правило:

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

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

У вас есть два варианта:

1. Сделай это стандартом
2. Перевести на стандартный инструмент

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

Второй вариант поможет вам установить навыки, и вы сможете найти стороннего разработчика (и, вероятно, с открытым исходным кодом с коммерчески дружественными лицензиями) для выполнения некоторой тяжелой работы. Например, поиск "LINQ to CSV" должен получить полезные хиты.

Кстати, инструменты разработчика VB6 (IDE, компилятор) не поддерживаются (даже исправления безопасности), так что, скорее всего, стандарт все равно нужно обновить. (Среда выполнения VB6 поддерживается как часть (и включена в установку) текущих версий Windows). Возможно, это можно использовать в качестве помощника для подхода # 1: стандартный набор инструментов должен поднять движущуюся цель из-за зависимостей от поставщика.

Если вам дано задание, и вы найдете единственный способ выполнить его вовремя, у вас действительно не будет выбора. Я думаю, что было бы разумно, чтобы ответственные лица знали, что вы делаете. Вы не должны выходить за рамки обязательного контроля исходного кода (если он просто абсолютно не работает вообще?) Тестирования и документации.

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

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

У вас есть скрипт Bash, который вызывает скрипт Python, который вызывает скрипт Perl, который вызывает двоичный файл Java, который вызывает C dll ...

Затем что-то попадает в вентилятор во всем конвейере, и вы проходите через - ЧТО ТАКОЕ КОДЕЗ? Особенно в Perl ... И отладка простой, скажем, проблемы кодирования превращается в кошмарный беспорядок. Вы не можете эффективно отлаживать 5 из 7 языков, и это превращается в настоящую боль.

Или вы должны добавить простое изменение, но вы создаете 10 ошибок, потому что в Perl есть ошибки, в Java есть ошибки и т. Д.

И эта цепочка языков 7+ начинается по одному шагу за раз.

Действуй осторожно, будь драконами ...

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

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

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

Когда вам говорят писать код на языке sth., Язык обычно указывается или подразумевается (правило в корпорациях).

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

Итак, я бы использовал это правило:

1) Если вам сказали выполнить какую-либо задачу, например, импортировать данные, я бы использовал инструменты / язык / и т. Д. это было бы наиболее удобным для меня и было бы самым быстрым для задачи.

2) Если вам предложат написать инструмент, выполняющий некоторую задачу, например, импортировать некоторые данные, я бы обсудил, какой язык / инструмент использовать с менеджером (за исключением случаев, когда я использую язык, который подразумевается стандартным, например, когда компания использует [почти ] только Java).

3) Если задача казалась одноразовой, но стала повторяемой, вам следует поговорить с менеджером, чтобы изменить ее с 1) на 2) и переписать с предпочитаемого вами языка, поддерживаемого компанией.

Я полагаю, что вы не в состоянии принять решение (иначе вы бы не задавали вопрос). Что твой босс думает об этой проблеме? Вы должны поговорить с ним и попытаться убедить его, что Python - это путь ...

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