Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How do you write code so it's easy to change?

news.ycombinator.com

Post reply on HN
Print view View original

71–78 of 78 posts

Re: Ask HN: How do you write code so it's easy to change?

#71

Post by joddystreet »

This is how we do the API -

- Database models should contain all the possible mechanisms/methods for data I/O

- Data Transformation utilities/ helper functions that do one job well, that is - sort, filter, validation, whatever -- -- If an API is using (more on API below), utils become immutable code

- Finally the API level -- -- treat the API code as immutable, once shipped -- -- The code should look like a pipeline of functions -- -- -- eg: serialize(...) validate(...) filter(...) db(...) -- -- -- need not be chained -- -- new API version, new router, new routing logic

- Review API with an intent to extract out any possible util methods. final API methods should look like a series of data transformation functions

- Overtime the utils would become extremely messy, but the APIs would be very clean

------------------------------------------------

The layer running business logic would be the most interacted with layer, if you can keep it clean, then you can keep frustration low in your fellow devs. A lot of people can work on the API level, irrespective of their experience.

Utils and Models should be managed by more experienced devs. Rate of change in Utils and Models is quite low as compared to the rate of change in the API levels.

------------------------------------------------

Not sure, I guess I am writing something very trivial and obvious.

Re: Ask HN: How do you write code so it's easy to change?

#73

Post by mattbrewsbytes »

Simple things go a long way. An easy one is abstraction.

If you are writing an interface to another system of any kind (DB, API, etc.), abstract that interface one layer from other parts of your app. Then when that other thing changes you are less impacted.

An example: if your organization has multiple apps, it might sound easy to just let app #2 have direct DB access to app #1's DB. Take a little time and build a simple API in app #1 to get at the data, then when you change column names, etc. as long as your API layer doesn't change app #2 won't require changes. You don't have to build a fully RESTful API to all-the-things if it is just one table. Iterate.

Re: Ask HN: How do you write code so it's easy to change?

#74

Post by Jugurtha »

The first thing we did when we started building our ml platform was to go with a plugin architecture. All applications are simply plugins. Data connectors are plugins.

We do consulting work and have to build custom solutions for our clients. Once they were satisfied with the models, they'd ask for an application to use these models: user management, data uploads, etc.

We used to build a custom solution for each client. It was very hard to change these solutions when client's demands changed, and it was almost impossible to reuse that solution with another client.

We took advantage of a decrease in activity to build a platform where things would be plugins. The time series forecasting application is a plugin, with endpoints you can tap into with authorization tokens.

The recommender system is a plugin, the notebook application is a plugin, etc.

Now our notebooks are "Published" in one click, which generates an AppBook a business person can interact with by changing the parameters. The runs are tracked (params, metrics, and models) in case domain experts tweak parameters that result in a better model than we have. The models can be deployed to endpoints you can invoke with generated tokens.

The major benefit is that when a new member joined the team, they had to understand the whole code base to be able to contribute or add something. Now? They don't have to understand anything, only the application they're building. If they want to render it on the sidebar, they just have to add a `sidebar.html` with the proper icon and route. If they want to show it in our appstore, they just have to add a file with the proper icon, and our platform handles the rest. It will discover the application, load it, etc.

An administrator can even load an application as a zip file. The platform will consume it, install its dependencies, load it, and activate it.

We want the product to be easy to add to and modify its behavior with config, instead of changing the code and we work to do just that.

Re: Ask HN: How do you write code so it's easy to change?

#76

Post by BurningFrog »

tunesmith wrote: post #35
BurningFrog wrote: post #21

Only write code that's absolutely needed for what you're building. It's very tempting to make it "extensible" by overgeneralizing. What you get then is overly complex code, most of which is never used. Cut out everything that isn't currently used, and you have a small system where every line pays for its keep.

Agreed - and note that this principle is in tension with the junior/intermediate (heck, even senior) urge to make things "easy to change" by just making everything abstract and configurable. ("See, now if we want to do it this other way in the future, we only have to flip this bit!") I still haven't found a pithy way to describe the limitations of this principle. Obviously, frameworks are helpful and also fail this p…

How I think about this is that adding this flexibility is no harder to do when we actually need it.

So there is no reason to add it now, even if we're 100% sure we'll need it. And in reality, those expectations are rarely more than ~40% true.

This goes hand in hand with refactoring as a core skill. If you're good at refactoring, you can always tweak code to do what you want.

Re: Ask HN: How do you write code so it's easy to change?

#77

Post by sush1612 »

Write however you want to write, choose whatever best practices available, any design pattern, design principal. Just add lots of comments, as many comments as possible which talks about what each line is suppose to do. If you are using a pattern, write at the start that this is x pattern used for this scenario. if you are branching the code, which scenario each branch will take care of.

At the end, if you comments and logs are complete and self explanatory, any one can come in and change the code or debug the code.

Re: Ask HN: How do you write code so it's easy to change?

#78

Post by tedmielczarek »

BurningFrog wrote: post #21

Only write code that's absolutely needed for what you're building. It's very tempting to make it "extensible" by overgeneralizing. What you get then is overly complex code, most of which is never used. Cut out everything that isn't currently used, and you have a small system where every line pays for its keep.

This mostly matches what I've come to believe over the course of my career with one slight tweak: also make sure that your code can handle the immediate next thing you know needs to be done. Don't try to plan any farther ahead than that because requirements change so often that you'll just waste time, but also don't write something so hacky that you'll have to do a bunch of rework to support the feature you know have to implement next week or month.
Post reply on HN