The stereotype of thinking in programming

The speed of IT development is so high that many technologies and ideas do not have time to pass the test of time and become de facto standards. Sometimes we follow these standards in the herd principle - like everyone else, and I. It is very easy and comfortable. And sometimes these ideas become so unshakable that we follow them fanatically, not trying to think it correctly or not.



1. Method code should fit on the monitor screen.
Do not take it too literally. I would paraphrase it like this: you should not write methods that do more than one clear concrete action from the point of view of application logic. Those. if the circumstances are such that your method cannot be less than 300 lines, you should not split it into separate methods. The names of such methods will not say anything to the developer. You will only create confusion in the code. After all, these methods can only be called in a certain order, forming an unchangeable chain of sequence.
Once I needed to add a few additional overloads for the application logic method that affected the UI layer, the public and admin parts. With the admin controller figured out quickly. But there were problems with the public.
Calling a method that I might need to change. He was in a mysterious method, in which there was only a walk through the cycle with a set of actions that I did not talk about. But he was lines 10! To understand what is happening here, I have risen to a higher level, where this method is being called ... Then I had a keen sense of deja vu - again a short mysterious set of operations in a short, faceless method. And as evil, my business logic method was invoked in several such codes. Thanks to the author of this implementation, for keeping me from reading one clear and specific method, even if it does not fit into the monitor screen. Replacing it with heels what the hell.
')
2. Static is bad!
There are a lot of programmers around me who are convinced of this, I think among you too. I do not even know where the legs grow from this stereotype. I heard only one more powerful argument - statics are more difficult to cover with tests. Only common sense tells me that the key point here is not taken into account: what comes first and what comes second. Those. who under whom should adapt. This is the same as the human body must adapt to the clothes we buy in the store.
By the way, here's another interesting variation of this stereotype: Static is bad, and extension methods are cool! <irony> It can not be ... </ irony> .

3. The more patterns I use in my implementation, the better I am as a programmer.
A very interesting way to self-affirmation. Leave your CRS, and regret the colleague who will try to make changes to your implementation, shoveling the 5th wrapper, most likely he will think: “In my opinion I lost my way ... I’ll use the search for the project, and after all, I had to replace true with false, in obvious functionality. "
Use paternes not when they come here, but when you see a particular advantage in using it <irony> or when you want to do an extra level of abfuscating your code </ irony> .

4. IoC container is our everything!
I assume that this is another way to assert itself among colleagues. Having the ability to easily substitute one implementation for another is great! It's really cool. But only if you see a situation in which you may need it. For example, the replacement of one engine to another. But this does not mean that this mechanism should support all your code. It comes to the absurd. I saw a commercial code in which the possibility of quickly replacing some subtle entities with others (classes in which properties were declared without any logic) was implemented. A very useful feature, isn't it?

5. We love Code first (talking about the Entity Framework)!
Always considered Code first a wiser approach. For me, the code is primary. It is important for me how I will manipulate the data in the code. A database is only a box for parallel access to data. Today I use one box, tomorrow another. But I confess, 5 years ago, my commitment to Code first was banned. Such an approach caused ridicule from colleagues, or a hint of my incompetence. How will this database be based on the program code, and not vice versa ?!
Now, when Microsoft began to promote Code First, everyone became sharply its supporters. Those. the majority opinion has reversed. Has something changed in IT? Not counting the advertising company Microsoft. The stereotype has changed.

The bottom line : stereotypical trend following is evil. And in my opinion, this is the greatest evil in modern programming. Every approach, solution should have a tangible, rather than an abstract justification. If your example of using a trend is not clear or absurd for these realities, stop using it. Otherwise, you will write applications that later, it will be unpleasant for you to accompany.