sobri909

On Changing Processes

1. All else being equal, a simpler system is preferable to a more complex system.
2. Complexity, structure, process, and size should only be added after a problem is identified.
3. Such additions should attempt to solve the identified problem only. Avoid scope creep.
4. If the problem can be solved by reducing rather than adding complexity, that solution is preferable.

A project or team should only have the structure, complexity, processes, and size necessary to solve identified problems, and no more. Start with the simplest form, and add to it only when necessary.

Questions to ask when evaluating process changes

sobri909

//
//  PersistentTimelineStore.swift
//  ArcKit
//
//  Created by Matt Greenfield on 9/01/18.
//  Copyright © 2018 Big Paua. All rights reserved.
//

import os.log
import GRDB

sobri909

```swift
// SwiftNotes, observing via NotificationCenter
when(field, does: .UITextFieldTextDidChange) { [weak self] _ in
    log("UITextFieldTextDidChange (newValue: \(field.text)))")
    self?.textFieldChanged()
}

// MGObserver, observing via old school objc KVO methods
field.onChangeOf("text") { [weak self] in
    log("field.onChangeOf(text) (newValue: \(field.text)))")

sobri909

Structural Notes

• The server’s customers are the mobile apps.
• The mobile apps’ customers are the end users.

Server

• The server should deliver updated product / functionality to its customers (ie the mobile apps) on a daily / timely basis.
• The changes / additions should be documented to ensure basic understanding of how to make use of them.
• The changes / additions should be delivered in a stable and shippable state.
• The server’s customers should never need to be aware of the inner workings of the server.
• The server’s customers should never be required to run an instance of the server locally.

sobri909

Master Branch Commit Discipline

1. Every commit must be fully human tested before hitting the repo.

You must be able to confidently say: “This commit does what it’s supposed to do, and does not either contain obvious regressions or introduce new bugs”. You have proven this to be true because you have tested the commit in the app (or browser or other relevant client), whilst also testing all reasonable combinations of related functionality to ensure there are no obvious regressions.

There should be no surprises. Regressions and new bugs should be limited to rare edge cases and unexpected conditions that fall outside of the range of normal user interaction with the app.

2. Each commit should be considered complete, in the sense that is a functional, tested, and shippable chunk of work.

Note that this does not mean that the commit needs to contain a completed feature, nor a completed sub-unit of a feature. It might only contain a single line change. But it must be confirmed that it leaves the p

sobri909

// fragment of main app file, to doing manual CloudKit fetches on appear, 
// because can't always rely on CloudKit subscription being timely

@main
struct LifeBalanceApp: App {
    @Environment(\.scenePhase) private var scenePhase
    
    var body: some Scene {
        WindowGroup {
            TodayTab().environmentObject(Session.highlander)