4 ms·
One thing I've been thinking about more and more is code that's easy to delete. For example, we recently built a data pipeline that did a bunch of processing a
by SatvikBeri 10y ago
One thing I've been thinking about more and more is code that's easy to delete.
For example, we recently built a data pipeline that did a bunch of processing and wrote data to a SQL database at the end. For various reasons, there was an unscalable, quick way to implement the write, and a scalable, slow way to do it. We wanted to get the product to testing ASAP, so we chose the quick way initially.
In order to make sure that we could easily replace that code, we ended up creating a separate write function for each table, where the function did nothing else except the write. That involved a lot of duplication, but made it easy to move the tables over to a better method one by one later.
It seems like having functions with one purpose, pure if possible, is a pretty good way to ensure "upgradeable" code–even if the internals of the function are messy, you just have to write a new one that copies the same functionality. Furthermore, I've found single responsibility functions to be easier to enforce in code reviews than single responsibility classes.
- VLM 10y agoI would agree with that goal and extend with a different anecdote that the articles "project knowledge" section should include documenting the weird requirements and unusual interfaces to other projects. Many times I've run into five year old program logic, pondered why in the world anyone (me) would had done something that weird, and realized the project or tool requiring that weirdness was cancelled three years ago long enough that I've forgotten about it. Its not as simple sometimes as just baking into the single function that talks to the API, sometimes it gets baked into weird corners of the application logic.
- iaml 10y agoWhat you are describing seems very familiar to the idea in this [0] talk that I saw mentioned in the other thread on HN. Basically, the speaker argues that any codebase has a tendency to become a big bloated mess. The proposed solution to that is writing highly modular code that you can easily rewrite from scratch in a week. [0] https://vimeo.com/108441214 https://vimeo.com/108441214
- SatvikBeri 10y agoThis is great! Much more fleshed out than my post.
- crowbahr 10y agoI mean that's the single responsibility principle right? Classes should do one thing and one thing only and then your methods within the class should do one thing and one thing only. If I'm writing a list adapter for android it should only be a list adapter. It takes its data, interprets it and converts it to present. It doesn't also do data manipulation, that's handed off to another layer. It means increased modularity.