Как вы позволяете другим доверять вашему коду и использовать его? - PullRequest
4 голосов
/ 11 сентября 2009

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


Спасибо всем, кто внес свой вклад. Я приложу все усилия, чтобы суммировать сказанное. Не стесняйтесь изменять список. Исправления и дополнения приветствуются:)

Ответы [ 8 ]

7 голосов
/ 11 сентября 2009

Получить блог, выпустить код через него. Объясните, почему вы это написали, какую проблему это решает. И поощряйте других улучшать его, сохраняйте код как можно более актуальным. Если ваши инструменты полезны, вы очень быстро разработаете следующее, которое «доверяет» вашему коду.

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

3 голосов
/ 11 сентября 2009

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

Также рассмотрите возможность использования сайта, на котором размещен проект (например, код Google или github).

2 голосов
/ 11 сентября 2009
  • Документация, объясняющая, почему вы ее написали, когда вы ее запустили, и ее предназначенная функция. Понимание того, откуда вы пришли, позволит мне увидеть будущие идеи, а также будущие идеи, которых вы, возможно, не видели.
  • Техническая документация, объясняющая API и некоторые примеры того, как его реализовать. В идеале, сохраняйте документацию в формате, соответствующем языку. Например, C # стремится использовать синтаксис XML для определения элементов. Это позволяет мне чувствовать себя как дома, когда я читаю это.
  • Чистый код - я не могу этого подчеркнуть, потому что слишком много людей пишут исключительно безобразный код. Если ваш код уродлив и / или нечитаем, мне будет проще написать его с нуля. Как минимум, сделайте ваш код непротиворечивым. Если я не могу понять код, я не буду чувствовать себя комфортно с ним.
  • Исторические записи, объясняющие ваши изменения. Видя, как вырос проект, я могу планировать лучше. Это также позволяет людям увидеть, как вы учитесь на своих ошибках и получить представление о вашем уровне квалификации. По сравнению с форумом вы можете почувствовать, как быстро все исправляется, а затем помещается в новый выпуск.
  • Задумайтесь над тем, какую лицензию вы хотите получить. Всеобщее достояние? BSD? GPL? Более строгий?
  • Примечание о том, против вас возражать или нет, и есть ли какие-либо ограничения в этом. Например, вы не возражаете против обновлений? Мне объясняют дыры в безопасности? Или, может быть, вы используете форум или вики?
  • Возможность получить ваши последние работы и / или ночные сборки. SVN или что-то. Это полезно, так что я знаю, если найденная ошибка уже исправлена.
2 голосов
/ 11 сентября 2009
  1. Имейте четкую лицензию с вашим кодом, если у вас его еще нет (желательно тот, который поощряет изменение / улучшение / совместное использование вашего код ...)

  2. Публичный контроль версий и / или общедоступный трекер ошибок / проблем и / или список рассылки. Есть много хороших сайтов, которые предлагают эти услуги бесплатно.

  3. Отдельная документация не является для меня решающим фактором (если код хорошо документирован и качество кода высокое).

1 голос
/ 11 сентября 2009

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

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

1 голос
/ 11 сентября 2009

Публикация в репозитории с открытым исходным кодом, таком как code.google.com или sourceforge.net, вероятно, с чего начать ...

Далее, чтобы привлечь внимание, четко и кратко документируйте назначение библиотеки / приложения, как указано в одном из ответов выше.

Наконец, ведутся блоги и прямой почтовый обмен ...

1 голос
/ 11 сентября 2009

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

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

1 голос
/ 11 сентября 2009

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

В документе должно быть указано:

  • какова цель вашей библиотеки
  • каковы основные характеристики
  • a действительно короткое руководство, чтобы запустить его за 5 минут.
  • Множество примеров
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...