Code rant: from hard coding to configurable, rule engine, low code DSL complexity clock

When I was a young programmer , Just started to enter the terrible world of enterprise software , An older 、 The more experienced guy hard coded my software hardcode The practice of puts forward a severe warning ." Hard coding will be changed at some time , You definitely don't want to recompile and deploy your application in order to change a value-added tax rate .”

I keep this suggestion in mind , Soon, every value my application needs must start from a huge .ini File loading . I still think this is a good suggestion , But notice , Like most things in software , It's a good suggestion to some extent . Beyond this point, there will be pain .

 

Let me introduce my “ Configure complexity clock ”：

This clock tells a story . We start from midnight 12 PM , There is a simple new requirement , We quickly coded it into a small application . It won't last long , Just a stopgap in a larger strategic plan , So we hard coded the values of all applications . A few months passed , This application is widely used , But there's a problem , Some business values have changed , So we found that we need to rewrite the build and deployment , Just to change a few numbers . This is obviously wrong . The solution is simple , We move these values into a configuration file , Maybe it's us App.config Some of appsettings, Now our time is 2 spot .

Time passed , Our applications are now somewhat ingrained in our organization . Business continues to grow , With its development , More values are moved to our configuration file . Now? appsettings It's not enough , We have groups of values and hierarchies of values . If we do well , Now we have moved our configuration to a special XML In the pattern , And is deserialized into a configuration model . If we are not so good , We may have stuffed duplicate and multidimensional values into some strange pipe separated strings , Now our time is 4 or 5 minute .

More time has passed , That annoying " Chief software framework t " Dismissed. , Our small applications are now at the core of our organization .

Business rules are becoming more and more complex , So is our configuration .

in fact , Before new employees can successfully deploy , There is a considerable learning curve . One of our new employees is a very smart guy , He has seen this before . He said ：" What we need is a business rule engine ". Now it looks promising .

Configure from XML Files are transferred to the database , And have their own special GUI.

At first , People want non-technical business users to be able to use GUI To configure the application , But it turned out to be a false hope ; Mapping business rules to the engine requires a degree of expertise , And this is only owned by some members of the development team . We are now 6 O 'clock .

 

What's frustrating is , There are still some business requirements that cannot be configured with the new rule engine .

Some logical conditions cannot be used at all GUI To configure , Therefore, the application must be recoded and redeployed for some scenarios . Help is at hand , Someone in the team read Ayende Of DSL book . Yes ,DSL Let's write arbitrarily complex rules , Solve all our problems . The team stopped working for several months to achieve DSL. When it's done , This is a considerable technological achievement , Everyone had a good rest . Of course , This will mean the end of any hard coded business logic ？ It's morning 9 Point time .

It's amazing , It can work . A few months passed , The core application does not need any changes . The team spent most of their time in the new DSL Write the code . After some embarrassing events , They are now deploying any new DSL The code will go through a complete release cycle before .DSL Text files are version controlled , Each version must undergo regression testing before deployment . debugging DSL The code is difficult , There is little tool support , They simply don't have the resources to build one for their new little language IDE or ReSharper. With DSL The code is getting more and more complex , They also began to miss being able to write object-oriented Software for . Some people in the team have begun to study the unit testing framework in their spare time .

In the bar after work , Someone joked that ：" We are back where we started four years ago , Hard coded everything , It's just that now we use worse language ."

They have walked around , Back to the 12 spot .

 

summary

Why tell this story ？ Tell the truth , I have never seen an organization come all the way , But I've seen many people walk to 5、6 or 7 I feel quite painful at all times . My point is that .

In a certain degree of complexity , Hard coded solutions may be the least evil choice .

You already have a general programming language , Before you build a business rule engine or DSL Before , Or even if your configuration passes a certain degree of complexity , Consider a more flexible build - test - Deployment cycle , Hard coding may be much simpler .

When you walk clockwise , Technology implementation will become more and more complex . It is difficult to build a good rule engine , And write a DSL Is more difficult . Every hour you walk clockwise , It will make the software more complex , More errors occur , And the learning curve of new employees will be more difficult . The more complex the configuration is , More control and testing are needed before deployment . Soon you'll find out , There is no difference in the length of time required between changing one line of code and changing one line of configuration . You find that your organization relies on a very rare skill , Not a common skill , For example, coding C#, You find that your organization relies on a very rare skill ： Understand your rule engine or DSL.

I'm not talking about implementing complex configurations 、 Rule engine or DSL It's not appropriate , in fact , If there are appropriate requirements , I will also seize the opportunity to build a DSL, But I mean , Before you go this way , You should understand the meaning , And recognize your place in time .