Blob


1 ## Методические рекомендации
3 Итак, допустим, вы убеждены и хотите дополнительных инструкций о том, как помочь движению. Это именно тот документ, что вам нужен. Первые два раздела — короткие и рассказывают о том, как вы можете помочь, не разрабатывая собственное ПО в рамках ТТ. Третий раздел содержит указания по максимальному упрощению ПО, в попытке сделать его Тривиальным.
5 ### Используйте ТТ, расскажите друзьям
7 Новые возможности бесполезны, если люди ими не пользуются. Правда в том, что вы способны всё поменять. Если вас не устраивает положение дел в какой-то области попробуйте программу ТТ. Если вы всё ещё не удовлетворены — вам будет намного проще поменять всё под свои нужды, так попробуйте это сделать! Видите недовольство своих друзей — расскажите им о ТТ. Если вы знакомы с разработчиками — расскажите им о ТТ. Если вы знаете людей, чьи цели сходны с вашими — расскажите им о ТТ, пусть предложат свой вариант.
9 Дополняйте список известного ПО, работающего в согласии с духом Тривиальных Технологий. Присылайте собственные патчи к странице pages/rocks.gmi администраторам известных вам зеркал ТТ.
11 ### Держите Зеркала
13 ТТ по своей сути Тривиальны. Они не могут быть централизованы. Например, этот экземпляр (оригинальный он или нет) всего лишь зеркало. Ваше зеркало может содержать изменения, делающие его более пригодными для ваших нужд или нужд вашего сообщества. Всё это доступно под Unlicense, так что вам нет нужды беспокоиться о том, что вы делаете с идеей. Вот ряд рекомендаций по процедуре зеркалирования:
15 * Скопируйте исходники (через git или просто как текстовые файлы).
16 * Измените template/footer.gmi, добавив туда ваши контактные данные в качестве сопровождающего.
17 * Внесите изменения на своё усмотрение, соберите (./build.sh) и разместите результат в сети.
19 ### Создавайте Тривиальное ПО
21 Первый шаг прост — вы должны пожелать, чтобы ваш проект был Тривиальным. Если у вас есть подобное желание, вставьте фразу об этом в README, заявляя миру, что ваш проект стремится достичь стандартов движения ТТ, и ссылку на зеркало по вашему выбору (ссылка должна вести на страницу "Добро пожаловать"). Всё остальное не имеет большого значения, если вам удастся достичь указанных стандартов. Ведь всё остальное — не более, чем рекомендации.
23 * Ваши коммиты должны быть минимальными и объяснять причину вносимых изменений.
24 * Оставляйте комментарии в местах существенных изменений.
25 * Всё, что объявлено глобально, должно быть read-only для всех модулей, в которых оно объявлено. Изменения вносятся в стиле библиотек или в main. В этом случае указывайте на это в комментариях.
26 * Функции и типы должны быть логичными и ограниченными. Ни в коем случае не создавайте функцию, делающую множество вещей.
27 * Минимизируйте количество аргументов. Если у функции 10 аргументов — проверьте, почему их столько и не стоит ли их перегруппировать в reusable type.
28 * Минимизируйте вложенность и потоковые функции. Поддерживайте несколько уровней отступов. Если вам нужно настраиваемое поведение, подумайте о map/reduce и о visitor pattern. Функции высшего порядка хороши, если их использование понятно.
29 * Поддерживайте файл NEWS. Он должен быть последовательным и содержать только изменения, видимые пользователю.
30 * Поддерживайте файл READING. Он должен содержать информацию о том, как читать исходники, в каком порядке и мягко помогать читателю разобраться в вашей программе.
31 * Минимизируйте объём и ограничения лицензии в файле LICENSE, так как полное понимание этого файла — часть понимания вашего проекта. Мы рекомендуем Unlicense и 0BSD.
32 * Минимизируйте количество "мета-работы". Проект, использующий CMake, требует от читателя понимания CMake. Это лишнее переключение контекста сильно увеличивает сложность понимания проекта, особенно, когда мета-работа разрастается до сотен строк. Предпочитайте либо очень малый объём мета-работы (простой Makefile или скрипт) или языки, не требующие оной (например Go, где вся дополнительная работа сводится к build-flags, число которых должно быть минимальным).
33 * Добавляйте только те функции, которые используете лично вы. Вместо добавления всех фишек — просто оставьте открытые места, где каждый сможет расширить функциональность под себя. Если вы не используете какую-то фичу сами, вы не знаете, как другой может захотеть её использовать, так что просто позвольте им сделать это самим, для их собственных нужд.