Баланс между «правильным инструментом для работы» и фамильярностью [закрыто]

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

Ого, это ОЧЕНЬ сложный вопрос, когда вынимается из мира теории и в мир производства.

Теоретически

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

На практике

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

• Стоимость покупки «правильной оснастки»
• Стоимость поддержки этого - люди должны быть обучены
• Стоимость обучения кривой
• Стоимость интеграции с другими продуктами (сейчас и в будущем)
• ... и т.д

Вне теории есть серьезные последствия для вашего выбора технологии.

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

Если это личный проект - всегда используйте «правильный» инструмент - поэтому, когда вы сталкиваетесь с этим решением в бизнес-контексте, вы можете сделать более информированный звонок.

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

http://headrush.typepad.com/creating_passionate_users/2006/08/when_the_best_t.html

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

Мой общий подход:

1. Если это мелкая или краткосрочная вещь, всегда пишите это в знакомых инструментах.
2. Если это большая, долгосрочная вещь, посмотрите на соотношение затрат и выгод изучения нового инструмента.
3. Если вы не уверены, рассматривайте это как краткосрочную вещь, пока у вас не будет доказательств того, что это долгосрочная вещь. Тогда иди и посмотри на решение еще раз.

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

Отличный вопрос! Как сказал в своем ответе whatsisname, «фамильярности не дают достаточного доверия». Другой инструмент, другой фреймворк, другой язык могут быть намного лучше, чем те, к которым вы привыкли, и вы все равно будете намного менее продуктивны с ним в первый раз, когда вы изучите веревки.

В течение нескольких лет я работал разработчиком ASP.NET в цифровых агентствах, где у нас есть смесь крупных проектов, небольших проектов, сложных проектов, проектов с хорошим дополнением и т. Д. Что мы пытаемся сделать, чтобы расширить свои навыки, искать «мягкие цели», небольшие проекты, которые не имеют мучительно сжатых и жестких сроков, и использовать их как возможность использовать новые технологии, которые могут быть лучше. .NET 2.0, 3.5, 4.0, ASP.NET MVC, Linq to SQL, Entity Framework - все это я впервые использовал в таком проекте.

Если вы можете использовать свои возможности таким образом, то, надеюсь, вы будете готовы с большим набором опций, чтобы выбрать правильный инструмент, не испытывая недостатка знакомства. Как в примере с Хулио: они нашли цель, где они могли бы добавить Ruby в свой репертуар, и теперь, двигаясь вперед, они могут выбирать между Java и Ruby.

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

Это зависит от нескольких вещей:

1. Насколько вы хороши в изучении новых языков или инструментов.

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

2. Насколько независимы язык / инструмент, вы делаете свою рабочую среду.

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

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

3. Деловая реальность

Изучение новых инструментов / языков требует времени. Это время имеет цену. Но эта стоимость может стать инвестицией, которая окупит больше первоначальных затрат. Кроме того, неуклюжее решение обычно занимает больше времени для внедрения и сложнее в обслуживании. Если это что-то большее, чем небольшой проект, и инструменты в моем существующем наборе инструментов, кажется, не подходят для проблемы, я исследую, какие инструменты действительно подходят для этой проблемы. Я также инвестировал в среду, подходящую для универсального подхода, и научился использовать vim в качестве выбранного мной редактора.

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

Если есть новый язык, который вас интересует, и вы (и бизнес) можете себе это позволить, почему бы не дать себе пару недель или месяц на его изучение?

Так я выучил рубин. Мой партнер по кодированию имел 7-летний опыт работы с Java. У меня был 11-летний опыт работы с Java. Никто из нас не знал ничего о рубине, только то, что мы хотели попробовать.

Я убедил его и всю остальную компанию попробовать ruby ​​в течение месяца (это будет 6-8-месячный проект). В худшем случае, мы начнем с этого времени, используя Java.

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

Очевидно, что нет единого ответа на этот вопрос, который применим ко всем ситуациям. Но вот аспект, который я не думаю, был упомянут еще. Если вы разработчик, вам также следует учитывать собственную конкурентоспособность. Если для вашего проекта выбран язык X, как это будет выглядеть в вашем резюме? Хорошей идеей может быть выбор языка, с которым вы не знакомы, чтобы у вас была причина выучить его, расширить свой интеллектуальный кругозор и сделать свой набор навыков более привлекательным для будущих работодателей.

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

Моя собственная версия - «использовать подходящий мне инструмент» для этой работы. Быть «доступным» означает, что я могу использовать его, а не только то, что я могу купить / получить компилятор и // или время выполнения.

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

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

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