Проблема в том, что ваша реакция на кишечник может быть правильной, но это не значит, что ваш менеджер обязательно ошибается - у него, вероятно, есть очень веские причины для того, чтобы все это делать в Java. Не в последнюю очередь, если вы попадете под автобус, найти замену, который знает java, perl и bash, будет намного сложнее, чем найти кого-то, кто знает java. И это оставляет в стороне проблему «их можно запускать только на ПК с установленным Cygwin». И, по всей вероятности, производительность не так важна, как вы думаете.
Сказав это, вам лучше всего потратить немного времени на оценку времени, которое потребуется для переноса их всех на java, чтобы он мог принять обоснованное решение. И пока вы занимаетесь этим, оцените, сколько времени потребуется для переноса сценариев bash на perl и их документирования. Тогда пусть он решит. Помните - он не тратит большую часть своего времени на программирование, как вы, поэтому справедливо будет принимать вместо этого некоторые решения.
Если он решит продолжить работу с параметром java, перенести один из сценариев как можно лучше, а затем сообщить о двух версиях, и, если вы правы относительно краткости сценариев perl / bash, вам следует быть в состоянии получить некоторое расстояние от изучения двух версий рядом.
РЕДАКТИРОВАТЬ: MCS, если честно, для меня это звучит так, как будто эти скрипты лучше реализованы в perl и / или bash, чем в java, но это не совсем так - дело в том, как Вы демонстрируете это своему менеджеру? Если вы ответите на этот вопрос, вы ответите как на вопрос «интуитивной реакции» (кстати, вот вам совет - начните называть ваши инстинктивные реакции «суждением, основанным на опыте»), так и на вопрос «лучший способ представить мой случай».
Теперь, первое, что вы должны осознать, это то, что ваш менеджер (вероятно) не идет по этому пути просто чтобы вас разозлить. Он почти наверняка испытывает искренние опасения по поводу этих сценариев. Учитывая, что они, вероятно, искренние проблемы (и нет никакого смысла идти дальше, если они этого не делают - если он решил сделать это по какой-то политической причине, то вы не собираетесь менять его мнение, неважно что, так что просто продолжайте в том же духе и добавьте его в свое резюме) из этого следует, что вам нужно предоставить ему информацию, которая решит его проблемы, если вы собираетесь куда-нибудь попасть. Если вы можете сделать это, то вы более чем на полпути к своему собственному пути.
Итак, каковы его проблемы? Исходя из вашего поста, моего суждения и опыта :-) Я бы сказал, что они:
- ремонтопригодность
- Вот и все, просто ремонтопригодность
Я бы также предположил, что его проблемы не :
Конечно, я могу ошибаться насчет последнего. В последний раз, когда я работал, у нас была проблема с производительностью SQL Server, связанная с репликацией, которая влияла на способность бизнеса обеспечивать поддержку клиентов, поэтому производительность была проблемой, поэтому мы решили ее. Но в целом производительность не так важна, как думают программисты. Если он на самом деле сказал вам, что производительность - это проблема, то учтите это. Но если он не упомянул об этом, забудьте об этом - вероятно, только вы думаете, что эти сценарии работают в Perl / Bash быстрее, чем они, вероятно, будут в Java имеет значение вообще.
Итак, ремонтопригодность. Это сводится к ответу на вопрос "кто будет поддерживать эти сценарии, если MCS попадет под шину?" и дополнительный вопрос "это вызовет у меня (т. е. вашего менеджера) проблемы?" (Помимо: не зацикливайтесь на всем автобусе. «Падать под автобус» - это полезный и дипломатический способ сокращения всех видов рисков, например, «что произойдет, если кто-то заманивает его зарплатой, которую моя компания не может матч? »,« что произойдет, если он решит эмигрировать на Бермудские острова? »,« что произойдет, если я захочу его уволить? »,« что произойдет, если я захочу его продвинуть? »и, конечно,« что произойдет, если просто он перестает появляться на работе однажды по какой-то неизвестной, возможно, связанной с автобусом, причине? ")
Помните, что задача вашего менеджера - учитывать и снижать эти риски.
Итак, как это сделать?
Во-первых, продемонстрируйте, насколько на самом деле поддерживаются эти сценарии. Или, по крайней мере, насколько они могут быть ремонтопригодны. Документируйте их (в надлежащих документах, а не в коде). Обучите коллег поддерживать их (выберите кого-нибудь, кто хотел бы приобрести / улучшить свои навыки Perl и Bash и кому доверяет ваш менеджер). Рефакторинг их, чтобы сделать их более читабельными (жертвуя производительностью и умными трюками сценариев, если это необходимо). Если вы хотите продолжить использовать bash, создайте документ, содержащий пошаговые инструкции по установке cygwin и bash. В любом случае, документируйте процесс установки perl и запуска сценариев.
Во-вторых, выберите один из сценариев и перенесите его на Java. Не стесняйтесь выбирать сценарий, который лучше всего демонстрирует преимущества perl / bash над java, но делает все возможное, чтобы портировать его. Используйте java.util.regex, чтобы делать те же самые умные вещи, которые вы делаете в ваш перл. Документируйте это в соответствии со стандартом, что документированы другие внутренние утилиты Java. Если производительность действительно является фактором, измерьте его производительность относительно сценария perl / bash.
В-третьих, пройдя это упражнение, будьте честны с собой относительно их относительной ремонтопригодности. Спросите парня, которого вы обучили, что он думает. Если вы все еще думаете, что сценарии perl / bash более или менее удобны в обслуживании, как и версии Java, оцените работу, связанную с переносом оставшихся сценариев в Java, как можно точнее (вы сможете сделать это довольно точно сейчас, потому что вы на самом деле перенесли один). Затем отнесите сравнительные сценарии, документацию и сметы (и, если необходимо, показатели эффективности) своему менеджеру и просмотрите их вместе с ним. Представьте ваши встречные предложения (а. Оставьте их в perl и bash, но задокументируйте их и обучите коллегу, и б. Перенесите сценарии bash в perl, задокументируйте их и обучите коллегу).
Наконец, пусть ваш менеджер взвесит всю информацию, примет решение и будет придерживаться его решения. На самом деле, не просто соблюдать его решение, принять тот факт, что он может быть прав. То, что вы знаете больше о perl / bash / java, чем о нем, не означает, что вы обязательно знаете больше об управлении командой / отделом, чем он. И если его решение - придерживаться perl / bash или портировать на perl, радуйтесь! Поскольку у вас есть не только свой собственный путь, вы повысили оценку своего менеджера и получили ценный урок на этом пути.