Wait what?
If you are working with systems that are transparent or applies failfast then dig into the following rules that will turn that system into a hard to understand/explain/extend/upgrade/debug/maintain/... thing.
With these rules you can keep working on the system for years in a less and less productive dialog with your users.
With these rules you can keep working on the system for years in a less and less productive dialog with your users.
#1: Don't log/measure/debug/comment
Make the code speak for itself. Elegance is the key. The simplicity of elegant code makes it easy and fast to read and write. Just like Math. Either you get or you don't.
Logging is a performance drain.
Measuring is not needed for optimal code.
Debugging sessions are never needed, if the code is like Math.
Comments are noisy and redundant information.
#2: Always catch - Never throw - 200 FTW
You are a competent programmer that can easily catch all possible exceptions from every possible path in the call hierarchy - so do it. You know what your code should do and you, if any, can turn every obstacle into a success-path in your code.
Why should anyone that calls your code be bothered with exceptions when they can be avoided?
Why should a user ever see an error message in a properly coded system? Never!
Imagine how disruptive it would be to have a unit in a distributed system sometimes returning http response code 401? Obviously, it is much more preferable to have any unit that always just gets the job done!
#3: Customize every function/service
Avoid simple atomic parts like CRUD and functions with only 1 purpose. The key is to understand what is needed and make that 1 function/service to do just that and nothing more. It gives the optimal calling code and the best performance. CRUD-like operations causes the calling code to have branches, control code and multiple calls. Good examples are AddIfNotAlreadyAdded, DeleteIfExisting, BulkEditIfExisting.
Please note that rule#2 and rule#3 complement each other. Only with rule#2 can we make a service called LogInQueryBestAndCheapestPrinterAddToBasketAddCreditCardInfoPurchaseLogOut.
Don't believe it!
CRUD and single purpose operations do exactly 1 thing or returns an error. This implies that conditionals, retries and error handling must be established at the calling side. In an application this causes the control points to move upwards in the call hierarchy and in a distributed system this causes the control points to move closer to the client. Some people claim that such an infrastructure can be re-used for multiple applications, but that is a poor solution compared to a custom-tailored high-performance solution.
Another silly idea is to engage the users by making the system transparent. In that school of thought a database error is displayed to the user, so that the user may issue the problem with a root cause, so it can be fixed quickly. Obviously, rule#2 - and you - will make sure that your users do not need to concern themselves with system errors.
