Сколько свободы должен иметь программист в выборе языка и структуры?

Я начал работать в компании, которая в первую очередь ориентирована на C #. У нас есть несколько человек, которым нравятся Java и JRuby, но большинство программистов здесь любят C #. Меня наняли, потому что у меня большой опыт создания веб-приложений, и потому что я склоняюсь к новым технологиям, таким как JRuby on Rails или nodejs.

Недавно я начал проект по созданию веб-приложения, в котором основное внимание уделялось выполнению множества задач за короткий промежуток времени. Ведущий по программному обеспечению диктовал, что я использую mvc4 вместо рельсов. Это может быть хорошо, за исключением того, что я не знаю mvc4, я не знаю C #, и я единственный, кто отвечает за создание сервера веб-приложений и интерфейсный интерфейс.

Разве не имеет смысла использовать фреймворк, который я уже очень хорошо знаю (Rails), вместо использования mvc4? Причиной такого решения стало то, что технический руководитель не знает Jruby / rails и не будет возможности повторно использовать код.

Контраргументы:

• Он не будет вносить свой вклад в код и, честно говоря, не нужен в
  этом проекте. Так что не имеет значения, знает ли он JRuby / rails или нет.

• На самом деле мы можем повторно использовать код, так как у нас есть много java-приложений, из которых JRuby может извлекать код и наоборот. Фактически он выделил некоторые ресурсы для преобразования библиотеки Java в C # вместо того, чтобы просто запускать библиотеку Java в приложении JRuby on Rails. Все потому, что он не любит Java или JRuby

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

В какой момент разработчик должен иметь возможность выбирать свои инструменты? Это зависит от компании? Моя компания отстой или это считается нормой? Существуют ли более зеленые пастбища? Я смотрю на это неправильно?

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

Я знаю, что вы, ребята, магазин .NET, но на самом деле меня наняли для моих навыков Java / JRubyRails. Я могу построить это новое приложение за X раз, используя те инструменты, которые я уже знаю. Я мог бы выучить C # / mvc4 так, как вы хотите, но это займет >> X времени. Чего ты хочешь?

В этой связи возникает вопрос о «навыках вы-were- (предположительно) -hired-за» против «навыки вы-потребность-сейчас» , а также показывает , что вы готовы , чтобы узнать новые навыки, но он будет принимать дольше разрабатывать новое приложение, поскольку вы новичок в этом наборе инструментов. И вы действительно хотите показать, что готовы изучать новые навыки. Отсутствие открытости для обучения новым навыкам - это хороший способ гарантировать, что ваша занятость заканчивается, когда ваши навыки больше не нужны.

Что касается вашего вопроса в конце:

В какой момент разработчик должен иметь возможность выбирать свои инструменты? Это зависит от компании? Моя компания отстой или это считается нормой? Существуют ли более зеленые пастбища? Я смотрю на это неправильно?

Обычно это зависит от компании. Если компания покупает инструменты MS и стандартизирует все на платформе VisualStudio и платформе .NET, может быть очень неловко, если один разработчик настаивает на использовании Linux и C. Это нормально. Могут существовать исключения, когда компания менее суетлива в отношении редакторов, например, разрешает разработчикам выбирать Vi против Emacs, если вывод одинаков. Я знаю, что некоторые компании даже позволяют разработчикам выбирать Windows вместо Linux, но язык, на котором они работают, имеет очень хорошую поддержку и время выполнения для обеих ОС.

Почему компании делают это? Последовательность является одной из причин. Отладка может быть очень сложной, если приложение представляет собой набор из двоичных файлов, созданных на любимых языках / платформах различных разработчиков, встроенных в различные инструменты и протестированных в самых разных системах. Если все разработчики работают в основном с подобными настройками, такие проблемы решаются.

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

В какой момент разработчик должен иметь возможность выбирать свои инструменты?

Когда они не влияют на вашу команду.

Я смотрю на это неправильно?

Абсолютно.

