PowerFactors dev by day, gamer by night. Battling impostor syndrome and writing clean energy code (and useless side projects) fueled by pure insanity since 2008.
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.
PowerFactors dev by day, gamer by night. Battling impostor syndrome and writing clean energy code (and useless side projects) fueled by pure insanity since 2008.
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 Nidentical 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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.