| > developers own their code from IDE to production. That was an important implied Principle of Steve McConnell's famous Software Quality At Top Speed article[0]. In fact, if you read that article, a number of these things resonate. Not everything good is new. I just think that we forgot them, along the way. For myself, I generally operate as a one-man shop, so I have the following tips, that work for me: * Modular Design I write my stuff in discrete modules, if possible. Sometimes, the modules are source code files, organized by functional realms, other times, they are complete, soup-to-nuts, published and supported SPM modules. The iOS app that I'm writing now, has this current dependency manifest: * KeychainSwift: 20.0.0
* LGV_Cleantime: 1.3.6
* LGV_MeetingSDK: 2.3.0
* LGV_UICleantime: 1.1.4
* RVS_AutofillTextField: 1.3.1
* RVS_BasicGCDTimer: 1.5.2
* RVS_Checkbox: 1.2.2
* RVS_GeneralObserver 1.1.1
* RVS_Generic_Swift_Toolbox: 1.11.0
* RVS_MaskButton: 1.2.3
* RVS_Persistent_Prefs: 1.3.2"
* RVS_UIKit_Toolbox: 1.3.2
* White Dragon SDK: 3.4.2
All of them, with the exception of the first one (KeychainSwift), were written by me, and are released, supported open-source Swift Packages.I also wrote a couple of backend servers, that the app leverages. * Layered Design I write stuff in layers; especially server code. Each layer has a loose coupling with the other layers, and also maintains a fairly strict functional domain. This makes it very easy (and less bug prone) to pivot and fix. * Document As I Go I write my documentation into the code. I've learned to keep it mostly to headerdoc-style documentation. I write about my process here[1]. I also practice "Forensic Design Documentation"[2], and "Evolutionary Design Specifications"[3]. These help me to move quite quickly, yet maintain a well-structured, well-tested project. * Test Harnesses over Unit Tests I find that test harnesses[4] allow me the greatest flexibility, and fastest path to integration testing, which is where I want to be. * Reduce "Concrete Galoshes"[5] This is pretty important, and many of the above practices go a long way towards this goal. I know that the way I do things won't work for many folks; especially teams of less-experienced developers. My experience, coupled with an OCD nature, make it work for me. WFM. YMMV. [0] https://stevemcconnell.com/articles/software-quality-at-top-... (It would be great, if he fixed the images in that article, one day). [1] https://littlegreenviper.com/miscellany/leaving-a-legacy/ [2] https://littlegreenviper.com/miscellany/forensic-design-docu... [3] https://littlegreenviper.com/miscellany/evolutionary-design-... [4] https://littlegreenviper.com/miscellany/testing-harness-vs-u... [5] https://littlegreenviper.com/miscellany/concrete-galoshes/ |