Насколько часто команды пишут все своими силами? [закрыто]

В одном из недавних интервью я спросил интервьюеров: «Как вы оцениваете новые технологии и библиотеки (такие как SignalR) и вводите их в действие?». Они сказали, что не делают, что вместо этого они пишут все сами, чтобы им не пришлось полагаться ни на кого другого.

Фирма не работает на правительство или подрядчиков по обороне или над какими-либо критическими для безопасности проектами или чем-то подобным. Они были просто вашей средней фирмой по разработке программного обеспечения.

Мой вопрос: как часто команды пишут все сами? Должны ли я быть обеспокоены командами, которые делают?

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

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

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

• Удовлетворить потребности кода, который они могли бы написать сами
• Были доступны по лицензии, совместимой с бизнес-моделью компании
• Включенные тесты
• Прошел обзор кода

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

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

Более того, отвращение к созданным сторонним библиотекам серьезно снижает производительность программиста. Допустим, компания писала веб-приложения и отказалась использовать (например) jQuery, поэтому вместо этого написала собственную альтернативную кросс-браузерную библиотеку для упрощения манипулирования DOM. С уверенностью можем предположить, что их реализация:

• Будет ли API чужим для разработчиков, уже знакомых с jQuery
• Не будет так хорошо документирован, как jQuery
• Не будет релевантных результатов Google при возникновении проблем с использованием библиотеки
• Не будет проверен в полевых условиях, как jQuery

Все эти моменты являются основными препятствиями для производительности программистов. Как бизнес может позволить себе отказаться от такой производительности?

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

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

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

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

Это кажется невероятно неконкурентоспособным. Я работал в магазинах, которые решили пропустить стандартные библиотеки с открытым исходным кодом, такие как Hibernate, и развернуть свои собственные из-за какой-то «критической» недостающей функции. В конце концов, программное обеспечение было невероятно дорого в сборке и обслуживании. Конечно, расходы на внутреннюю библиотеку были сильно недооценены. И хотя внутренняя библиотека была написана, стандартные библиотеки быстро развивались, добавляя новые функции, которые не были доступны во внутренней библиотеке. В конце концов, работа со стандартной библиотекой, которая заняла бы час, заняла два дня. И это было плохо для карьеры разработчика, поскольку мир прошел мимо них. Я бы избегал такого магазина. Мне нравится доставлять, и у меня нет терпения, чтобы переписать, когда я мог бы использовать повторно.

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

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

Да, обязательно будьте обеспокоены! Это пахнет высокомерием и (извините за резкость) глупостью. Любой программист с половиной мозга будет использовать библиотеку типа signalR вместо того, чтобы писать ее самостоятельно. Нет абсолютно никакого смысла тратить свое время на решение проблемы, которая уже решена. Возможно, я сначала попытаюсь узнать больше информации - возможно, вас неправильно поняли (хотя может быть сложно, если собеседование закончено!)

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

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

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

Я не буду отрицать уже высказанные хорошие моменты, но добавлю одну вещь.

Они только что сделали найм намного сложнее.

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

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

И в равной степени, будут некоторые компании, которые работают в «интернет-масштабе», Amazon, Facebook и т. Д., Где у них есть безумные пользовательские потребности, но опять же они в меньшинстве.

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

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

Из того, что вы написали, этот сценарий, похоже, не лежит в основе дела.

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

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

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

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

Я бы лично не пошел в место с такой культурой.

То, что у вас есть, это действительно хорошая возможность пойти на второе интервью и задать им несколько сложных вопросов. Я не знаю, что делает компания, поэтому трудно сказать, почему это кажется странным выбором. Вы можете использовать комментарий @Daniel Pryden относительно использования Google сторонних библиотек.

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

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

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

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

Крупные компании все пишут сами.

Есть несколько преимуществ в написании этого самостоятельно:

1. Вы гарантированно владеете программным обеспечением самостоятельно
2. Вы можете правильно рассчитать объемы работ, которые пошли на его создание
3. Повторение ваших шагов становится возможным, даже если в следующий раз библиотеки не доступны
4. Это сокращает ваши требования раздувать
5. Вы не повторяете то, что уже сделали другие
6. Вы гарантированно иметь достаточно людей, чтобы поддерживать его
7. Вы можете изменить каждую часть программного обеспечения
8. Размер программного обеспечения ограничен количеством имеющихся у вас ресурсов

Вот как каждый из пунктов ломается, если вы используете чужую библиотеку:

1. Кто-то еще владеет библиотекой
2. Вы не знаете, сколько усилий ушло на создание библиотеки
3. Вашу следующую версию продукта невозможно создать на новой платформе, так как такие же библиотеки больше не доступны
4. Способность реализовать требование зависит от того, была ли библиотека реализована несколько лет назад.
5. Кто-то также использует ту же библиотеку, получая те же ограничения и функции
6. Поскольку вы не создавали библиотеки, у вас недостаточно людей для поддержки всего программного обеспечения в вашем продукте
7. Libs являются бинарными, немодифицируемыми. Даже если исходный код доступен, у вас недостаточно людей, чтобы изменить этот большой объем кода.
8. Поддержание созданного вами кода + библиотеки - это больше усилий, чем вы предполагали