Запуск персонального reuasable репозитория кода
Я означал запускать библиотеку отрывков повторно используемого кода некоторое время и никогда, казаться, не вернуться к нему. В данный момент я просто склонен иметь некоторые переходные классы/файлы, которые я перетаскиваю из старых проектов.
Я думаю, что мои основные проблемы:
С чего начать. Какую структуру мой репозиторий должен взять? Это должна быть скомпилированная библиотека (в соответствующих случаях) или просто классы/файлы, я могу заскочить в какой-либо проект? Или проект библиотеки, который может быть включен? Каковы последствия лицензирования этого?
По моему опыту, создал/уменьшил библиотеку, быстро станет устаревшим, и источник потеряется. Таким образом, я склоняюсь к источнику, который я могу экспортировать из SVN и включать в любой проект.
Интеллектуальная собственность. Я нанимаюсь, таким образом, много кода, который я пишу, не является моим IP. Как я могу удостовериться, чтобы я не давал свой собственный IP далеко с помощью него на проектах в работе и дома? Я думаю, что лучший способ состоял бы в том, чтобы лицензировать мою библиотеку с лицензией Open Source и удостовериться, что я только добавляю к нему в свое собственное время с помощью моего собственного оборудования и поэтому удостоверяясь, что, если я использую его в работе, предполагают, что те же правила применяются, как будто я пользовался сторонней библиотекой.
Я пишу на многих различных языках и часто требовал бы двух или больше частей этой библиотеки.
Я должен посмотреть на реализацию нескольких шаблонных проектов и базового проекта для каждого из моих выбранных допускающих повторное использование компонентов и языков?
Кто-либо еще получил этот вид библиотеки и как Вы организуете и обновляете его?
4 ответа
Правило номер один. Если вы хотите использовать его для себя, не используйте его на работе и не работайте над ним на работе. Даже в этих условиях некоторые работодатели будут думать, что они владеют им, даже если вы работали над ним в течение того периода времени (календарного времени), который вы работали на них. Некоторые могут быть даже более смешными. Так что даже не упоминайте, что он существует.
При этом размещение ее под лицензией BSD на sourceforge может позволить вам использовать ее с вашим СЛЕДУЮЩИМ работодателем, при условии, что вы заранее разъясните основные правила - скажите им, что вы берете такую библиотеку и, возможно, что вы ее написали.
IANAL - я не юрист. Вы можете посоветоваться с одним из них.
Я предпочитаю работать над своим материалом в свое время и свои машины и просто никогда не упоминаю об этом. Затем, когда компании просят меня подписать одно из тех, что «все ваши вещи нам принадлежат», я убеждаюсь, что это не относится к домашним вещам - в некоторых случаях для этого потребовалось внести поправки. Даже в этом случае, если бы я хотел использовать код на работе, я бы беспокоился, что могу потерять право собственности, потому что некоторые из этих строк были размыты.
Не беспокойтесь о изобретении велосипеда. Они платят вам за написание программного обеспечения.И когда жизнь действительно начнется, у вас все равно останется меньше времени на хобби-программирование; -)
Как сказал Нил, многие детали реализации ответа зависит от вашего языка.
Тем не менее, вы делаете два очень важных замечания:
по очевидным причинам лучше иметь библиотеку в форме исходного кода даже для скомпилированных языков
Если вы хотите сохранить IP и использовать его вне работы, затем сделайте это на 100% вне работы, лицензия с какой-то очень разрешительной лицензией. Что-то вроде лицензии zlib может подойти.
Еще один момент - Вам будет лучше, если вы убедитесь, что ваш работодатель не возражает против использования этого кода !!! . Вы можете опубликовать его анонимно / под псевдонимом, если получить такое разрешение сложно / невозможно.
Я бы выбрал легкий подход:
- Используйте Git или Mercurial, возможно, с Dropbox, если вы не хотите размещать его на хостинге: вам нужен контроль версий независимо от того, что вы делаете, а распределенный контроль версий особенно идеален, если вы не планируете делиться; центральное хранилище не нужно
- Сохраняйте все, что вы используете. Не тратьте время на создание кода, потому что думаете, что будете использовать его позже; подождите, пока вы собираетесь написать его дважды, прежде чем добавлять какую-либо работу. Затем бросьте продублированную работу туда, и вы будете готовы, если это случится в третий раз.
- Сделайте каталог для каждого языка; вы не можете повторно использовать Java в Python, в конце концов
Вот одна структура каталога, которую вы можете попробовать:
+ src
| + python
| | + emailing
| | | // the source goes in here
| | + quick-profiling
| + java
| + c++
+ notes
// This may not be your thing, but it's a convenient place for them
Проблема с вашей идеей и с концепцией фрагментов кода в целом заключается в том, что она плохо работает, если в вашем фрагменте есть ошибка. Для подхода с использованием фрагментов вам нужно будет исправить ошибку в исходном коде всех приложений, которые использовали фрагмент. С другой стороны, если вы создаете двоичные библиотеки, вам просто нужно один раз исправить ошибку в коде библиотеки, протестировать ее там, повторно связать, запустить регрессионные тесты вашего приложения, и все готово. Вот почему профессиональные программисты ненавидят фрагменты кода.