Нормально ли использовать язык, который не поддерживается вашей компанией, для некоторых задач?
-
16-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я работаю в компании, которая поддерживает несколько языков:COBOL, VB6, C# и Java.
Я использую эти языки для своей основной работы, но мне часто приходится кодировать некоторые второстепенные программы (напримерscripts) на Python, потому что я счел его лучшим инструментом для такого типа задач.
Например:Аналитик дает мне сложный CSV-файл для заполнения некоторых таблиц БД, поэтому я бы использовал Python для его анализа и создания скрипта БД.
В чем проблема?
Основная проблема, которую я вижу, заключается в том, что некоторые части этих быстрых и грязных сценариев постепенно приобретают все большее значение и:
- Моя компания не поддерживает Python
- Они не контролируются версиями (я создаю их резервные копии другим способом).
- Мои коллеги не знают Python
Аналитики даже начали ссылаться на них по электронной почте ("запустите скрипт, который экспортирует ..."), так что они нужны чаще, чем я изначально думал.
Я должен добавить, что эти скрипты - всего лишь утилиты, которые не являются частью основного проекта;они просто помогают выполнять тривиальные задачи за меньшее время.Для моих собственных небольших задач они очень помогают.
Короче говоря, если бы я был победителем лотереи попасть в аварию, моим коллегам нужно было бы поддерживать проект в рабочем состоянии без этих сценариев.;например, они потратили бы больше времени на исправление ошибок CSV вручную.
Является ли это распространенным сценарием?Я делаю что-то не так?Что мне следует делать?
Решение
Вы должны формализовать ситуацию, поскольку она не должна была добраться до этого момента. Тем не менее, эти вещи случаются, поэтому вам нужно объяснить своему боссу, что вы создали эти сценарии для личного использования, но они «сбежали» в более широкий циркуляцию. Признайте (если это необходимо), что вы виноваты, что не доведем это до его внимания раньше.
По крайней мере, сценарии должны быть помещены под контроль источника «на всякий случай» - тогда, по крайней мере, если вы недоступны (по какой -либо причине), ваши коллеги будут иметь доступ к сценариям.
Тогда вам либо нужно убедить своего босса в том, что Python-это способ пойти на них, либо принять, что вам придется переписать их на поддерживаемом языке. Если стоимость документирования сценариев и обучения ваших коллег на Python ниже, чем у переписного писателя, вы можете даже выиграть аргумент.
Другие советы
Я не могу дать вам полный ответ на то, что вы должен делать. Я могу дать только одно предложение, которое вы можете использовать, чтобы начать с:
Проверьте сценарии в хранилище, к которому могут получить доступ все (требуемые) разработчики. Но очень обязательно отметим тот факт, что вы впервые написали эти сценарии для своих собственный Цель, т.е. выполнить задачу, вам дали. Затем добавьте, что вы проверяете только эти сценарии, чтобы дать другим преимуществом использовать их.
После этого вам просто нужно увидеть, как другие люди реагируют на это.
Я столкнулся с подобными проблемами, где я работаю. Я слышал "Что такое PHP?" несколько лет назад. Они не понимают или не заботятся о чем -то за пределами стека MS. Если Python является правильным инструментом для работы, я бы просто рассказал своим руководителям об этом и буду готов к многому сравнению и объяснению того, почему Python был правильным выбором. Это будет разочаровывает, но я думаю, что большинство согласится с Python - хороший выбор для манипуляции с текстами.
Первое, что вам нужно сделать, это поговорить с командой и вашим боссом. Прямо сейчас у вас есть огромный фактор грузовика (если вам ударил грузовик, никто другой не мог бы легко поддерживать ваши сценарии). Похоже, что сценарии для выполнения этих задач важны, но также важно, чтобы любой, кому нужно редактировать и поддерживать эти сценарии. Вам нужно объяснить, как использование Python добавляет ценность - как он экономит время, усилия, ресурсы, деньги и так далее.
Во -вторых, получите его в контроль версий проекта. В настоящее время. Ничто из того, что вы производите для проекта, не должно быть за пределами контроля версий этого проекта.
Будьте готовы к обратной реакции - люди обычно не любят перемен. Выбег самостоятельно, использование неподдерживаемых и неизвестных (для команды/организации) технологий было плохой идеей, без консультации, по крайней мере, других разработчиков и определения лучших (для проекта, а не только для вас) способа автоматизации этих задач для всех использовать.
Я думаю, что это, вероятно, хороший случай
Просить прощения проще, чем получить разрешение.
Похоже, вы сделали работу, но вам сейчас придется иметь дело с последствиями.
Мое правление большого пальца:
Все, что потенциально влияет на работу других, должно обсуждаться со сверстниками и начальством как можно скорее.
Но, Если это для вас и вас один, пока это не нанесет ущерба инфраструктуре или безопасности вашей фирмы, вы можете сделать, как хотите выполнить работу.
У вас есть два варианта:
- Сделайте это стандартом
- Перевести в стандартный инструмент
В зависимости от организации № 1 может быть сложной задачей (после того, как все ограничение списка стандартных технологий позволяет избежать комбинаторного взрыва требований обучения и поддержки навыков).
Второй вариант поможет вашему набору навыков, и вы, возможно, сможете найти третью сторону (и, вероятно, открытый исходный код с коммерчески дружелюбными лицензиями) для выполнения некоторой тяжелой работы. Например, поиск «Linq to CSV» должен получить несколько полезных хитов.
Кстати, инструменты разработчика VB6 (IDE, компилятор) не поддерживаются (даже не исправления безопасности), так что, вероятно, в любом случае это стандартное потребление обновления. (Время выполнения VB6 поддерживается как часть - и включена в установку - текущих версий Windows). Возможно, это может быть использовано в качестве помощника для подхода № 1: стандартный набор инструментов должен повысить движущуюся цель из -за зависимостей поставщика.
Если вам дается задача, и Эйте единственный способ сделать это вовремя, у вас нет выбора. Я действительно думаю, что целесообразно сообщить, что ответственны, что вы делаете. Вы не должны выходить за пределы требуемого контроля источника (если только это не работает вообще не работает?) Тестирование и документация.
Иногда компании, возможно, придется позволить одному разработчику начать изучать новую область разработки. К сожалению, код может проникнуть в производство быстрее, чем кто -либо другой может достичь скорости.
Ну, я должен признать, что работа с 20 различными языками воняет, много.
У вас есть скрипт Bash, который вызывает сценарий Python, который вызывает скрипт Perl, который называет Java Binary, который вызывает C DLL ...
Тогда что -то поражает вентилятор во всем трубопроводе, и вы проходите - WTH - это Dat Kodez? Особенно в Perl ... и отладки простой, скажем, проблемы кодирования, превращается в кошмарный беспорядок. Вы не можете отлаживать 5 из 7 языков эффективно, и это превращается в настоящую боль.
Или вы должны добавить простое изменение, но вы создаете 10 ошибок, потому что у Perl есть есть полученные, у Java есть полученные и т. Д.
И эта языковая цепь 7+ начинается один шаг за раз.
Продолжить осторожно, здесь будь драконами ...
Если это инструменты, которые вы используете для себя, вы можете делать все, что делает вас более продуктивным.
На самом деле, вы следует поощрять Сделать и использовать такие инструменты, которые в конечном итоге станут расширением ваших рук.
В конце концов они признают важность наличия таких инструментов, Независимо от того, на каком языке они написаны, и начнет реализовать в своей рабочей среде.
Когда вам говорят написать код, выполняющий что-то подобное, язык обычно указывается или подразумевается (правило в корпорациях).
Но когда вам приходится выполнять какую-то одноразовую задачу, например импортировать данные в базу данных, вы вольны выбирать инструмент, который, по вашему мнению, подходит лучше всего, потому что вам нужно сделать что-то правильное и быстрое, и важен результат, а не инструменты.
Итак, я бы воспользовался этим правилом:
1) Если вам скажут выполнить какую-то задачу, например импортировать данные, я бы использовал инструменты / язык / etc.это было бы наиболее удобно для меня и быстрее всего подошло бы для выполнения задачи.
2) Если вам скажут написать инструмент, выполняющий какую-то задачу, например, импортировать некоторые данные, я бы обсудил, какой язык / инструмент использовать с менеджером (за исключением случаев, когда я использую язык, который подразумевается стандартным, например, когда компания использует [почти] только Java).
3) Если задача казалась одноразовой, но ее можно было повторить, вам следует поговорить с менеджером, чтобы он изменил ее с 1) на 2) и переписал с вашего предпочтительного языка на поддерживаемый компанией.
Я полагаю, что вы не можете решать (или вы не зададите вопрос). Что ваш босс думает об этой проблеме? Вы должны поговорить с ним и попытаться убедить его, что Python - это путь ...
Конечно, проблема в том, что произойдет, когда вы уйдете. Неспособность поддерживать код, вероятно, является достаточно хорошей причиной, чтобы прекратить использование Python. Или вы можете начать обучать своих коллег этому языку ...
