Как разработчик, мы каждый день имеем дело со словами, файлами, каталогами. Вы не хотите, чтобы ваша кодовая база испортилась так же, как вы делаете это с архитектурой кода, стилем или самим кодом.
В книге Как работает Google сказано: Беспорядок — это добродетель (стр. 38). Дело не в том, что вокруг нас что-то аккуратно, а в том, как мы делаем что-то аккуратно. Если у вас нет четкого способа организации, возможно, вы попали в нужное место.
Способ ниже вдохновлен настройкой GOPATH на Голанге.
Поместите весь свой код в одно место
Я предпочитаю ~/src. Это ясно и указывает на домашний каталог пользователя, поэтому у вас есть все права доступа rwx.
Классифицировать свой проект
Предполагая, что у вас есть 4 типа проектов, {} является заполнителем.
- Проект компании: ~/src/{example.com}/{project}
- Проект сообщества: ~/src/{example.org}/{project} или ~/src/github.com/{organization}/{project}
- Личный проект: ~/src/github.com/{you}/{project}
- Тестирование проекта foo bar: ~/src/foo-bar/{project}
Примечание. Я настоятельно рекомендую вам выбрать github.com(или альтернативы) в качестве корневого пути личного проекта. Мне знакомо чувство, когда пишешь что-то классное и хочешь поделиться с другими. Это называется социальным кодированием и тем, что сегодня делает хорошее программное обеспечение. Однако, если вы не хотите открывать исходный код, просто оставьте его там и не публикуйте.
Что если я клонирую проект из удаленного репозитория?
То же самое, предположим, что автор или сообщество по имени Боб помещает его в ~/src/github.com/Bob/{project}.
Бонус
После того, как вы соберете проект из ~/src и выведете исполняемые файлы, поместите его в ~/bin, если у вас нет других веских причин. То же самое касается var, usr, pkg, lib и т. д. Будьте хорошим гражданином в мире *Nix.
Если вы пишете код Go и устанавливаете GOPATH в ~/src, все ваши артефакты сборки будут видны в ~/bin, это нормально, не так ли?
Наконец, в этой статье нет правил, а есть несколько личных предложений. Спасибо за чтение, удачного взлома!
