Review and Refactor
By the end of this lesson, you'll be able to:
- Review the full banking system against this course's accumulated principles
- Identify and refactor at least one rough edge in the implementation
- Reflect on how this project draws together nearly the entire course
Prerequisites: "Monitor and Log"
A checklist drawn from the whole course
- Bulk safety (Module 25): does every trigger handle 200 records in one query and one DML statement? Yes — Lessons 2 and 6 both confirmed this.
- Security (Module 28): is
with sharingandWITH SECURITY_ENFORCEDapplied everywhere sensitive data is queried? Yes — Lesson 6. - Testing (Module 31): bulk, negative-path, and async coverage all present? Yes — Lesson 7.
- Async correctness (Module 38): is the ledger callout properly decoupled from the trigger transaction? Yes — Lesson 4.
- Observability (Module 33, Lesson 8): can a real production issue in this system actually be diagnosed from the logs alone? This is worth a second, honest look.
One rough edge, found and fixed
// Before: TransactionLogger.logRejection swallows the account's
// current status, making a "why was this rejected" log entry less
// useful than it could be.
public static void logRejection(Id accountId, String reason) {
System.debug(LoggingLevel.WARN, 'Transaction rejected for account ' + accountId + ': ' + reason);
}
// After: the caller passes richer context, so a spike in a specific
// rejection reason is actually distinguishable in the logs.
public static void logRejection(Id accountId, String reason, String accountStatus) {
System.debug(LoggingLevel.WARN,
'Transaction rejected for account ' + accountId +
' (status=' + accountStatus + '): ' + reason);
}
This is a small, honest refactor in the spirit of Module 33's "make future debugging easier" principle — not a bug, just an improvement noticed only once the whole system was reviewed together rather than lesson by lesson.
What this project actually drew together
Across nine lessons, this project used: Module 24's trigger structure, Module 25's bulk safety, Module 26's rollup pattern, Module 28's security model, Module 31's testing toolkit, Module 33's debugging and logging mindset, Module 36's callout rules, Module 38's Batch/Queueable/Schedulable Apex, Module 39's retry and error-handling design, and Module 41's incident-response thinking — a genuine synthesis of nearly the entire course into one coherent, realistic system, which is exactly what the final capstone project in Module 45 will do again at an even larger scale.
Exercise
As a comment, name three specific modules whose principles this banking system project relied on, and what each one contributed.
Show hint
Pick three that feel most load-bearing to you.
Review and Refactor Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
The closing lesson steps back and reviews the whole banking system as a working system — the same review-and-refactor discipline that closed Modules 30, 32, 35, 37, and 39 — before moving into the course's final architecture-focused modules.