This is a common interview question for new coders, and the goal in replying is to show the interviewer that you understand the importance of scalability and maintainability in coding, and that you have experience with techniques and best practices that help ensure these qualities in your code.
CodeNewbies: How would you answer - or have you answered - this questions?
Experienced Coders: How do you ensure that your code is scalable and maintainable? And what advice would you give for answering this question?
Follow the CodeNewbie Org and #codenewbie for more discussions and online camaraderie!
#codenewbie
The most supportive community of programmers and people learning to code.
Oldest comments (27)
That's a really tough question
I don't think many projects can say with confidence "yeah I have figured that out".
And if they do that could be a symptom of the reverse.
Like they over-engineered an infinitely scalable Netflix-like micro-services zoo
... but their backend has currently 1 request per second.
There are practices you can and should put in place:
But you probably want to stay humble.
Your codebase being maintainable is more a constant struggle than a science.
I am just cursious about your point of view, if the question was "How do you deal if unscalable or maintainable repos in your codebase"
First I would buy and read this book
It's a great book. One of my favourites.
And, I would add to it, the importance of stakeholder/business side's support!
The point inherent in maintainability of code is that of long-term usability. The folks owning the code must view the code as an investment, which carries an RoI. If that support (may be implicit) doesn't exist in principle and in execution, then all the good design practices begin to look like unnecessary overhead.
How do you identify performance problems?
Legend
Scalability and maintainability. Two words that result to an over engineered application. Make your code simple and concise. Do not think too much about the future.
Following SOLID principle might be a way to ease maintainability
unit testing and never deliberate create tech debt. "We will refactor later" is the biggest lie ever.
Maintainability and scalability are the two holy beasts of software engineering. I really don't believe that even large code houses with armies of skilled and talented people have too much to show on this front. Also neither of them has a be all end all solution on that.
Maintainability means that you have a codebase with little to none tech debt where everyone can jump in and contribute. There are a few things that you might do to increase maintainability, like following a specific coding style and convention across the whole codebase, follow the SOLID principles, YAGNI, and other weird acronyms. Keep in mind, though, that these principles can easily lead down the path of a cargo cult. The best advice I can give for maintainability is to "Always write your code as if the next person who will work on it is a violent psychopath who knows where you live" 😁😁😁
As of scalability, things become even more unclear. We go around and say, "We will follow the X architecture because it is more scalable", then after a while we go like "Let's use the shiny new Y architecture it's more scalable". There are actually at least three dimensions you can scale an app, so there isn't a definitive answer. Again, the best thing you could do is to organise your code in components with a single responsibility or context, and keep them as loosely coupled as possible. But again these are too general guidelines and your approach should be dictated by the project at hand.
I love your answer can you break down the three dimensions for me please
According to Michael Fisher's book, The Art of Scalability, we can describe the scale cube.
This model defines three ways to scale an application: X, Y and Z.
X-Axis Scaling or load balancing requests across multiple instances. X-axis scaling is a common way to scale monolithic applications. What we do here is to run multiple instances of the application behind a load balancer, and the load balancer distributes requests among N identical instances.
Y-Axis Scaling or functionaly decomposing an application into services. Y-axis scaling breaks down the monolithic application to a set of services. A service is a mini application that implements a narrow focused functionality.
Z-Axis Scaling or routing requests based on an attribute of the request. Z-axis scaling also runs multiple instances of the monolith, but unlike X-Axis scaling, each instance is responsible for only a subset of the data. So for example you can split the usernames based on their first letter, with one instance handling requests from usernames between A-H, one for usernames I-P and one for usernames R-Z.
Follow coding standards and conventions: Adhere to established coding standards and conventions for your programming language. This makes your code easier to read, understand, and maintain.
Write modular code: Break your code into smaller, reusable modules or functions. This allows you to manage complexity, isolate issues, and reuse components across your project.
Use version control: Use a version control system like Git to track changes, maintain a history of your code, and collaborate effectively with other developers.
Write unit tests: Create unit tests to validate the functionality of individual code components. Regular testing helps catch bugs early and ensures the stability of your codebase.
Use a consistent naming convention: Use clear and descriptive names for variables, functions, and classes. Consistent naming improves code readability and maintainability.
Enforce prohibition of writing code comments, the code should be self explanatory.
Refactor regularly: Periodically review your code to identify areas for improvement, remove duplication, and simplify complex logic. Refactoring helps keep your codebase clean and maintainable.
Optimize for performance: Analyze your code's performance and identify bottlenecks. Use efficient algorithms and data structures to improve scalability.
Utilize design patterns: Implement proven design patterns to solve common problems. Design patterns provide reusable solutions that can improve the structure and organization of your code.
Plan for future growth: Consider how your code will need to change as your project grows or requirements change. Design your code to be flexible and adaptable to reduce the effort needed for future updates.
I believe it's impossible to build totally maintainable code initially. First focus on your requirement writing the cleanest code you can as you go, but do not over engineer it before it's needed. Chance are either this requirement is never going to be revisited again and thus you have more complexity than useful or is going to be totally changed in unexpected way and the great architecture you built will be in the way of the new requirement.
Most of the time, keeping the code simple is the most maintainable solution.
The same goes with scalability, don't architecture for scalability before you need it, chance are the boundaries you'll create will be at the wrong place and again in your way.
Maintainability: My favorite trick for this is to architect everything with testability as the chief architectural goal. Not only does this help you to efficiently achieve great test coverage, which itself is good for maintainability (keeps you from breaking stuff), but I find that this approach naturally leads to modular and cohesive code.
Scalability: I wouldn't usually worry too much about mega-scalability up front because it might just be a waste of time. Many, many projects run just fine forever on a handful of machines all talking to one database instance. It's usually hard to know whether you'll need to go beyond that scale or not, and designing for it might be a waste of time due to the added complexity. If you're sure you'll need it, then by all means, design for that up-front. But it really does happen that sometimes people try to design for scalability that they never end up using, I've seen it.
One technique that I like, which preps you for needing to scale, but without introducing too much complexity, is building a modular monolith. What I mean is for example, have a "users" module, a "photos" module, a "posts" module, etc, and have those be separate in code and have them be able to talk to independent database instances. But then just deploy them all as one package and have them talk to the same database instance (but different logical databases inside of it). If that database instance gets too hot one day, and the posts module is mostly the culprit, then pull out the big guns and refactor it to use Scylla or something, and start deploying the code in separate containers. To be honest I haven't had to do that yet in my career, but I'm looking forward to the day!
Modest scalability is a different story. A modestly sized project can still be crippled by bad database indexing and query writing, ignoring time complexity, etc. I don't have any super specific tips about this, you just have to learn about the basic good performance practices of the technologies you're using.
I like to think that I get a little better at these things every day, but I still have a long way to go! These are very hard problems and as others have said in the comments, nobody has all the answers.
When they ask questions like this, they want to hear keywords like: design patterns, loosely coupled, SOLID principles, etc. But honestly no company I ever worked for had achieved truly maintainable and scalable code... Its the holy grail of software engineering. At most what you can achieve is a basic understanding of the code base among all team members that will live on until the last team member with the knowledge is replaced.
Agree! When I hear people say that they have 100% test coverage, I generally just laugh because I'm sure there are "no-cov" or similar comments everywhere. It's like people way I painted this entire wall brown without using the color blue.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.