• Bug fixes
• Code cleanup and reorganization

Not much to visually appreciate in this update; mostly just some housekeeping! Details below 4nerdz.

Technical Details

I know updates like this aren't the most exciting, but they play an essential role in the long-term success of LK. Housekeeping vs. forward development is always a balancing act. You don't want to clean stuff up when you could be shipping new features unless the technical debt is actively standing in the way of something.

In this case, the Hydra update was a significant upheaval of LK. The first iteration was messy, but that's how I roll---Be scrappy and get something working, cover its primary entry points with tests, and ship it! Once you've validated the solution, then you clean it up. Your test coverage gives you confidence that you aren't breaking too much stuff when you do so.

But what is clean code, and why is it important? I want to emphasize that clean code has no immediate value to the user. It's better to have an app that's deployed and helping people than a perfectly architected codebase that's never shipped. That being said, an unmaintained codebase slowly accumulates obstacles that slow down and even halt development given enough time to fester. Naturally, this means codebase maintenance is more important for large applications and less necessary for smaller ones.

Clean code generally follows what is called the SOLID principles. These are design guidelines that make your code easier to extend and manage. There's lots of debate about how useful they are, and while they don't fully capture the landscape of software challenges, I've found them helpful in my pursuits.

LK's issue, in particular, was some disorganized client architecture impeding progress on bringing back cross-cutting key features, like the activity feed which needs to talk to many different systems. Responsibilities were splayed across the client, with many classes and functions holding references to many other classes and functions---Classic spaghetti code kind of stuff! But in your spaghetti, there lives an actual dependency graph that yearns to be free! By untangling the graph and applying a stricter, layered architecture, you get a codebase that's much easier to extend.

A layered architecture is an architecture style that occurs in layers, with higher layers responsible for higher levels of abstraction. Layered architectures come in many flavors. While implementations follow similar patterns, they're usually unique to each app based on need. For LK, from top to bottom:

1. The Presentation Layer displays UI and captures user interactions. In our case, React is our presentation layer.

2. The Controller Layer mediates communication between the presentation and application layers and protects the UI from changes in the layers below.

3. The Application Layer is the largest and defines possible actions. It manipulates models in the domain layer to execute those actions. Editing documents, applying permission settings, renaming pages, hiding from members, everything! This is the brain of the app.

4. The Domain Layer models the data entities that create the LK experience. Pages, pins, images, etc.

5. The Data layer handles all the bits and bytes. This includes storing and zapping them across the internet. The domain layer above interprets these raw bits and bytes to turn them into domain objects.

Anyways, I felt like diving a little deeper. Realistically, there are a few more layers here if you zoom in, but I'll leave that for next time. Hopefully, this is interesting to any of you software devs out there. 😄