How can you write code that adapts to changing requirements?

Modular design, and the tightly related Object Design, can contribute to adaptable code. The difficulty is that such design, if properly done, consumes lots of analysis resources as your design has to identify some atomic level of functionality. It work, and it works well, but the resource cost to do it correctly tends to cause PM to have heart attacks. Normally, the result is a partially flexible design.

In my experience it is fundamental to think of your system as a living organism. Regardless if it is a new greenfield or a legacy system, take a step back and think about the business domain very clearly, think about what the bounded contexts are and how best to define the boundaries of your modules. Once these are well defined, think about what is the appropriate granularity you want to adopt - design your independent modules with these things in mind; iterate overtime as your organization scales. Another important aspect to have in mind is how the modules need to scale and respond to volume - systems can have different read and write scalability needs. Next, look at coding practices using SOLID and other principles to ensure low coupling.

Write code that: - solves the problem in a simple way - is well covered by automated tests - is well factored (does not repeat itself too much but is not spread over too many classes/functions/methods) - obeys a coding standard (does not matter much which one, just have a standard and obey it)

I believe that if we smartly follow some design rules, we can easily have a flexible design that can change with the times without affecting how it works now. The following are some of them: -> KISS (Keep it simple, stupid) -> DRY (Don't say it again) -> SOLID -> High Cohesion and Low Coupling The above rules can help you begin organizing your code into different sections.

Use SOLID principles & implement modular design - loosely coupled components with use of well defined abstraction on key sections. Adopt agile methodologies to go with iterative & incremental development. Establish feedback loop with stakeholders to stay on top of any changes in requirements.

Just as you have a scrum master, so too, you need a cide master or at least a buddy system that enforces standards. Comment your code. Don't rely on your chosen naming convention to tell the whole story.

Unraveling messy code or battling unexpected bugs? ???♀? Coding standards are your superhero! They ensure: 1. Clarity for All: Consistent formatting and naming conventions make code universally readable. 2. Debugging Like a Boss: Pinpoint errors swiftly, saving time and headaches. 3. Refactor with Confidence: Easily restructure code, knowing its organization remains clear. ?? 4. Quality First: Reduce bugs and vulnerabilities, ensuring reliability and security. Pro Tips: - Adopt widely-used standards (e.g., PEP 8, Google Java Style) or create team-specific ones. - Use linting tools for early error detection. - Document for accessibility. Fun fact: 80% of devs agree—coding standards boost quality and maintainability. ??????

Many developers try to keep this as a last activity. Adhering to coding standards should start from the very first line of the code. This is more of a habit every developer should adopt. Keeping this last hygiene activity would mostly result in not doing anything or doing it partly.

A big No to *Not Following Coding Standards* Get some expert, read books, read articles on better coding; but Donot create a Living Mess As the saying goes; What goes around, comes around! It is a balance though, donot fall into the trap of Perfection

In traditional development shops, well-defined coding standards keep things consistent across the code base, which directly contributes to its maintainability. The uniformity is particularly valuable when new team members are brought on board as it significantly reduces the learning curve allowing them to quickly become meaningful contributors. Then with proper devops practices and the infrastructure to boot, you can even automate most or all of your compliance checks eliminating the administrative overhead of standards enforcement. Even with the disruption that LLMs bring to development productivity, maintaining standard, readable code is still important.

For code to be testable developers should follow the "D" in S.O.L.I.D principle i.e. Dependency Inversion Principle . This principle states that "Depend on abstractions, not on concretions". Hence all modules which interact with external systems such as Database, File System, Third Party API's should be abstracted. This will allow injection of mocks during unit or integration test execution. However, there will be development overheads which can be managed by using Mocking and IaC frameworks. The increase in development time and complexity will be offset by a robust set of unit and integration tests which ensure quality when integrated with the CI Pipeline and allow for refactoring of code when required.

Craft code with a focus on testability by breaking it into modular units that can be independently tested. Define clear interfaces, minimize dependencies, and use appropriate testing frameworks. Writing testable code enhances software reliability, facilitates easier debugging, and supports efficient maintenance when adapting to changing requirements.

Even though the code is easy to understand, we might overlook its cyclomatic complexity as it might hide its dependencies. As a result, we fail to realise how complex the code is. Writing unit tests forces us to refactor our code to have single-responsibility and dependency inversion. These are already two of the five SOLID principles. That is why having unit testable code makes writing tests painless and makes the codebase less complex, easier to understand and more maintainable.

A code that can be tested in isolation promotes modular design and it goes hand in hand with the first point. This would improve the reusability.

In my experience it is imperative that we have testable code. This helps with requirements, static or changeable. But testable code alone is not the only key to adaptable requirements.

In architectural design , adopting version control presenting the evolution of a blueprint. It enables tracking comparing and merging design iterations and fostering collaboration among architects. Like code, designs undergo revisions; version control ensures a seamless process, facilitating recovery from errors and maintaining a coherent project history.

Absolutely essential during collaborative development to use version control and a central repository. For example, Bitbucket, Gitlab, etc... It makes it so much easier to colloborate on, compare, merge and roll back code. As important is that the whole team is aligned on the processes governing code development and management and that formal governence is followed if a change is required to either streamline the existing process, add new steps such as automated build like Jenkins etc... and changes to the end to end release and version management process...

Version control - also known as source control or revision control - is an important software development practice for tracking and managing changes made to code and other files. It is closely related to source code management. If developers code concurrently and create incompatible changes, version control identifies the problem areas so that team members can quickly revert changes to a previous version, compare changes, or identify who committed the problem code through the revision history. With a version control system (VCS), a software team can solve an issue before progressing further into a project. Through code reviews, software teams can analyze earlier versions to understand the changes made to the code over time.

Rather than applying traditional approach for coding, think about what can you get AI to do the work for you ? What can you innovate ( small or big ) it doesn't matter. Bring out the best in you ( do rubber ducking with your peers - best way to uncover the gaps)

I would also say that version control: Enables you to experiment with new features and ideas without affecting the main codebase, by creating separate branches for each feature or task. Improves the quality and security of your code, by allowing you to perform code reviews, testing, and auditing before merging your changes to the main branch. Supports continuous integration and delivery, by automating the build, test, and deployment processes of your code. Facilitates documentation and communication, by providing a history and context of your code changes, as well as annotations and comments.

Refactoring is like "cleaning as you go" in the kitchen. If you focus too much on only cooking the dishes (feature work) and not on organizing ingredients or clearing messes, you will simply pile on more to clean later, and things will be harder to find in the clutter. Every now and then, it's not unusual that the bug fixes, feature additions, package replacements and other contributions added inflate the size of your codebase. People join and leave and some code that was relevant 6 years ago might not be today. Taking some time periodically to optimize and reevaluate the sensibility and structure of your code base could help you and your team be more efficient with everything they do, especially if they deliver software in an agile world.

Think, Think, Think Always think about what future your product holds. Draw scenarios, discuss with stakeholders about what they are thinking to shape their product. Then comes the development phase where you loosely bound your code so that it could take any shape accordingly. The bottom line is : Be proactive

Always think about where your product is headed. Discuss ideas with stakeholders to understand their vision. When building, keep your code flexible so it can easily evolve. The key is to be proactive and stay ahead of the curve.

Refactoring code can help in the overall life cycle of an application. It should be part of your standards for modifications to an application. The primary purpose of the effort being making the application leaner. However, the other major benefit is that it tends to result in lower effort requirements for later problem resolution or application modification.

write - test - refactor is a continuous cycle that should be followed while developing software. Its rare to right the perfect code in first attempt and with evolving needs and context. A enforces refactoring at code and design level eventually ends in a a good quietly software.

with Gen AI developers have started blindly copying and pasting code. We should use these tools for sure but taking the design and context into account and adjusting it to the local needs. Else we would end un into a complex code

Don't try to think too far ahead and anticipate future requirements. When you do that, you end up making your code more complex for a chance that your expectations will be right. Most of the time they won't and you'll end up with extra code to maintain. Keeping it simple allows you to change it easier in the future.

A helpful perspective can be to embrace iteration as part of the development process rather than as an unwelcome interruption.

The ability to think and work with abstractions. While developers are often taught/advised not to hard-code, too many things are hard-coded. Furthermore, even when hard-coding has been thought to be tackled, you’ll often find that the use of data forces developers into hard-coding… specifically because the data is itself absent of sufficient abstraction.

You may also want to think about the following other things when working with changing requirements: 1. Making sure that past work is well documented 2. Sharing of knowledge 3. Adding automated tests to your CI/CD pipeline All of those things can be very helpful. In this case, if you have documentation, everyone on the team can look it up and find answers, technical design, and so on. In the same way, having sessions where people share their knowledge can really help the team stay up to date on the latest requirements, and they can also think about edge cases while working on a feature. Lastly, a good automated tests process can help you save time on testing and make sure you don't send any changes that break things to production.