Большой проект на С. Как строить работу чтобы не завалило кодом?

Вопрос для общего развития.

Знакомый работает в проекте на чистом C (в команде разумеется). Количество строк около 1 000 000 ИМХО не очень удобное для чистого С количество строк.

Как бы вы вели работу над таким проектом?
ЗЫ Сразу оговорюсь вопрос скорее теоретический.
  • Вопрос задан
  • 1006 просмотров
Решения вопроса 3
@koronabora
Человек
1) Разбиваем по категориям, каждую категорию - в свою папку. Если надо - еще подпапки.
2) Общий или старый код вынести в библиотеку, подключать только .h + .lib
3) Использовать систему контроля версий.
4) Ввести лимит по количеству строк на файл, перераспределять код таким образом, чтобы в одном .c файле было не больше 1000 строк (имхо даже 500 на с уже много. )
Ответ написан
Комментировать
Декомпозировать проект на несколько проектов с независимой разработкой и документированным API.
В случае серверной системы - разбить на несколько независимых взаимодействующих сервисов, что, кроме всего прочего, еще и упростит горизонтальное масштабирование и переход к высоким нагрузкам.
Выделить в отдельную разработку отдельные компоненты и библиотеки, для упрощения интеграции и сборки можно сделать библиотеки динамическими/разделяемыми.

Это потянет за собой новые проблемы и необходимость содержать системного архитектора, но рано или поздно все равно потребуется при таком объеме кода.
Ответ написан
Комментировать
@abcd0x00
По самому проекту тебе ответил уже Владимир Дубровин, а вот по малой части надо стремиться к декомпозиции (разложению) на исполнители.

В одном .h файле описываешь интерфейс объекта, например, стека
void stack_start();
int stack_push(int value);
int stack_pop();
int stack_isempty();
int stack_topr();
int stack_topw(int value);
void stack_del();
void stack_end();

Дальше в .c файле пишешь реализации этих методов (сами функции и статические (закрытые в файле) переменные, которые им нужны для внутренней работы). И потом, чтобы подключить стек, ты просто подключаешь его .h файл и используешь эти методы.
(Это пример; на самом деле, делается набор методов, который можно применять к разным стекам, где соответствующий стек (структура) просто передаётся в метод первым аргументом.)

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

Тогда всё будет чисто, это всё можно будет тестировать ясными unit-тестами, можно будет легко выделять такую часть и заменять на другую и, самое главное, можно будет сами эти методы также декомпозировать дальше, так как не всегда они просто устроены, как в примере со стеком.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 4
@vilgeforce
Раздолбай и программист
Я бы разбивал кодес на отдельные файлы в зависимости от функций. Ну и Doxygen, ясное дело.
Ответ написан
Комментировать
heksen
@heksen
Разбивать по файлам. Использовать теги в названиях функций.
Ответ написан
Комментировать
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
ООП: функции, классы, библиотеки!
Ответ написан
@iv_k
документировать с использованием UML
не прямо до класса и функции, а хотя бы общий скелет и поведение.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы