Лучший способ ознакомиться с наследованной кодовой базой
Другое событие NullPointerException возникает, когда объявляется массив объектов, а затем сразу же пытается разыменовать его внутри.
String[] phrases = new String[10];
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
Этот конкретный NPE можно избежать, если порядок сравнения отменяется ; а именно, использовать .equals для гарантированного непустого объекта.
Все элементы внутри массива инициализируются их общим начальным значением ; для любого типа массива объектов, это означает, что все элементы null.
Вы должны инициализировать элементы в массиве перед доступом или разыменованием их.
String[] phrases = new String[] {"The bird", "A bird", "My bird", "Bird"};
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
11 ответов
Карандаш & Ноутбук (не получают отвлекающуюся попытку создать нетребуемое решение)
-
Делает примечания, когда Вы идете и занимаете час каждый понедельник, чтобы прочитать и расположить примечания с предыдущих недель
-
с большими кодовыми базами, которые могут обманывать первые впечатления, и проблемы имеют тенденцию перестраивать себя быстро при ознакомлении.
-
Помнят, что проблемы от Вашей последней рабочей среды не обязательно допустимы или релевантны в Вашей новой среде. Остерегайтесь предвзятых понятий.
-
примечания/наблюдения Вы составляете справку завещания Вы учиться быстро что вопросы спросить и кого. Надо надеяться, Вы собирали имена всего чиновника (и неофициальные) заинтересованные стороны.
Один из лучших способов ознакомиться с наследованным кодом состоит в том, чтобы пачкать руки. Запустите с исправления нескольких простых ошибок и проложите себе путь в более сложные. Это согреет Вас до кода лучше, чем попытка систематически рассмотреть код.
, Если существует требования или документ функциональной спецификации (который, надо надеяться, актуален), Вы должны читать его.
, Если существует документ высокоуровневого или детального проектирования (который, надо надеяться, актуален), Вы , вероятно, должны читать его.
Иначе должен расположить встречу "передачи информации" с людьми, которые знакомы с кодом, где они обеспечивают презентацию дизайна высокого уровня и также делают пошаговую демонстрацию важных/хитрых частей кода.
Запишите модульные тесты. Вы найдете бородавки более быстрыми, и Вы будете более уверены, когда время настанет для изменения кода.
Пробегитесь через оперативные библиотеки и прочитайте объявления функции. Если это - C/C++, это означает только заголовки. Документ вообще Вы не понимаете.
В прошлый раз, когда я сделал это, один из комментариев, которые я вставил, был "Этим классом, никогда не используется".
Мои шаги были бы:
1.) Устанавливают исходное понимание (или любой хороший браузер исходного кода, который Вы используете), рабочая область/проект со всем источником, заголовочными файлами, в кодовой базе. Browsly в более высоком уровне от самой верхней функции (основной) к самой нижней функции. Во время этого просмотра кода продолжайте делать примечания по статье/или документом слова, прослеживающим поток вызовов функции. Не входите в реализацию функции nitti-gritties на этом шаге, сохраняйте это для более поздние повторения. На этом шаге отслеживают то, какие аргументы передаются функциям, возвращаемым значениям, как аргументы, которые передаются функциям, инициализируются, как значение тех аргументов установило измененный, как возвращаемые значения используются?
2.) После одного повторения шага 1.), после которого у Вас есть некоторый уровень кода и структур данных, используемых в кодовой базе, установите MSVC (или любой другой соответствующий проект компилятора согласно языку программирования кодовой базы), скомпилируйте код, выполнитесь с допустимым тестовым сценарием, и одноэтапный через код снова от основного до последнего уровня функции. Промежуточный вызовы функции продолжают отмечать, что значения переданных переменных, возвратились, различные пути выполнения кода взятые, различные пути выполнения кода, которых избегают, и т.д.
3.) Продолжают повторяться 1.) и 2.) в многократно, пока Вы не удобны в какой-то степени, что можно измениться, некоторые кодируют/добавляют, некоторые кодируют/находят ошибку в exisitng, кодируют/устраняют ошибку!
- AD
Действительно попытайтесь понять код путем исправления ошибок в нем. Действительно исправьте или поддержите документацию. Не изменяйте комментарии в самом коде, который рискует представлять новые ошибки.
В нашей строке работы, вообще говоря, мы не делаем никаких изменений в производственном коде без серьезного основания. Это включает косметические изменения; даже они могут представить ошибки.
, Неважно, как отвратительный раздел кода кажется, не испытывайте желание переписать его, если у Вас нет bugfix или другого изменения, чтобы сделать. Если Вы определяете ошибку (или возможную ошибку), читая код, пытающийся изучить это, записываете ошибку для более поздней медицинской сортировки, но не пытаетесь зафиксировать его.
Одна вещь vi и emacs пользователи могут сделать, использовать теги. Теги содержатся в файле (обычно называемые ТЕГИ). Вы генерируете один или несколько файлов тегов командой (завершающие теги для emacs vtags для vi). Затем мы, Вы редактируете исходный код и Вы видите запутывающую функцию или переменную, Вы загружаете файл тегов, и это возьмет Вас туда, где функция объявляется (не прекрасная достаточно хорошим). Я на самом деле записал некоторые макросы, которые позволяют Вам переместиться по источнику с помощью Alt-cursor, вида подобного popd и pushd во многих разновидностях UNIX.
BubbaT
Я не знаю об этом являющемся "лучшим способом", но чем-то, что я сделал в недавнем задании, должен был записать паука/синтаксический анализатор кода (в Ruby), который прошел и создал дерево вызова (и обратное дерево вызова), который я мог позже запросить. Это было немного нетривиально, потому что у нас был PHP, который назвал Perl который названным функциями/процедурами SQL. Любые другие проверяющие код инструменты помогли бы в подобном виде (т.е. javadoc, rdoc, perldoc, Doxygen и т.д.).
Чтение любых модульных тестов или спецификаций может быть довольно поучительным.
вещи Документирования помогает (или для себя, или для других товарищей по команде, нынешних и будущих). Прочитайте любую существующую документацию.
, Конечно, не недооценивайте питание простого выяснения у такого же товарища по команде (или Ваш босс!) вопросы. Вначале, я спрашивал так же часто по мере необходимости, "у нас есть функция/сценарий/нечто, которая делает X?"
Попытайтесь понять бизнес-логику позади кода. После того как Вы знаете, почему код был написан во-первых и что он, как предполагается, делает, можно начать прочитывать его, или как кто-то сказал, пролил, исправляющий несколько ошибок тут и там
Первая вещь, которую я делаю перед потерей работоспособности в код, состоит в том, чтобы использовать приложение (в качестве нескольких различных пользователей, при необходимости), чтобы понять все технические возможности и видеть, как они соединяются (как информационные потоки в приложении).
После этого я исследую платформу, в которой было создано приложение, так, чтобы я мог сделать непосредственную связь между всеми интерфейсами, которые я только что видел с некоторым Представлением или кодом UI.
Затем я смотрю на базу данных и любой слой обработки команд базы данных (если применимо), чтобы понять, как та информация (которым управляют пользователи) хранится и как это переходит в и прибывает из приложения
Наконец после изучения, куда данные прибывают из и как это отображено, я смотрю на слой бизнес-логики, чтобы видеть, как данные преобразовываются.
я полагаю, что каждая архитектура приложения может de, разделенный как это и knowning полная функция (кто то, кто в Вашем приложении), могло бы быть выгодным прежде действительно отладить его или добавить новый материал - то есть, если у Вас есть достаточно времени, чтобы сделать так.
И да, это также помогает много говорить с кем-то, кто разработал текущую версию программного обеспечения. Однако, если он собирается покинуть компанию скоро, сохраните примечание по его списку пожеланий (что они хотели сделать для проекта, но не могли из-за бюджетных ограничений).
создайте документацию для каждой вещи, которую Вы изобразили из кодовой базы. узнайте, как это работает exprimentation - изменяющий несколько строк тут и там, и посмотрите то, что происходит. используйте geany, поскольку он ускоряет поиск наиболее часто используемых переменных и функций в программе и добавляет его для автоматического заполнения. узнайте, можно ли связаться с orignal разработчиками кодовой базы через Facebook или посредством поиска с помощью Google для них. узнайте исходную цель кода и посмотрите, соответствует ли код все еще той цели или должен быть переписан с нуля в выполнении намеченной цели.
узнают, какие платформы сделали использование кода, что сделали редакторы они используют для создания кода.
самый легкий способ вывести, как код работает, путем фактического тиражирования, как определенная часть была бы сделана Вами и перепроверкой кода, если существует такая часть.
это перепроектирует - выяснение чего-то, просто пытаясь повторно спроектировать решение.
у большинства программистов есть опыт в кодировании, и существуют определенные шаблоны, которые Вы могли искать, если это присутствует в коде.
существует два типа кода, объектно-ориентированного и структурно ориентированного.
, если Вы знаете, как сделать обоих, Вы хороши для движения, но если бы Вы не знакомы с одним или другим, необходимо было бы повторно изучить, как программировать тем способом понять, почему он был кодирован тот путь.
в ориентированном коде, которому возражают, можно легко создать схемы, документирующие поведения и методы каждого класса объекта.
, если это структурно ориентировано, подразумевая под функцией, создают документирование списка функций, что делает каждая функция и где это появляется в коде..
я не сделал ни одного из вышеупомянутых сам, поскольку я - веб-разработчик, относительно легко выяснить запуск от index.php до остальной части других страниц, как что-то работает.
goodluck.