Кращі / погані практики спільного використання коду? [зачинено]


9

Чим більше я досліджую Github , тим більше мені подобається. Мені дуже подобається, як кодування стає більш соціальним.

Мені цікаво, чи є якісь погані практики, яким програмісти повинні уникати спільного використання коду між собою. І називаючи погані практики, які найкращі практики для спільного використання коду ?

Наприклад:

Чи поганою практикою для одного репо є наявність декількох сценаріїв / проектів під назвою "MiscProjects" ? Де ця репо, як випливає з назви, - це сукупність різноманітних невеликих сценаріїв та проектів. Це може нагадувати, як програміст організовує проекти на своєму локальному сховищі, але це можливо не оптимально для спільного використання коду?

Можливо, якщо буде зроблено хорошу README / документацію, було б краще? Або поки це добре документально підтверджено, що-небудь іде?

Відповіді:


9

Хоча немає жодних «поганих практик», встановлених у камені, як і в інших системах управління версіями, існують конвенції .

Ваше Git repo має бути якомога менше. Якщо ви надходите з модуля CVS / SVN, зазвичай було структуроване єдине сховище, яке могло б скласти кілька сховищ для ряду проектів. Спосіб Git полягає в тому, щоб розділити їх і мати окремі репортажі Git для кожного проекту. Причини:

  • Git швидше для менших репостів.
  • Завдяки своїй конструкції кожна операція впливає на всю репо . Неефективно виконувати операції Git над необхідними проектами, якщо ви працюєте лише над одним із них.

Документація, як завжди, є обов'язковою. Хоча люди вмілі читати код, ніхто не хоче тлумачити код більше, ніж потрібно. Використання README вищого рівня для опису проекту та структури репортажу Git завжди буде хорошою справою для тих, хто бере участь (або прагне долучитися) до проекту.

Більшість проектів на GitHub відповідають конвенціям. Використовуйте їх як приклади для структури своїх майбутніх проектів.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.