Вещи, которые вы ищете, пытаясь понять новое программное обеспечение - PullRequest
0 голосов
/ 15 ноября 2010

Интересно, что вы ищете, когда начинаете работать над существующей, но новой для вас системой? Допустим, система довольно большая (что бы это ни значило для вас).

Некоторые из идентифицированных вещей:

  1. Где вызывается определенная подпрограмма или процедура?
  2. Каковы аргументы, результаты и предикаты конкретной функции?
  3. Как поток управления достигает определенного места?
  4. Где конкретный набор переменных, используется или запрашивается?
  5. Где объявлена ​​конкретная переменная?
  6. Где осуществляется доступ к конкретному объекту данных, т.е. создание, чтение, обновление или удаление?
  7. Что такое входы и выходы конкретного модуля?

Но если вы ищете что-то более конкретное или какой-либо из перечисленных выше вопросов особенно важен для вас, поделитесь им с нами:)

Меня особенно интересует то, что можно извлечь из динамического анализа / выполнения.

Ответы [ 2 ]

1 голос
/ 17 ноября 2010

Возникает вопрос, какая у меня мотивация для изучения новой системы:

  1. Исправление ошибки / незначительное улучшение - в этом случае я могу сосредоточиться исключительно на той части системы, которая выполняет определенную функцию, которую необходимо изменить. Это способ сломать огромную систему, но также и способ определить, является ли проблема тем, что я могу решить, или это то, что я должен передать готовой компании, программное обеспечение которой мы используем, например. Система CRM, CMS или ERP может быть настроенной готовой системой, поэтому в ней много компонентов.

  2. Работа над проектом - это был бы другой случай, и я бы, вероятно, попытался построить себе вид с высоты около 30 000 футов, чтобы узнать, что представляют собой компоненты высокого уровня и какие области системы выполняет влияние проекта. Примером этого является то, что я присоединяюсь к компании и работаю над существующей кодовой базой, но у меня нет такой роскоши, как в небольшом фокусе, как в предыдущем случае. Часть этого представления заключается в поиске любых шаблонов в коде с точки зрения соглашений об именах, структуры проекта и т. Д., Поскольку это может быть полезно, когда я начну изменять какой-то код в системе. Я, вероятно, проведу некоторую трассировку в системе и попытаюсь увидеть, где находятся более уродливые части кода. Под уродливыми я подразумеваю те части, которые похожи на клуджи и могут иметь некоторый код для спагетти, так как он был спешен при первой записи и сейчас подвергается серьезной переработке.

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

1 голос
/ 15 ноября 2010

Мне нравится использовать подход "варианта использования":

  1. Сначала я задаю себе вопрос: «Какова цель этого программного обеспечения?»: Я пытаюсь определить, как пользователи будут взаимодействовать с приложением;
  2. Как только у меня появляется «сценарий использования», я пытаюсь понять, какие объекты более вовлечены и как они взаимодействуют с другими объектами.

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

...