How do you write code that is extensible and maintainable when you don’t know what new features and changes will be demanded in the future.
In my 20 years of software development I have found one constant in all the projects I been working on, things are going to change. Not even one project escapes this reality, no matter what you do and how well you try to gather requirements, all the projects will need adjustments during the development and after being on production.
So, is a must to write software easy to read and easy to maintain instead of writhing software to last (The Noble Art of Maintenance Programming).
The answer is quite long but I will give you the key points, but you are going to need to investigate a lot more the subjects and put them in practice.
The first one is, you need to deeply understand the Entity–relationship model when creating databases and Data structures . It really doesn’t matter if they are relational data, document type or graph databases or any, the principals for managing data are the same, the foundations of any application is the Data, not the business logic (is also very important but not the foundations). So learn Database design and Data modeling
Second, you must learn why we use Object oriented programming (OOP). It is not needed to always use this pattern, it actually takes some resources and is not advisable to be used when real time response systems are needed. OOP was created to model the real world on a computer (the weather specifically) so we can deal with coding better when creating the solutions to a real world problems. We can achieve the same results without OOP, by using other languages as Haskell (Which is a purely functional oriented) or C (which is structured programming). Just remember that none of them are right or wrong, better or worse, they all have a circumstance and a times which some are better to use in some cases and other in other cases. That is why you need to go to the roots and learn why OOP exist, what it intent to solve, how it solved, when is better to be used, when is not.
Third, you must learn Software architecture even if you are a developer and don’t plan to be in that role. By using Layered architecture and Multitier architecture will help you a lot when problem arise and you will know exactly where it is and you will not be wondering where you have to look for to locate the problem. In this eBook https://www.intertech.com/Downlo... you will learn more about the repository style but also the domain driven design style is very good.
Fourth, learn the SOLID , the KISS , the DRY , separation of concerns principals and all the ones in this article 12 essential software development principles and concepts, it will save you a lot of headaches.
Learn about Module pattern , this is very important since it will allow you to deliver small pieces of fully functional software, so the user can test the application before is completed. The user will give you feedback and make any corrections during the software development so the following software that you write will be already on track over a bad requirement. This approach save you a ton of work. Make sure that always do a s Minimum Viable Product. Here is a good article about it Patterns of Modular Architecture.
Learn about the Adaptive Object-Model Architectural Style , this one is not easy to learn, since you have to put the business logic of the application on the database but not in the code. This is a supreme way to make an application since any changes in the business logic in your system only require an update on your database as configuration and the application will adapt to the change without needing to write any code and you will not need to deploy the whole system for every new change on the business logic. (More of it here and here )
And at least, the more and most important thing I ever found, consistency. Especially when working on a team. All of us learn different approaches on how to do things to solve the problems on software development and we have use different solutions. There is nothing wrong with the way you solve the things, as long it is a reliable solution and does what is expected to do, is fine everybody is different. (don’t fall for the trap “everybody writes bad software except me”, you will be always wrong and you will miss an opportunity to learn from others and improve your self).
When you are in a team, if every developer put their own style on the project you are going to make a chaos. The software architect or technical lead imposes (yes, it must be imposed) the style to be use on a project and must be strictly followed. A lot of times I work with styles, patterns and architectures that I know I could do it better but is not on my role and responsibility to establish that and I must respect hierarchy. Other times, there was no software architect and every developer create the code on their style, it was very frustrating trying to figure out the bugs and trying to add or change functionality since every time I need to figure out how the things are being done and resist the temptation to erase everything and redone it in my way.
Also, is very common that the user interface (GUI) will have a mix design and the user will find that grids and forms and all the parts have in different places the fields, the buttons, the messages, the way the data is validated in the same application; this is very unprofessional. So, the first thing you can do and it will help you a lot is the consistency principle. You can find it in this article https://www.d.umn.edu/~gshute/softeng/principles.html.
This is only the tip of the iceberg and the beginning of a path on how to deal with unpredictable changes. You must read a lot more and put in practice the concepts that I just mention. What can you add to this?
