I'm beginning to realize that developing software is (amongst others) a process of constantly asking yourself questions. Questions regarding quality of code, separation of concerns, minimizing dependencies, ...
But the main question is: how far can you go without ending up in a mental hospital?
I'm applying for a new job. Yesterday I was with a possible future employer who wanted to test my programming capablities. One of the exercises was: explain what this code does. I went through some code of the application (winforms in vb.net) that they develop (it's an administrative application for a hospital). This gave me the opportunity to actually see how they approach things and it was rather disappointing.
- I saw somewhere: Call [insert name of subroutine here] -> I was struck: isn't that something from VB6?
- They have a separate datalayer, using ado.net, but one method I had to examine returns a dataset to the calling layer. So separate datalayer or not, the application is tied to ado.net (which could also never be a problem if they never switch to another data access approach).
- That dataset is read as-is, so it still is a data-centric approach (of course, one can argue how much logic/behaviour you can put in classes like "Patient" or "LabAnalysisRequest".
- I also believe to have seen the construction of an sql query by string concatenation.
- They use stored procedures (which, to me, means: scattering of logic)
- no mention of views/controllers: it's all form driven
- The most ugly thing I saw was:
If TestEnvironment.IsTesting then someVar = [some hard coded value] else someVar = [some dynamically retrieved value] end if [remainder of the function here]
It's all so different from what I learned in school: (persistence agnostic) domain layer, persistence layer, presentation layer, unit testing, ...
So I rephrase my question: how fundamental or dogmatic should one be? To what extent should a programmer stick to his or her principles or just write code that does the job?