Как сохранить код, поддерживаемый после выхода оригинального программиста

Скажите, если это проект из 10 человек, 2-3 из первоначального программиста ушли после того, как проект выпустил стабильную версию на некоторое время. Как сохранить код в этом случае?

Мое воображение просматривает код после того, как проект выходит на выпуск версии и продолжит просматривать его после? Может быть, разделить на 2-3 небольшие группы, и каждая группа просматривает часть кода. Таким образом, по крайней мере 3-4 человека знакомы с частью кода. Это работает? Как компании справляются с этой проблемой?

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

Ответ 1

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

Ответ 2

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

Ответ 3

Звучит из вашего вопроса, что вы пытаетесь увеличить свой проект " коэффициент шины". Разумным способом добиться этого является требование, чтобы каждый фрагмент кода получал несколько пар глаз, прежде чем он когда-либо появлялся в репозитории, или, по крайней мере, периодически просматривал каждый другой код, чтобы знакомы несколько разработчиков с другими частями кода. В дополнение к этому, необходимо потребовать, чтобы каждый отдельный класс и метод документировались с использованием Doxygen, Javadoc или какого-либо другого инструмента стандартной документации, а также требовали стандартного набора стандартов кодирования, которые приводят к тому, что код является интуитивным и понятным для разработчиков, которые никогда не видели его (например, требуя, чтобы имена классов были TitleCased, эти функции являются camelCased, эти имена являются описательными и понятными).

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

Ответ 4

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

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

Да, я знаю, что это большая работа. Но это отличный источник информации, когда это было сделано.

С уважением, Ян

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

Вам нужно начать писать документацию, создавать модульные тесты и публиковать javadocs.

Ответ 8

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

Другим преимуществом является модульные тесты на всю жизнь, они не покидают компанию:)

При проверке кода (по крайней мере, в важных разделах) люди меньше боятся поддерживать код, так как риск изменения кода снижается. Если кодер хочет изменить менее идеальный фрагмент кода, вы знаете, что как только unit test все еще проходит, все в порядке в мире.

Ответ 9

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

В любом случае, если у вас нет ошибок для исправления в этом связанном коде, я не думаю, что есть что беспокоиться.