Как вы (физические и юридические лица) управляете своим источником, чтобы сделать его проще для повторного использования? Вы специально поддерживаете библиотеку повторного использования? И если да, то как вы индексируете его, чтобы максимизировать коэффициент попадания?
Я не и у меня есть правда спорный мнение здесь, но я считаю идею максимального повторного использования кода непродуктивным (я интерпретации «максимизации» в качестве приоритетов его выше всех других вещей, а не рассматривать его как имея как плюсы, так и минусы, чтобы сбалансировать их внимание). Вместо этого я предпочитаю, чтобы в командах было здорово компенсировать избыточные усилия, чтобы лучше разобраться и изолировать модуль каждого разработчика. Во-первых, прежде чем все начинает соглашаясь со мной слева и справа, я думаю, мы можем согласиться на некоторые вещи:
- Повторное использование глючный код, который будет у вас тратить часы отладки кода других людей не желательно.
- Повторное использование кода, который уравновешивает такой широкий спектр разрозненных потребностей, что он едва удовлетворяет ваши собственные потребности и требует от вас перепрыгнуть через множество обручей, чтобы в конечном итоге получить неудобное и неэффективное решение нежелательно.
- Повторное использование кода, которое постоянно требует изменений в дизайне и проходит через изъятия, которые потребуют от вас переписать код, используя его каждые 6 месяцев, является нежелательным, если вы могли бы просто реализовать решение самостоятельно через полчаса таким образом, t нуждается в изменениях в дизайне в будущем, поскольку он служит только вашим конкретным потребностям.
- Кодовая база, заполненная чужим кодом, нежелательна по сравнению с тем, который использует больше языка и стандартной библиотеки по идиоматическим и знакомым способам, даже если для этого требуется немного больше кода.
- Разработчики наступают друг на друга, потому что они хотят сделать несовместимые изменения одного и того же дизайна во время борьбы и споров и внесения изменений, которые вызывают ошибки в реализации друг друга, нежелательны.
- Бросание лодок зависимостей от незрелых конструкций, которые еще не доказали себя (не было тщательного тестирования, не было времени, чтобы действительно звукоизолировать дизайн и убедиться, что он эффективно удовлетворяет потребностям пользователя без каких-либо дополнительных изменений конструкции) нежелательно ,
- Необходимо включить/импортировать/связать лодку с библиотеками и классами/функциями с самым сложным сценарием сборки, чтобы написать что-то простое нежелательно.
- Прежде всего, повторное использование кода таким образом, который требует гораздо больше времени как в краткосрочном, так и в долгосрочном плане, чем повторное использование, нежелательно.
Надеюсь, мы сможем по крайней мере согласиться с этими вопросами. Проблема, которую я обнаружил с максимальным повторным использованием кода у чрезмерно восторженных коллег, заключалась в том, что она часто приводит к одной или нескольким проблемам выше. Это не было прямым энтузиазмом к повторному использованию кода, что было основной проблемой, но приоритеты были искажены в отношении повторного использования кода, а не для тестирования покрытия, создания звукоизоляции, убедившись, что все достаточно зрело, прежде чем мы повторно используем их как сумасшедшие и так далее.
Естественно, что если бы весь код, который мы использовали повторно, работал красиво, прошел тщательную проверку, было доказано, что оно удовлетворяет потребности всего, используя его способами, которые были гораздо более продуктивными, чем повторное использование, и не нужно было проходить через изменения дизайна в течение многих лет подряд, я был бы в восторге от повторного использования кода. Но мой опыт часто находил вещи, далекие от этого идеала, таким образом, когда повторное использование кода, вероятно, становилось проблемой обслуживания, а не решением.
Как вы (частные лица и организации) управляете своим источником, чтобы сделать его легче использовать? Вы специально поддерживаете библиотеку повторного использования? И если да, то как вы индексируете его, чтобы максимизировать коэффициент попадания?
Итак, я снова не пытаюсь «максимизировать» повторное использование кода среди проприетарного кода, написанного внутри команды. Я стараюсь, чтобы команда не тратила огромное количество времени на излишнее усилие, но я позволял вещам слабее, если и физики, и ребята-ребята реализуют собственный собственный класс ограничивающих полей, например. Это не обязательно даже избыточно, так как физик может использовать представления min/max, которые более эффективны для его цели, в то время как разработчик рендеринга может использовать представления центра/полуразмера. Я стараюсь убедиться, что мы по возможности используем как можно больше стандартной библиотеки, потому что это повторное использование кода, которое практически гарантировано, является прочным, ультра-проверенным и не требует дополнительных изменений дизайна (другие команды тратят лодку своего времени, чтобы убедиться в этом).
Вместо этого я сфокусирую внимание на тестировании. Модуль, дублирующий немного кода здесь и там, полностью прекрасен, если вы спросите меня, работает ли он красиво так, чтобы пользователи действительно были довольны, прошли тщательное тестирование и не гарантировали бесконечных изменений. Мы принимаем такое дублирование все время, когда используем сторонние библиотеки, которые, вероятно, дублируют код, который мы также имеем в нашей внутренней кодовой базе. Это не проблема, когда избыточность не приводит к избыточным усилиям по обслуживанию.
Так что я предлагаю просто немного успокоить идею максимизации повторного использования кода. Но если вы хотите сделать все возможное, чтобы повторно использовать действительно прочный, проверенный, нетривиальный код, то я нашел гораздо более полезным организовать очень уникальные библиотеки, такие как «математическая» библиотека, библиотека обработки изображений и т. д. - вместо того, чтобы пытаться объединить их все в нечто вроде «основного» или «общего». Последние типы склонны заставлять разработчиков бросать все виды эклектичных функций полезности, которые едва ли приносят пользу команде, использующей их, и в основном она становится грязной, когда становится трудно найти что-либо интересное.
Хорошие имена для рефакторинга. Не там, откуда оно взялось, или что оно делало, или где оно используется в настоящее время, но что это ДЕЙСТВИТЕЛЬНО. – 2008-09-28 13:26:09