توثيق البنية القديمة ورسم خريطتها

Legacy Objective-C projects accumulate years of undocumented decisions. Mapping the architecture first prevents you from breaking hidden dependencies.

• Reveals coupling between modules
• Surfaces dead code and unused classes
• Builds a shared mental model for the team

Start with the build settings. List every target, scheme, and configuration. A single legacy app often hides several targets sharing source files.

Note which files belong to which target to avoid surprises when you refactor.

Build a class catalog. For each @interface, record its responsibilities and collaborators.

Follow each #import to draw a dependency graph. Watch for cycles where two classes import each other.

• Circular imports signal tight coupling
• God classes import nearly everything

Find the app entry points: main.m, the AppDelegate, and any storyboard or XIB roots. These anchor your map.

Document how data enters, transforms, and persists. Trace a single user action from UI tap to network call to disk write.

This vertical slice reveals the real architecture better than any diagram.

Use version-control history to find files changed most often. Frequently edited files are usually fragile and central.

Legacy code embeds assumptions: hardcoded endpoints, magic numbers, platform versions. List them explicitly.

Keep the map in source control as a Markdown or text file. A living document updated with each PR stays accurate; a one-off slide deck rots.

Mark areas that are risky to change: code with no tests, threading-heavy sections, and singletons holding global state.

• No tests = high regression risk
• Singletons = hidden global coupling

A map only helps if the team reads it. Walk new contributors through the diagram and let them correct it. Collective ownership keeps it honest.

You learned to inventory targets, catalog classes, trace dependencies, follow data flow, and keep a living architecture map. With this groundwork, modernization becomes deliberate rather than dangerous.