Tag Info

New answers tagged

0

Unit tests and Integration tests can be used to protect your logic from code changes. If you currently have a good code coverage, and you need to re-work a section, then the approach would be easier, you can change your tests to reflect the result after the re-work and once you have done the change you can re-run the test cases, to make sure it's all ...


-1

It's never nice when things change, hope it hasn't got you down though. I do the architecture for our company as well and have asked some similar questions, so will share the little bit I know. Firstly I've found that there is no realistic solution for massive changes. The solutions I did find meant that everything had to be built so dynamically, that it ...


3

The only thing you can do to help reduce the impact of a change is to split your overall project up into many components, so while a major change will impact several of them, many will not be affected. eg if the customer decides they need a new button that sends data through the middletier to be stored in a new column in the DB, you're going to have to ...


1

There are plenty of methodologies given for making your code more adaptable and maintainable, but most of them have the following points at their core: Keep methods small: Your methods should only do one thing well. If they try to do more than one thing they will almost certainly fail at doing at least one of those things under certain circumstances, and ...


2

I'm not advocating this as the answer, but this is a list of techniques that has helped me greatly over the past 20 or so years. Self documenting code You might be tempted to add comments everywhere to make the code easier to understand. But the simple fact is that a lot of the time, if extensive comments are required within a method, the code isn't simple ...


-1

As MainMa already said: The changes that actual happen are unpredictable. (in almost all cases) Keep the implementation as simple as possible from the technically POV and as close as possible to the actual requirements (i.e. use speaking identifiers), or, in other words The best you can do for future changes is help understanding how your solution works.


9

Two very essential things to understand are that: You can never anticipate every change a customer may ask. I had a customer who decided to switch a two months project from PHP to ASP.NET one week before release and was convinced that this would be an easy change. Any change will have a cost. It doesn't matter if you are using Agile or if you have clean ...



Top 50 recent answers are included