Hot answers tagged

87

I see some wrong assumptions in this question: code with design patterns, though applied correctly, needs more time to be implemented than code without those patterns. Design patterns are no end in itself, they should serve you, not vice versa. If a design pattern does not make the code easier to implement, or at least better evolvable (that means: easier ...


43

My humble opinion is that you shouldn't avoid or not-avoid using design patterns. Design patterns are simply well known and trusted solutions to general problems, that were given names. They aren't different in a technical manner than any other solution or design you can think of. I think the root of the problem might be that your friend thinks in terms of ...


14

In your example of using the Null Object pattern, I believe it eventually failed because it met the programmer's needs and not the customer's needs. The customer needed to display the price in a form appropriate to the context. The programmer needed to simplify some of the display code. So, when a design pattern doesn't meet the requirements, do we say that ...


10

Because software engineering isn’t done for some abstract pursuit of software engineering, it’s about building a useful result. If halfway through the construction of device A you find out that it won’t be useful, won’t be competitive, has huge unforeseen issues, etc., then you’re better off scrapping it and building device B. The dev effort sunk into A is ...


9

SQL scripts are the right way to go: The information was originally created via a sql statements, most reliable repeat-ability would come from the same script Import/export can also get tricky if two devs are modifying the same table. It's hard to code review an export file. It's hard to debug an export file We have 5 database environments in our world: ...


9

It would appear the mistake was more to remove the pattern objects, than to use them. In the initial design, the Null Object appears to have provided a solution to a problem. This may not have been the best solution. Being the only person working on a project gives you a chance to experience the whole development process. The big disadvantage is not ...


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 and ...


7

Basically, you're completely right. All the information should be in the VCS as well, and as commenters said, changelogs are often generated out of VCS information. However, prepared changelogs come with some remarkable advantages: A changelog does not require to connect to the VCS, maybe install the proper VSC client before, scrolling through tons of ...


7

Let's pause for a moment and look at the fundamental issue here - Architecting a system where the architecture model is too coupled to low-level features in the system, causing the architecture to break frequently in the development process. I think we have to remember that the use of architecture and design patterns related to it have to be laid on a ...


7

The question seems to be wrong at so many points. But the blatant ones are: For the Null Object Pattern you mentioned, after the requirements changed, you change a bit of the code. That's fine but it doesn't mean you 'murder' the Null Object Pattern (btw, be careful with your wording, this sounds too extreme, some people too paranoiac won't see this as ...


6

When used properly, VCS has too much detail. Every little change is recorded, when a changelog is generally for the big user-visible changes. In short, the target audience for a changelog is not the same as for the commit messages of the VCS. If you are disciplined, a changelog can be an auto-generated subset of what is in VCS, though in my experience most ...


6

I will focus on the two core problems described in your question: Soon there are like hundreds of configurable options, and even naming them becomes a nightmare, let alone managing them, changing them, tracking them in code The naming problem can be solved by organizing them in hierarchies. For example, look at the thousands of options you will find in ...


5

Is this acceptable in agile scrum? Define "acceptable". In some environments, it's fine. In most, it is prohibitively problematic. That problem is that most Business Analysts are horrrrrible. Even when they understand the product well, and even when they can define and scope features, they rarely understand much of the implications of the feature to the ...


5

Not all test should experience changes like how you're describing. For example acceptance test cases shouldn't fail if a constructor changes--they should only change when requirements change. Testers should focus on writing automated test cases that verify requirements and tests that protect against regression. These automated test cases should be executed ...


5

If I may be so bold ;) The problem isn't really about unexpected schema changes to production, though that's certainly a symptom. In reality it is: "Why aren't different members of my organization communicating about changes that affect each other" Once you view it that way then it makes more sense to look at: current processes of code and database ...


4

Your friend seems to be facing numerous headwinds based on his anecdote. That is unfortunate, and can be a very hard environment to work in. Despite the difficulty, he was on the correct path of using patterns to make his life easier, and it is a shame that he left that path. The spaghetti code is the ultimate result. Since there are two different problem ...


4

As you figured out by yourself, SQL is the way to go, but if you put the SQL commands into scripts or embed them in code does actually not make a big difference. What matters is that you make the upgrade process robust. Therefore, I would recommend to consider the following improvement over track your changes in sequential sql or code files Instead, ...


4

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 ...


4

All you have to do is buffer your structured events such that you can look them up by affected path (source and destination, probably). The actual mechanism for combining any given pair of events will depend on what those events are, so you just need to manually code the optimisations you want. It's much simpler to do this pairwise than to somehow ...


4

why are requirements changes allowed to happen They aren't "allowed" to happen. They happen. There is simply a non-zero amount of time between the point in time where the requirements are defined and when the software is delivered. Within this non-zero amount of time, the universe has changed. Even the process of gathering the requirements itself ...


3

Continous Integration is a best practice per se, which main goal is to ensure that your code assembles correctly and pass both unit and integration tests. CI should happen continuously regardless the changes (not sporadically only when changes happen). This is especially important for projects involved in continuous deployment and delivery. Tests can fail ...


3

Consistent UI is very important. That's why most, if not all, shops have a "standard" way of doing UI things, even if that standard is de-facto. Often, that standard arises from conventions that users already understand because they are widely used. Introducing new UI innovations into an application where they didn't exist before can confusing, both to ...


3

The short answer: Log it, maybe notify the user, and maybe continue execution of your application. Changes happen all the time. In production. Without warning. Often by mistake. Even with change control policies carved in stone, mistakes happen. A DBA that is tuning a query drops a table. A developer with too much access accidentally removes a column. One ...


3

What's the purpose of keeping a changelog if everyone uses their VCS properly? ... If this history is being properly kept, what is the purpose of manually keeping the same history in a regular file? Your question is a good one, but you're making two big assumptions. Given a team with a disciplined check-in history, you're assuming that the changelog ...


3

A design pattern's complexity can bite you if the problem it was supposed to solve suddenly disappears. Sadly, due to enthusiasm and popularity of design patterns, this risk is rarely made explicit. Your friend's anecdote helps a lot to show how patterns don't pay off. Jeff Atwood has some choice words about the topic. Document variation points (they are ...


3

What do you mean allowed? Do you think that businesses like inefficiency, or throwing things away? Change is one of the true constants in the world - as is human inability to predict the future. One tiny consequence of that fact is that engineers sometimes need to throw stuff away.


2

I think it at least partly depends on the nature of your situation. You mentioned constantly changing requirements. If the customer says "I want this bee-keeping application to also work with wasps" then that seems like the kind of situation in which careful design would help progress, not hinder it (especially when you consider that in the future she might ...


2

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 ...


2

Releasing a piece of software as not beta should only be done after testing. You will lose most of your customers, when only one GUI element is not working. For example, a well known online clothing company (I don't know if I'm allowed to write down the name) released an update to their Website which doesn't allow chrome users to access their shopping cart ...


Only top voted, non community-wiki answers of a minimum length are eligible