2.1 KiB
Step 1: Design Phase -> Design Document. - distill basically what most skills do. - use even other skills: grill-with-docs, superpowers, etc.
Step 2: Architectural Phase -> Architectural Orientation - already more like a plan - this is where specs are born or connected - should help to situate the solution in the code: - modules - files - structs / classes - academic approach (functional, data driven, DDD, clean arch, ...) - traits / interfaces - pre-plan and post-plan: some of these decisions could be not very helpful if built right away, others should be prepped: e.g. writing database-models, creating modules, defining base shape of interfaces, etc. are good pre-plan jobs usually. deriving or polishing traits, restructuring abstractions etc. sometimes are more helpful as a later refactor if more code is available - Some abstractions are derivative and we have to anticipate this: sometimes the true structure of the data arrives out of the final logical requirements; sometimes these only arrive from actually applying the application to the problem. This is why this should be orientation. Because the opposite is also true: no architectural approach would have meant, that e.g. structures are written ad-hoc, functions that almost do the same are missing the opportunity to use common dispatch. - testing: design document for tests. how can we prove, our implementation is working well? what are the minimal tests required? what are breaking points that should be considered? - a good human programmer would probably already be able to implement a problem with design and orientation document only, solving the rest on the fly. - only high level code examples, like structures or relationships
Step 3: Planning Phase -> Implementation Plan - Again: should use existing skills, but: input is Design and Architectural docs / specs.
Step 4: Attack the Plan. Last chance to detect major blunders or optimize approaches, point out missing functional thoughts (a button is planned but it does nothing. there is an onboarding procedure but no offboarding procedure. error handling or security concerns. early abstraction could have solved this)