A two-thousand-line grab-bag module talks to Webex, Firepower FDM, and a spreadsheet for a city helpdesk app. What structure improves maintainability?
Select an answer to reveal the explanation.
Short Explanation
A junk drawer the size of a garage is where tools go to vanish. Small units named for Webex, FDM, or the sheet they own let a later engineer change one hop without fear. Maintainability is structure, not one mega-file.
Full Explanation
A two-thousand-line grab-bag that talks to Webex, Firepower FDM, and a spreadsheet is a maintainability hazard for a city helpdesk app. Prefer small named modules that each own one integration hop: clear boundaries, clearer tests, and safer change. Engineers can update FDM auth without risking Webex notification paths buried in the same file.
Growing the grab-bag for simplicity fails because cognitive load and regression risk grow faster than convenience. Hiding Webex and FDM calls inside spreadsheet macros fails by burying privileged integrations in the least reviewable layer. Inlining all three integrations into every UI handler fails through duplication and inconsistent error handling.
Exam caveat: module size should follow responsibility, not an arbitrary line count—but a multi-integration megafile is a classic anti-pattern on the exam.
Operational check: relocate FDM calls into a dedicated module with its own tests and confirm Webex and spreadsheet modules need no changes for an FDM-only fix.
Named modules also clarify ownership: Webex notifications, FDM policy reads, and spreadsheet exports can have different SLAs and test doubles. A grab-bag forces every helpdesk hotfix to regress all three integrations. Structure the city app so a later engineer can find and change one hop without spelunking a two-thousand-line mixed file.