| Both sides previous revision
Previous revision
Next revision
|
Previous revision
|
emergence [2021/05/10 09:34]
9gu1h [Emergent Code] |
emergence [2021/05/11 13:43] (current)
9gu1h [Emergent Learning] |
| Come back to the construction of our application -- multi-step functions. With an application of "sufficiently large size", no human could be reasonably expected to be able to "memorize" the entire function set of the application. The minimum size for an "inscrutible" application is a lot smaller than anyone suspects. And this trick of complexity requires **memory**, which is often shorter than the time frame it takes to change or add functions to the system. | Come back to the construction of our application -- multi-step functions. With an application of "sufficiently large size", no human could be reasonably expected to be able to "memorize" the entire function set of the application. The minimum size for an "inscrutible" application is a lot smaller than anyone suspects. And this trick of complexity requires **memory**, which is often shorter than the time frame it takes to change or add functions to the system. |
| |
| What do we do!? **Refactoring!!** | What do we do!? **Refactoring!!** The properties required of an "elemental function" are described by Kent Beck in //Extreme Programming Explained : ch. Simple Design// ((Extreme Programming Explained: Embrace Change, Kent Beck, Addison-Wesley, 1999.)) |
| |
| | • Runs all the tests |
| |
| | • Contains no duplication |
| |
| | • Expresses the intent of the programmer |
| CleanCode version | |
| |
| MonkeysAtKeyboards | • Minimizes the number of classes and methods |
| | |
| | Robert C. Martin in //Clean Code : ch Emergence// associates these properties with his own traits of "Clean Code". |
| | |
| | Neither author though tells us what to expect, nor how to achieve or observe "Emergence". |
| | |
| | ===== Emergent Refactoring ===== |
| | Emergence in our //CODE// comes of Refactoring. Taking our multi-step function and first applying tests to it... to ensure all conditions (code-branches!) and exception-handling (null-check!) operate as expected... Expected Behaviour! |
| | |
| | Then we perform a step that is not obviated by //Simple Design//... divide this function into "elemental functions" -- one //behaviour// per function, one condition(branch) per function, exception-handling as an "elemental function". |
| | |
| | As we work through this process of splitting our molecular function into it's atomic components... Patterns will Emerge. Functions with similar //behaviour// can be collected together into modules or classes. Functions that act upon a single data-type can be collected together into classes. Common collections of arguments or data-blobs (Objects!) can be collected together into DataClass classes. |
| | |
| | By the continual breakdown and gathering-up of "elemental functions" -- we can begin to observe and //Emergence// of "behaviours" (data-classes, common function collections, etc) that we could not have predicted from a simple examination of the original multi-step functions. While breaking down into "elemental functions"... we continue to examine the correct execution of tests, adding tests to new "elemental functions" -- data-classes, modules, libraries. Correct execution of tests ensures no //Unexpected Behaviours// are observed -- Less BUGS!! |
| | |
| | By this Emergence of Code, and improving the stability of our application (less BUGS!!), it is now easier to "reason" about how the application operates. The code, grouped together into common //behaviours//, matches the form of concept-processing that is used in our brain. Now we can more easily understand //WHY// our complex application behaves a certain way. We also can now easily determine what changes we could make to our complex application to add or enhance it's //behaviours// (API!). |
| | |
| | |
| | ===== Emergent Learning ===== |
| | You may have detected that //execution// of the above discussions is a time-consuming endeavour! This is exactly correct; and we can lean-into this time and use it to our advantage. |
| | |
| | Our industry, specifically software technology, has become fixated on **right now**. Agile process is debunked as "too flexible" -- we want **all the design**... //now!// Testing is deferred (and forgotten!) because we want **all the results** ... //now!// This becomes especially clear in application management, when a BusinessOwner turns to micromanagement as the only tool that seems useful in attempting to control a process and effort (MONEY$$) that they do not understand. Upon examination, we want to enable that BusinessOwner to have a recurring opportunity to "guide the ship" of development, helping the development and design team respond to business opportunities and challenges as they arise. The critical theme here is that **time goes by**. Business opportunities and challenges are unkown. They come about "at a time". We cannot predict them and must take them in turn. |
| | |
| | We humans also do another important task "over time"... LEARNING. We don't learn //all the things// **immediately**. We spend //years// learning our trade, learning languages, learning about each others as acquaintances, friends, partners. We also //learn about software//. The BusinessOwner learns about how the software we're building interoperates with the business process. We developers learn how the software is used (in unpredictable ways!!). We encourage the BusinessOwner take //time to learn//, leaving space in the planning and design process to **learn as we go**. |
| | |
| | Similarily, in refactoring our code, we need to give //time to learn//. Small refactorings don't necessarily take days to contemplate and review. We //do// need to give ourselves time to reflect on these small refactorings and //learn// the larger themes and modules that are. ... wait for it... **EMERGING** from the previous work. |
| | |
| | Emergence comes from learning. They are a form of each other. Emergence begets learning. Learning begets Emergence. |
| |
| Embrace | |