Да, у вас короткий срок. Да, вы можете сделать это быстрее в Rails. Но компании в целом необходимо развернуть и поддерживать приложение. Если у компании есть стабильная группа хороших разработчиков на C #, то, вероятно, будет дешевле (и обеспечит лучшее качество) поддерживать приложение на C #.

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

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

1. Вы, очевидно, были наняты из-за вашей способности адаптироваться к «новым» технологиям. C # ничем не отличается в этом отношении. Вы уверены, что не хотите воспользоваться возможностью, чтобы узнать что-то новое?

2. ASP.NET MVC очень похож на Ruby on Rails во многих отношениях.

3. Вы не будете в темпе улитки вечно. Если вы уже знаете ROR, ASP.NET MVC станет для вас непростой задачей. Хитрость заключается в изучении C #.

Аргументы для того, чтобы остаться с Java / JRuby

Скорее всего, ваш босс хочет, чтобы вы производили. Они наняли вас, чтобы вы могли повысить ценность компании. Убедитесь в том, что они понимают , что, заставляя вас использовать рамки , которые вы не знакомы с их будет причинить вам:

1. Производить результаты медленнее
2. Создать код низкого качества

Даже лучшим программистам требуется время для разминки с новыми языками / фреймворками.

Аргументы для изучения MVC4 и C #

Изучение новых языков это хорошо. Инвестирование в свои навыки программиста - это только риск, если язык / платформа, которую вы изучаете, исчезнет в ближайшем будущем, и, если Microsoft пойдет на попятную, я не думаю, что это проблема. C # и MVC оба недавно получили обновления, улучшающие их оба, с еще большим количеством обновлений в конвейере.

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

Нижняя линия

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

В какой момент разработчик должен иметь возможность выбирать свои инструменты?

Когда сказал, что разработчик является руководителем программного обеспечения.

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

Кстати, фраза

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

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

Отмечу, что вы не говорите, что были наняты в качестве программиста на JRuby или Java.

Вот почему вы сказали, что вас наняли: «Потому что у меня большой опыт создания веб-приложений и потому, что я склоняюсь к новым технологиям, таким как JRuby on Rails или nodejs».

Другими словами, им нравится ваш веб-опыт и ваша готовность изучать новые технологии.

Теперь они просят вас использовать свой веб-опыт и изучать новые технологии.

Итак, вопрос в том, собираетесь ли вы это делать или нет?

Самые большие затраты на программное обеспечение заключаются в его поддержке

Я читал, что самые большие расходы (80%) связаны с обслуживанием программного обеспечения. Первоначальная разработка составляет всего 20% от общей стоимости разработки.

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

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

Решение: парное программирование

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

Статья в Википедии "Парное программирование": http://en.wikipedia.org/wiki/Pair_programming

