IT professionals,
specially developers how are we supposed to deal with this huge amount of
changes, new concepts, APIs, technologies… ???
The IT world is moving fast we should be open
minded to accept changes. For example the old debate around ASP webforms VS ASP
MVC or when Node.js came out many said that using javascript
in both client side and server side is out of question (I don’t like
programming in javascript either but it is not a reason to treat Node.js as a
crap before even trying it).
We as developers we should know that there is no magic
solution or silver bullet for everything, we should use the right tool
( i will use the word tool to represent concept, pattern, methodology, language,…) for the right job.
Simple example: personally I found Webforms more fitted to
administrative pages than MVC, and MVC more suited for internet applications
than Webforms. Node.Js is more suited for certain type of application like sending updates to user in real time (long-polling).
Even some design patterns may become useless over the time (depends on the context).
Let's take the repository
pattern as example, we can find this pattern everywhere but did we really need it ??
This pattern came
out before actual ORMs. ORMs are already based on this pattern so why adding
additional abstractions specially for reads operations (make a controller that
calls a data service layer that calls a repository data access object that
calls an ORM that generate an sql query). Note, that I’m not saying that the repository pattern is
useless but we should ask the question if it is really needed (e.g if it is
used only for data access and we don’t need change tracking we could use simple
solution like Massive instead of NH or EF with all the added overhead). This
leads as to the next point
2-Don’t follow blindly, always try to understand when to use a tool and more
importantly when not to use it:
Usually when a new tool* came out we found articles, blog
posts and demos(usually with trivial examples that mislead the community of
developers) showing how to use this tool and advantages of using this tool. But
we notice that it is hard to find when not to use this
tool (you should dig and have an objective critical mind). As I said
earlier, we should use the right tool for the right job, in order to do that we
should know when and when not to use it depending on the context.
3-Orchestrate altogether: how to use the right tool is
good, combining all the tools together to get the right result is better and
also harder. Sometimes the problem is not on the set of the tools or knowledge of
how to use the tools but the challenge is how to combine them. This story from
Udi Dahan (one of my favourite blogger) illustrate what i meant.
4-Understand the context: in short use the right tool for the right job within the right context, some tools that applies in situation or project X doesn't mean that it is true in another situation or project Y even if it may seem similar.
Another point, don't lie on assumptions specially for performance or concurrency problems. For example, you may use every optimization technique that you are aware of to reduce response time but the only way to be sure of that is by testing it and doing a stress test. (just because that is an optimization technique that worked for another project doesn't necessarily mean that it will optimize your current one at least you can't be 100% sure of it).
That is it for this post probably there is more but these are the main advices that i have in mind now and that i think that are the most important to face the huge amount of innovations on the IT world.
0 comments :
Post a Comment