Как Вы удостоверяетесь, что код снова используется правильно? [закрытый]
Вы могли использовать генетический алгоритм для этого. При определении "кластера" как, скажем, прямоугольная подобласть с высокой точечной плотностью Вы могли создать начальный набор "решений", каждое из которых состоит из некоторого количества случайным образом сгенерированных, неперекрывающихся прямоугольных кластеров. Вы тогда записали бы "функцию фитнеса", которая оценивает каждое решение - в этом случае, Вы хотели бы, чтобы функция фитнеса минимизировала общее количество кластеров при максимизации точечной плотности в каждом кластере.
Ваш начальный набор "решений" все будет ужасен, скорее всего, но некоторые, вероятно, будут немного менее ужасными, чем другие. Вы используете функцию фитнеса для устранения худших решений, затем создаете следующее поколение решений путем скрещивания "победителей" от последнего поколения. Путем повторения этого поколения процесса поколением необходимо закончить с одним или несколькими хорошими решениями этой проблемы.
Для генетического алгоритма для работы, различные возможные решения пространства задач должны инкрементно отличаться друг от друга с точки зрения того, как хорошо они решают проблему. Точечные кластеры идеально подходят для этого.
7 ответов
У нашей команды есть ряд полезных библиотек, которые мы используем на протяжении всей разработки. Эти библиотеки хранятся в общем репозитории по принципу «открытого исходного кода». Есть один человек, который наблюдает за каждой библиотекой (или несколькими библиотеками), и разработчики могут отправлять исправления.
Затем библиотеки выпускаются / создаются в общем месте (мы развертываем на веб-сервере), откуда люди могут затем загрузить их и использовать в каком бы проекте они ни хотели. Пока что это работает довольно хорошо. Единственное, чего нам нужно остерегаться, это если есть изменение API, мы должны убедиться, что все это понимают. Мы делаем это с помощью номеров версий и информации в нашей библиотечной вики.
Edit: Кроме того, мы публикуем сгенерированные документы для наших библиотек (Javadoc, Crystal Report и т. Д.), Чтобы разработчики могли их использовать.
Мы команда .Net, так что это сработало для нас ...
Мы создали нашу собственную библиотеку классов для функций, которые, по нашему мнению, будут широко использоваться. Такие вещи, как вычисление контрольной цифры Luhn Mod 3, создание регулярного выражения для проверки адреса, который впишется в поле базы данных, состоящее из n символов и т. Д. Хитрость заключается в том, чтобы распознать код, который может быть повторно использован и получить его там. И держите его организованным.
Исходя из полного отсутствия опыта в этом вопросе, идеальной ситуацией, вероятно, является создание общей системы контроля версий между командами. Затем, после нескольких начальных организационных встреч и встреч, относитесь к общему хранилищу как к проекту с открытым исходным кодом, в который люди могут внести свой вклад. Итак, рассмотрим пару случаев:
Вы пишете код для совместного использования : для этого требуется создать новую область в хранилище для кода, добавить базовую документацию, тесты, очистить код и т. Д. .но есть стимул делать это правильно, если он считается «публичным».
Вы хотите использовать код хорошего качества : Звучит как хорошая библиотека, но есть несколько ограничений. Вы добавляете дополнительную документацию, тесты, дополнительные функции и так далее.
Вы хотите использовать код, но это чушь : Вам нужно поговорить с оригинальными разработчиками. Затем сделайте серьезную переработку кода, но это все же немного лучше, чем изобретать колесо. Обе команды выиграют, когда вы закончите.
Уловка состоит в том, чтобы сделать все достоянием общественности. Таким образом, вам нужны чемпионы в каждой команде, чтобы подтолкнуть людей к повторному использованию и внесению вклада. Это то, что вы получаете от начального раунда встреч. Если предположить, что модель с открытым исходным кодом - проверенная практика, нет причин, по которым она не может работать, если у вас есть чемпионы.
что вы получаете от первого раунда встреч. Если предположить, что модель с открытым исходным кодом - проверенная практика, нет причин, по которым она не может работать, если у вас есть чемпионы. что вы получаете от первого раунда встреч. Если предположить, что модель с открытым исходным кодом - проверенная практика, нет причин, по которым она не может работать, если у вас есть чемпионы.Проверьте свои предварительные условия с помощью утверждений.
Кроме того, подумайте о некоторых модульных тестах, чтобы убедиться, что ваш код достаточно надежен для работы в необычных или непредвиденных ситуациях.
В остальном, убедитесь, что все действительно понимают, что делает код, по крайней мере, на уровне черного ящика. Проведите короткую встречу с доской и займитесь парным программированием, как только людям придется начать использовать новый для них код.
Мы - команда разработчиков Java, и то же самое относится к нам. Мы создали служебные проекты в нашей SVN под различными заголовками, например, синтаксический анализ XML, векторная обработка, и повторно используемый код регистрируется в этих служебных библиотеках и повторно используется в других проектах.
Просмотрите книгу о передовых методах работы с вашим языком программирования. Примените их и посмотрите, что работает, и адаптируйте соответственно. В основном хороший, чистый и лаконичный интерфейс / api имеет большое значение. Также напишите множество модульных тестов для охвата различных функций. Также взгляните на встроенные библиотеки на вашем языке / платформе или поищите хорошие примеры библиотек и посмотрите, каковы их интерфейсы.
Используйте SOLID и держите код в чистоте. Проверьте: http://www.lostechies.com/content/pablo_ebook.aspx
Если вы видите что-то, что, вероятно, будет реализовано, спросите группу. Всегда помните о своих знаниях о предыдущих проектах, если вы знаете, что в проекте x есть эта функция, начните с нее;)
Повторное использование важно и также позволяет избежать дублирования, особенно когда вы работаете с одним и тем же продуктом /, возможно, даже с подсистемой. Его важно всегда искать, но не позволяйте этому мешать прогрессу в проектах.