Многие компании просто предпочитают придерживаться того, что они всегда делали или что "безопасно". Есть причина, по которой Java и PHP по-прежнему очень популярны. В настоящее время поиск по запросу «COBOL» на веб-сайте действительно.com возвращает 2144 списка ... которые действительно должны говорить сами за себя. Индустрия не заботится о хорошем коде, она заботится о коде, который может доить как можно дольше (это не означает, что C # плох, но на самом деле это не так).

Подумайте об этом: код переживет вас. Есть большая вероятность, что кто-то другой будет поддерживать ваш код, и C # безопаснее, чем Node.js и Rails. Меня не удивит, если через 5 или 6 лет число программистов на Ruby сократится вдвое, ведь то же самое произошло с Perl и любым другим языком, который в какой-то момент считался веб-языком "it". Javascript вряд ли уйдет, но мы уже начинаем видеть, что он используется как своего рода ASM (или даже C) в Интернете - промежуточный язык, который могут компилироваться другими языками, так что написание серверного кода в нем может очень хорошо устаревают.

Моя основная проблема с разработчиками, выбирающими способы реализации своих целей, заключается в том, что они обычно предполагают, что только они будут редактировать код. Посмотрите на это так, через 12 месяцев они могут нуждаться в изменениях; вы недоступны (ушли из компании или действительно заняты другой задачей), и другой разработчик должен изменить ваш код. Если это магазин C #, то использование их набора инструментов - хорошая командная работа. Новые технологии должны быть исследованы и внедрены, но только тогда, когда ведущий считает, что настало время, так как они видят многие цели, а не только одну.

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

Что бы вы им сказали? Это наш стек, чувак. Учись жить с этим.

Золотое правило, вот, кто владеет золотом, устанавливает правила.

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

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

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

Если ваша команда не является полным идиотом, вы сможете найти консенсус, который имеет смысл в отношении проекта и общих целей компании.

Ба. Все не правы.

Будьте лучшим разработчиком, чем те, кто работает на одной платформе, и у вас будет гораздо больше интересных возможностей, чем когда-либо. Итак, на данный момент, изучите MVC. А в свободное время узнайте больше о платформах, которые действительно вас интересуют. Создайте свои навыки Node. Узнайте немного Джанго. Обращайте внимание на все, что вам угрожает Java или pre MVC .NET, и затем убегайте, но, по крайней мере, выучите достаточно, чтобы иметь возможность критиковать и объяснять, сколько мыслей вы вложили в свой едва скрываемый предрассудок ненависти к этим платформам. (хорошо, может быть, я проецирую там)

А теперь важный совет. Если вы продолжите оттачивать свои специальности, а также диверсифицируете свой опыт в других областях, вы в конечном итоге окажетесь в том месте, где сможете найти новую работу в любое время года менее чем за две недели в любом крупном городе, занимаясь чем-то, что является в основном интересно хотя бы половину времени. Когда вы окажетесь в этом месте, не миритесь с этими работами, когда говорят, что они этого хотят, и ко второму дню они заставляют вас делать ЭТО без надежды на отсрочку в обозримом будущем. Просто вежливо объясните и извинитесь, но нет, вы действительно не хотели делать ЭТО и сказали так много на своем интервью, а затем! @ # $, Уходите и идите дальше, когда проходит пара недель, и они неизбежно не сделали ничего, чтобы приспособиться к тот факт, что они представили вам неверную позицию и отказались признать это.

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

Конечно, не имеет смысла, потому что они диверсифицировались с разработчиком Rails / JS / UI и только заставляли его делать приложения MVC. Но сейчас. Возможно, вам придется забрать его и заплатить взносы. И, как я сказал в комментариях, MVC действительно не так уж и плох. Действительно плохой выбор, учитывая все варианты, но, конечно, не худший. Это довольно просто, не отбрасывает 10 000 слоев абстракции поверх всего, что на самом деле происходит, и не настолько извращает себя на стороне клиента, что вы бы проклинали имена ответственных за MS инженеров, если кто-то может быть обеспокоен учить их.

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

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

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

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

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

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

То, что вы выберете, зависит от вас, но я бы посоветовал вам попробовать освоить новые технологии. Это не повредит, я обещаю.

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

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

Естественно, есть кривая обучения. Если работодатель принял вас на работу, он должен быть уверен в вашей способности следовать этой кривой в течение разумного периода времени (опять же, если вы честно заявили, что не знаете C #). Язык C # в значительной степени заимствует из Java, и в более общем смысле большинство языков программирования на основе классов в основном очень похожи (вы упомянули node.js, который основан на ECMAScript, который является языком на основе прототипов, так что вы, очевидно, комфортно с другими парадигмами программирования.

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

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

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

Возможно, они не удовлетворены тем, как все используют MVC в среде .NET. Там может быть слишком много, чтобы рассматривать его как веб-формы. Это ничем не отличается, когда кто-то с процедурным прошлым начинает в ООП, ставит все в один большой класс и продолжает вести дела как обычно.

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

Надеемся, что ваш способ использования MVC4 (при условии, что все остальные делают это не совсем правильно) в более рубиновом стиле поймает и отделит всех от менталитета Webforms.