Когда вы используете сторонний код?

Question

Как вы обычно решаете проблему программирования, например, когда вам нужно проанализировать ini-файл?

Если это моя задача, я буду:

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

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

3. Если я ничего не нашел, тогда я сделаю свою собственную реализацию. Но эта ситуация очень редка.

Таким образом, я считаю, что могу больше сосредоточиться на бизнесе, на чем-то уникальном для нашей организации.

---

НО, что я обычно вижу совершенно иным способом.

1. Только верьте в стандартные библиотеки C/C++.
2. Внесите все остальное, если это невозможно.

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

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

---

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

Что вы думаете об этом? Как вы анализируете файлы .ini?

Answer 1

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

Answer 2

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

sscanf прекрасно работает для разбора INI файлов в C.

Answer 3

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

Answer 4

Я предпочел бы использовать готовые INI-анализатор (для C - например, this one, это довольно мало), чем делать это вручную, используя sscanf или так (это хорошо для простого key=value возможно, но INI-файлы могут быть более сложными, чем что).

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

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

Answer 5

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

Иногда есть действительно хорошие решения некоторых проблем. Они не могут быть пропущены. Большую часть времени я предпочитаю решения, которые остаются сами по себе, которые изолированы и не требуют каких-либо дополнительных зависимостей. Я стараюсь отдать предпочтение библиотекам, которые тестируются как на уровне, так и на местах. Я всегда стараюсь избегать добавления фреймворков или библиотек, которые слишком сложны для выполнения задачи. Например, я не использовал boost-библиотеки для «любой» реализации. Для этого требуется много файлов, чтобы заголовки заголовков были включены в путь include, и может быть больше зависимостей.

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

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

Answer 6

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

Answer 7

Похоже, что ваш коллега страдает от Not-Invented-Here Syndrome, что в целом было дискредитировано. (С другой стороны, Joel has an interesting piece that takes the other side.)

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

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

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

Answer 8

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

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

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

Answer 9

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

1. Я все мои сам, так как это единственный способ, которым я буду делать это правильно
2. I будет использовать Done компоненты, если это применимо, если я не буду буду писать это мой сам
3. Я буду использовать Done компоненты, если это применимо, если не я не буду делать это, так как это беспокоит, чтобы написать что-то с нуля

Answer 10

Writing ваша собственная реализация, безусловно, имеет свои преимущества перед повторным использованием готового m ade сторонний модуль:

• Характеристики соответствуют вашим потребностям точно. С готовым модулем это может быть не так.
• Существует маленький код, чтобы понять, насколько это возможно, так как реализация соответствует вашему делу. Это большое преимущество, когда вам нужно написать расширение, поскольку для понимания и модификации кода меньше кода.
• Оценка a ready made module is very занимает много времени. Кроме того, некоторые недостатки будут появляться только после широкого использования, когда слишком поздно переключаться на другой продукт.
• Расширение готового модуля вызывает большие коммуникационные издержки (обсуждения с разработчиками, поддерживающими готовый модуль). С другой стороны, разветвление кода не требует внимания, потому что вы не сможете воспользоваться преимуществами исправлений и расширений.
• Все предыдущие примечания предполагают, что готовый модуль с открытым исходным кодом. Я никогда не использовал бы закрытый модуль-источник, так как всегда было бы мало доступной документации.

Однако я не говорю, что повторное использование всегда плохое. В вашем примере анализа файла .ini я бы рекомендовал использовать парсер Boost Spirit, который позволяет с минимальным усилием определить синтаксический анализатор.