Чи добре використовувати мову, яка не підтримується вашою компанією для деяких завдань?

Я працюю в компанії, яка підтримує кілька мов: 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 до CSV" повинен отримати корисні звернення.

BTW, інструменти для розробників VB6 (IDE, компілятор) не підтримується (навіть не виправлення безпеки), тому, швидше за все, стандарт потребує оновлення. (Виконання VB6 підтримується як частина (та включена до встановлення) поточних версій Windows). Це може бути використане як помічник для наближення до №1: стандартний набір інструментів потребує збільшення цілі, що рухається, через залежність постачальника.

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

Іноді компанії, можливо, доведеться дозволити одному розробнику почати вивчати нову сферу розвитку. На жаль, код може пробитися у виробництво швидше, ніж хто-небудь інший може досягти швидкості.

Ну, я маю визнати, що робота з 20 різними мовами смердить, МНОГО.

У вас є сценарій Bash, який викликає скрипт Python, який викликає скрипт Perl, який викликає Java бінарний, який викликає C dll ...

Потім щось потрапляє у вентилятор у всьому трубопроводі, і ви проходите через це - ЧОМУ ДАТЬ КОДЕЗ? Особливо в Perl ... І налагодження простої, скажімо, проблеми кодування, перетворюється на кошмарний безлад. Ви не можете ефективно налагоджувати 5 з 7 мов, і це перетворюється на справжній біль.

Або вам доведеться додати просту зміну, але ви створюєте 10 помилок, оскільки Perl має gotchas, Java має gotchas тощо.

І цей мовний ланцюжок 7+ починається по черзі.

Обережно ступайте, ось дракони ...

Якщо це інструменти, які ви використовуєте для себе, ви можете робити все, що робить вас більш продуктивними.

Власне, вам слід заохочувати робити та користуватися такими інструментами, які з часом стануть розширенням вашої зброї.

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

Коли вам кажуть писати код, виконуючи що-небудь, мова, як правило, вказується або мається на увазі (правило в корпораціях).

Але коли вам доведеться виконати одне ціле завдання, наприклад, імпортувати дані в БД, ви можете вибрати інструмент, який, на вашу думку, підходить найкраще, тому що ви повинні зробити щось правильне і швидке, а результат важливий, не інструменти.

Отже, я б застосував це правило:

1) Якщо вам скажуть виконати якусь задачу, таку як імпорт даних, я б використовував інструменти / мову / тощо. це було б для мене найбільш зручно і було б найшвидшим для виконання завдання.

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

3) Якщо завдання здавалося одноразовим, але воно стало повторюваним, вам слід поговорити з менеджером, щоб змінити його з 1) на 2) і переписати з потрібної мови, що підтримується компанією.

Я припускаю, що ви не в змозі прийняти рішення (інакше ви б не ставили питання). Що думає ваш начальник з цього питання? Ви повинні поговорити з ним і спробувати переконати його, що Python - це шлях, який потрібно пройти ...

Звичайно, питання полягає в тому, що буде, коли ви підете. Неможливість підтримувати код - це, мабуть, достатньо хороша причина, щоб перестати використовувати Python. Або ви можете почати навчати своїх колег до цієї мови ...