Вы или ваша компания пытаетесь использовать код повторно? Если да, то как и на каком уровне , то есть низкоуровневом api, компонентах или общей бизнес-логике? Как вы или код повторного использования вашей компании?
Раньше я работал в кодовой базе с повторным использованием UBER-кода, но было трудно поддерживать, поскольку повторно используемый код был нестабильным. Он был склонен проектировать изменения и устаревания способами, которые каскадировались на все, используя его. До этого я работал в кодовой базе без повторного использования кода, когда пожилые люди действительно поощряли копирование и вставку, чтобы повторно использовать даже код приложения, поэтому я добрался до двух конечных элементов, и я должен сказать, что это не обязательно лучше, чем другие, когда принимаются до крайности.
И я раньше был программистом снизу вверх. Вы просите меня построить что-то конкретное, и я в итоге создаю обобщенные инструменты. Затем, используя эти инструменты, я создаю более сложные обобщенные инструменты, а затем начинаю создавать абстракции DIP, чтобы выразить требования к дизайну для инструментов нижнего уровня, затем я создаю еще более сложные инструменты и повторяю, и в какой-то момент я начинаю писать код, который на самом деле делает что ты хочешь чтобы я сделал. И как контрпродуктивный, как это звучало, я был довольно быстро в нем и мог поставлять сложные продукты таким образом, чтобы действительно удивлять людей.
Проблема была в обслуживании в течение месяцев, лет! После того, как я построил слои и слои этих обобщенных библиотек и использовал их из черных черт, каждый из них хотел использовать гораздо большую цель, чем то, что вы просили меня сделать. Каждый слой хотел решить голодные потребности мира. Итак, каждый из них был очень амбициозен: математическая библиотека, которая хочет быть потрясающей и решать голодные потребности мира. Затем что-то построено на вершине математической библиотеки, как библиотека геометрии, которая хочет быть потрясающей и решить проблемы голода в мире. Вы знаете, что что-то не так, когда вы пытаетесь отправить продукт, но ваш ум размышляет над тем, насколько хорошо ваша библиотека обобщенной геометрии работает для рендеринга и моделирования, когда вы должны работать над анимацией, потому что код анимации, который вы работаете на потребности несколько новых функций геометрии.
Балансировка Всеобщие Потребности
я нашел в разработке этих Uber-обобщена библиотеки, которые я должен был одержим с потребностями каждого члена команды, и я должен был узнать, как трассировка лучей работал, как динамика жидкости работали , как работает механизм сетки, как работает обратная кинематика, как работает анимация персонажей и т. д. и т. д. и т. д.Мне нужно было научиться делать почти всю работу в команде, потому что я балансировал все их специфические потребности в дизайне этих обобщенных библиотек uber, которые я оставил, ходя по базирующимся на противовес усилиям по дизайну компромиссов из всего повторного использования кода (пытается чтобы сделать работу лучше для Боба, работающего над raytracing, который использует одну из библиотек, но не причиняя слишком большого вреда Джону, который работает над физикой, которая также использует его, но не слишком усложняя дизайн библиотеки слишком, чтобы сделать их счастливыми).
Это дошло до того, что я пытался параметризовать ограничивающие прямоугольники с классами политики, чтобы их можно было хранить как в центре, так и в полуразмерном виде, как хотелось бы одному человеку или мин/макс, как и кто-то другой, и реализации был очень запутанным, пытаясь отчаянно идти в ногу со всеми нуждами.
Design By Комитет
И потому, что каждый слой пытается служить такой широкий спектр потребностей (гораздо шире, чем мы на самом деле нужно), они нашли много причин, чтобы потребовать изменений в конструкции, иногда комитет просил (которые обычно являются грубыми). И тогда эти изменения дизайна будут каскадироваться вверх и влиять на весь код более высокого уровня, используя его, и поддержание такого кода стало реальным PITA.
Я думаю, вы можете поделиться больше кода в единомышленников. Наш совсем не был единомышленником. Это не настоящие имена, но у меня бы был Билл, который является программистом высокого уровня и графическим редактором, который создает приятные пользовательские проекты, но сомнительный код с большим количеством хаков, но для этого типа кода он подходит. Я получил Боба, который является старым таймером, который программировал со времен эры перфорации, которому нравится писать 10 000 линейных функций с gotos в них и до сих пор не понимает объектно-ориентированного программирования. Я получил Джо, который, как математический мастер, но пишет код, который никто не может понять, и всегда делает предложения, которые математически выровнены, но не обязательно настолько эффективны с вычислительной точки зрения. Затем я получил здесь Майка, который находится в космосе, который хочет, чтобы мы портировали программное обеспечение на iPhone и думали, что мы все должны следовать соглашениям Apple и техническим стандартам.
Попытка удовлетворить все потребности здесь при разработке достойного дизайна была, возможно, ретроспективно невозможной. И у всех, кто пытается поделиться друг с другом кодом, я думаю, что мы стали контрпродуктивными. Каждый человек был компетентен в области, но пытался придумать проекты и стандарты, которые все довольны, просто приводят к любой нестабильности и замедляют всех.
компромиссы
Так в эти дни я нашел баланс, чтобы избежать повторного использования кода для вещей низшего уровня. Я использую подход сверху вниз с середины, возможно (что-то не то, что тоже далеко от того, что вы мне просили), и создайте там некоторую независимую библиотеку, которую я все еще могу сделать за короткий промежуток времени, но библиотека не собирается создавать мини-библиотеки, которые пытаются решить голодные потребности мира. Обычно такие библиотеки немного более узкие по назначению, чем более низкоуровневые (например, библиотека физики, в отличие от обобщенной библиотеки пересечения геометрии).
YMMV, но если есть что-то, чему я научился на протяжении многих лет в самых трудных случаях, это может быть балансирование и точка, где мы могли бы захотеть сознательно избегать повторного использования кода в команде в некоторых деталях чтобы отказаться от некоторой общности для кода самого низкого уровня в пользу развязки, имея гибкий код, который мы можем лучше сформировать, чтобы обслуживать более конкретные, а не обобщенные потребности и т. д. - возможно, даже просто позволить каждому иметь немного больше свободы делать что-то их собственным путем.Но, конечно, все это связано с тем, что все еще создается очень многократно используемая обобщенная библиотека, но разница в том, что библиотека не может разлагаться на самые младшие обобщенные библиотеки, потому что я обнаружил, что пересечение определенного порога и попытка сделать слишком много подростковые, обобщенные библиотеки начинают на самом деле становиться чрезвычайно контрпродуктивными усилиями в долгосрочной перспективе - не в краткосрочной перспективе, а в долгосрочной перспективе и широкой схемой вещей.
Если у вас есть кусок кода, который потенциально может быть распределено между организацией в среднего размера, как бы вы о информировании других членов компании, что Lib/API/и т.д. существовала и может быть в пользу ?
Я на самом деле я больше не хочу в эти дни и найти более простительно, если коллеги сделать некоторую лишнюю работу, потому что я хочу, чтобы убедиться, что код делает что-то достаточно полезное и нетривиальным и также очень хорошо проверенным и разработан прежде чем я попытаюсь поделиться им с людьми и накопить кучу зависимостей. У проекта должно быть очень мало причин, чтобы потребовать каких-либо изменений с этого момента, если я поделюсь им с остальной частью команды.
В противном случае это может вызвать больше горя, чем это фактически экономит.
Раньше я был так нетерпим к избыточности (в коде или усилиях), потому что он, казалось, переводил продукт, который был очень глючным и взрывным в использовании памяти. Но я слишком сильно увеличил избыточность в качестве ключевой проблемы, когда реальной проблемой было низкое качество, поспешно написанный код и отсутствие твердого тестирования. Хорошо проверенный, надежный, эффективный код не понесет эту проблему почти до такой степени, даже если некоторые люди дублируют, скажем, некоторые математические функции здесь и там.
Один из основополагающих вещей, на которые нужно обратить внимание и помнить, что я не был в то время, - это то, как мы не против некоторой избыточности, когда используем очень прочную стороннюю библиотеку. Скорее всего, вы, ребята, используете стороннюю библиотеку или две, у которых есть избыточная работа с тем, что делает ваша команда. Но мы не возражаем в тех случаях, потому что библиотека третьей стороны великолепна и хорошо проверена. Я рекомендую применить этот же настрой к своему внутреннему коду. Цель должна состоять в том, чтобы создать что-то потрясающее и проверенное, а не суетиться из-за избытка избыточности здесь и там, как я ошибочно сделал давно.
Так что в эти дни я переместил свою нетерпимость на недостаток тестирования. Вместо того, чтобы расстраиваться из-за излишних усилий, я считаю гораздо более продуктивным расстраиваться из-за отсутствия у других людей модульного и интеграционного тестирования! : -D
«Название статьи, о которой вы говорите ...« Я не имел в виду ничего, в частности, это звонит с чем-то, что вы читали раньше? Karl – Karl 2008-12-10 14:59:41
Второй результат, который вы видели в Google. «Повторное использование внутреннего кода считается опасным». Это технический документ, который я прочитал некоторое время назад. – 2008-12-10 15:45:26