Какой код является кандидатом на повторное использование?

Question

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

На мой взгляд, есть две причины для написания повторно используемого кода в бизнесе; 1) Поделитесь внутри компании, чтобы повысить скорость и эффективность в будущем. 2) Публиковать в Интернете, а другие люди помогут улучшить код (толчок-источник в некотором смысле).

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

Мои первоначальные мысли: Не стоит писать повторно используемый код на самых низких уровнях (например, у меня есть встроенный код, который добавляет «'s» к концу строки), было бы слишком большая часть этого кода даже просеивается и обнаруживает, что кто-то уже это сделал. Также не стоит писать повторно используемый код на самом верхнем уровне, то есть приложение, потому что ваше приложение для отчетности клиентов в конечном итоге будет генерироваться в SQL-клиент - бесполезно для большинства пользователей.

Основные препятствия для использования повторно используемого кода: вы не можете повторно использовать его, если не знаете, что он существует; Доверие. Это сделано, но доверяете ли вы этому ?; Первоначальное время, затрачиваемое на то, чтобы сделать код общим/повторно используемым (и документировать его).

Answer 1

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

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

Следовательно, я не склонен рассматривать код как многоразовый, если он действительно не был повторно :-)

Answer 2

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

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

Кроме того, вы можете прокомментировать все функции и типы и использовать такую ​​систему, как Doxygen (или Javadoc), а затем автоматически генерировать документацию, которая сделает ее доступной для поиска даже вне IDE и будет представлена ​​несколько приятным образом.

Answer 3

Я хотел бы повторно использовать и постоянно поддерживать/рефакторинг:

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

я бы выбросить (удалить из ВСМ) и переписать с нуля:

• любая библиотека, которая плохо написана; который пытается выполнить несколько задач и делает все это плохо
• клиент к сервису, когда услуга полностью переписана, изменена другой технологией (база данных изменена с помощью веб-службы)
• бизнес-уровень/модель, когда она больше не работает служит ничего
• интерфейса, когда клиент хочет серьезные изменения, или при переключении на другую рамку

Answer 4

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

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

Вы сделал есть блок-тесты, не так ли?

Answer 5

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

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

Главное - сделать хорошее различие, где должен быть код. Чтобы взять пример «добавить« s »к строке, это может быть код, который помещается где-то в библиотеку с указанием строк, а также« добавить «h» в строку »и« добавить «b» в функции строки. Когда вы видите эти три функции вместе, вы, вероятно, получите идею создания более общей функции «добавить любой символ в строку», что сделает код еще более многоразовым - вы также можете добавить букву «r» к строке Теперь!

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

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

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

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

Если пример был написан для повторного использования, вы можете использовать его снова во втором проекте, экономя время и усилия. Кроме того, дополнительные функции, которые задает ваш следующий клиент, вероятно, могут предложить первый клиент в качестве обновления - (см., Вы можете установить высоту и ширину сейчас, woohoo!)

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

Answer 6

в Германии, мы говорим: истина лежит в середине

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

Другая крайность - это общий клиент SQL. Разумеется, повторное использование не должно возлагать на пользователя никаких надержек. Это окончательное нет-нет!

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

• Будете ли вы прилагать дополнительные усилия (см. Ниже)? (3-7 лайнеров!)
• Оказывает ли это дополнительную нагрузку на пользователей и/или пользователей?
• Как часто это будет использоваться повторно (оценено)
• Могу ли я решить сейчас? (У вас может не хватить опыта прямо сейчас, а затем лучше задержать его и реализовать некоторые прецеденты как автономные, прежде чем сделать их многоразовыми)
• Могу ли я действительно обобщить все подробности, которые могут быть у меня, линия? Особыми случаями могут быть смерть повторного использования ...

Вы можете найти дополнительные факторы. Я хотел привести некоторые примеры adhoc.

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

Также необходимо дополнительное усилие:

Это действительно главное, многие люди забывают. Повторное использование не бесплатное! Вы должны заплатить за это.

У вас есть дополнительные расходы на:

• Extra догадываясь, как сделать это действительно универсальный
• Extra-Запрашиваемые все потенциальные потребители
• Extra-Документирование, так как потребители будут использовать только его, когда он действительно прост в использовании
• Экстра-реклама, поскольку потенциальные потребители должны знать, что существует что-то многоразовое, и это целесообразно повторно использовать.

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

Итак, к нему прилагается ценник. Но это стоит, когда вам удастся действительно заплатить цену!

Answer 7

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

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