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

53

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

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

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

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

Энди Хант
источник
58
Огромный красный флаг. Уходи спокойно и не делай резких движений.
tdammers
16
Я не думаю, что это так смешно, как говорят люди ... Недавно я потратил невероятное количество времени на исправление заброшенных библиотек для новых версий фреймворка, новых версий библиотек с серьезными критическими изменениями, которые не были задокументированы, и даже с огромными пробелами. в значительных рамках, таких как jQuery, которые делают их не пригодными для использования. Люди не прикладывают достаточных усилий, чтобы решить, добавят ли компоненты третьей части огромные накладные расходы на техническое обслуживание, и часто они заканчиваются пиками неосуществимого ада зависимости от спагетти.
Дэнни Таппени
4
NuGet - это круто, но это так легко сделать. Недавно я установил некоторую тривиальную вспомогательную библиотеку от NuGet, и она включила Касла и всякую другую вздутую ерунду. Конечно; Прямой запрет - это странно, но он не более глуп, чем позволять каждому разработчику и его собаке случайным образом вводить вещи без реальной мысли.
Дэнни Таппени
13
Все? Включает ли это свои собственные браузеры, операционные системы и компиляторы? В противном случае они просто обманывают себя.
Мухаммед Алкарури
4
Конечно, это так же смешно, как говорят люди. Дело в том , что а) можно выбрать неправильную библиотеку для работы и б) существуют ситуации , в которых нет библиотеки третьей стороны доступны будет соответствовать вашим потребностям лучше , чем в доме один: не значит , что одеяло политики никогда не используя третью сторону библиотеки правильные.
user16764

Ответы:

76

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

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

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

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

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

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

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

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


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

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

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

  • Они открыты для перемен, и ваша забота об их процессе заставляет вас выглядеть лучше, чем некоторые другие кандидаты.
  • Они не открыты для изменений и думают о вас как о «разработчике, которого мы бы не хотели нанимать». Неважно, это не то место, где вы хотите работать в любом случае.
Марк Рушаков
источник
1
+1 но я думаю вы имели ввиду частный сектор, а не государственный сектор.
MarkJ
6
«Если код с открытым исходным кодом, то в худшем случае сторонняя библиотека перестает обслуживаться. Но кого это волнует? Тесты показывают, что библиотека подходит для ваших нужд!» У вас также есть исходный код, который позволяет вам иметь то, что вы используете сейчас, и иметь возможность обновлять его для удовлетворения любых будущих потребностей. (Да, чтобы привыкнуть к «чужой» кодовой базе, нужно время, но то же самое происходит и с самим собой.)
CVn
34

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

Кевин Клайн
источник
2
Так как у разработчиков больше не было соответствующих навыков для других работ, деньги компании, потерянные на длительное время разработки, были сэкономлены благодаря тому, что им не приходилось заменять уходящих членов команды! #stratgey
Майкл Полуконис
@Michael: Единственными людьми, которых они могли сохранить, были люди, которые присутствовали при первоначальном решении создать собственные фреймворки. Новые сотрудники, как правило, уходили примерно через год.
Кевин Клайн
</ itwasaweakjoke>
Майкл Полуконис
+1 Если недостающая функция действительно, действительно важна: измените библиотеку с открытым исходным кодом и добавьте эту функцию в основной источник. Обеспечивает большую деловую ценность, заставляет всех чувствовать себя хорошо, и это отлично подходит для всех резюме, потому что теперь они внесли вклад с открытым исходным кодом.
MarkJ
@MarkJ: но если изменение будет отклонено, у кого-то будет синяк эго.
Кевин Клайн
20

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

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

Дэн Пичельман
источник
15

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

Rocklan
источник
11

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

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

авик
источник
+1 одна из главных причин, по которой я перешел от моего предыдущего работодателя!
Энтони Скотт,
5

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

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

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

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

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

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

Ozz
источник
4

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

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

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

Томас
источник
4

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

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

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

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

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

Итай Саги
источник
1

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

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

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

Даниэль Холлинрейк
источник
-3

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

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

Мартин Конечни
источник
«Я не видел, чтобы это упоминалось здесь» - вы смотрели на другие ответы, например на этот ?
комнат
3
Не получите много навыков? Это смешно. Это верно только в том случае, если вы рассматриваете программирование как игру с блоками Lego, объединяющими компоненты. Если вам нужно «заново изобрести» библиотеку, вы очень много узнаете о конкретной теме.
GrandmasterB
@GrandmasterB Вы правы, позвольте мне уточнить - во многих местах спрашивают, с какими инструментами вы работали. Ваши шансы на то, что вас упустят из виду, гораздо выше, если другие кандидаты смогут начать работать, а вам придется учиться с нуля.
Мартин Конечни
-9

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

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

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

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

  1. Кто-то еще владеет библиотекой
  2. Вы не знаете, сколько усилий ушло на создание библиотеки
  3. Вашу следующую версию продукта невозможно создать на новой платформе, так как такие же библиотеки больше не доступны
  4. Способность реализовать требование зависит от того, была ли библиотека реализована несколько лет назад.
  5. Кто-то также использует ту же библиотеку, получая те же ограничения и функции
  6. Поскольку вы не создавали библиотеки, у вас недостаточно людей для поддержки всего программного обеспечения в вашем продукте
  7. Libs являются бинарными, немодифицируемыми. Даже если исходный код доступен, у вас недостаточно людей, чтобы изменить этот большой объем кода.
  8. Поддержание созданного вами кода + библиотеки - это больше усилий, чем вы предполагали
ТР1
источник
7
Не будет ли логическим продолжением этих аргументов также написать свой собственный компилятор (возможно, для вашего собственного языка), запустить это программное обеспечение в вашей собственной ОС и, возможно, создать собственный HW?
Timday
4
1: Да, и я могу заплатить комиссию, чтобы использовать это (не тратя деньги, чтобы построить это разница в стоимости). 2: если я не строю это, мне все равно. 3: В бизнес-платформах медленно меняются. Оставаться на переднем крае редко требуется. Но хорошее программное обеспечение легко перемещается. 4: не правда. Вы просто переносите наворот с внешнего на внутренний. 5: не имеет смысла. 6: не верно. 7: Верно, но означает, что вам нужно отвлечь ваших драгоценных программистов (самая дорогая часть проекта) от реальной работы в исправление ошибок, которые можно было бы поддерживать в другом месте. 8: это плохо.
Мартин Йорк,
5
Многие крупные компании широко используют открытый исходный код в различных формах (включая библиотеки), часто улучшая / внося свой вклад в соответствующие проекты. Точки в основном не имеют значения или неверны.
Мэтт
7
@ tp1: я работаю в Google и могу заверить вас, что Google очень часто использует сторонние библиотеки, когда они отвечают нашим потребностям. Во многих случаях у Google есть потребности, которые являются уникальными или в разных масштабах по сравнению со многими другими компаниями-разработчиками программного обеспечения, поэтому по той или иной причине Google часто разрабатывает свои собственные продукты. Но Google также использует большое количество библиотек с открытым исходным кодом и / или множество внутренних библиотек с открытым исходным кодом, так что не все внутри компании. Большинство ваших баллов больше не применяются к программному обеспечению с открытым исходным кодом, поскольку, имея исходный код, вы всегда можете отладить его и исправить его при необходимости.
Даниэль Приден
5
«Нет, ценность заключается в точном выполнении требований. Если он был построен до того, как требования стали известны, он не может точно выполнить эти точные требования». Подсказка: если вы считаете, что этот аргумент имеет какое-либо значение, то вы не поняли разделения интересов.
user16764