|
|
In an attempt to be crazy famous, I've devised a few tricks and tips to help a senior developer
to defend his turf from the Jr. Developer, like me, that is after his job.
These techniques I call Un-Factoring, since they are largely the antithesis of Refactoring(Fowler)
Stuff Method.
Whenever you see a method that takes an Interface as a param. Replace that interface with each and every
field from that interface. Even if it isn't used.
If you can add one or two extra params that are used for control flow, even better.
If your method has a return type of an interface or class, replace that with 'out' params as well.
10-12 params is a good rule of thumb. If you can get away with more, it is prefered to properly disguise
the method's intent.
Collapse Hierarchy
Inheritance reduces complexity, if you have few classes that derive from an abstract base. It may be wise
to collapse all the objects into one big one. Making extensive use of case statements to control the differences
in behavior. Doing such will freeze any Jr. Developer in their tracks, forcing them to understand all potential
cases of the class. Adding new functionality will then require the Jr. Developer to modify every case statement.
The Jr. Developer will have no choice but to run to you for help, thus affirming your station in the company.
Remove Cohesion
Classes that have methods acting only on their data are too easily understood. It is instead preferred to have
logic that modifies a class to be outside of that class. Methods such as IsValidNonHolidayDate(); should be
removed from a class entirely. Instead replace every occurrence of the call with the entirety of the method
logic. This will help insure that when a bug occurs involving NonHolidayDates, it must be fixed only by you.
Introduce Coupling
Sometimes decreased coupling occures when a Jr. Developer has read a new fancy book. Logic separated into
layers can be combated with Introduce Coupling. Subtle decoupling occurs when objects and methods rely on
interfaces instead of the implementations of objects themselves. Replace abstractions such as DataSet or ILists
with the appropriate UI widget, such as System.Web.UI.WebControls.DataGrid or System.Windows.Forms.ListBox, and
fill them directly in any data access code. This will insure that none of your code can be used outside of the
specific context in which you wrote it. You and only you will then be able to extend that functionality.
The following was contributed by ... maybe i shouldn't say...
Obfuscate Intent
Naming conventions sometimes work against you. If you can, don't identify member variables
in any way different from local variables. That makes the JrDev either spend a LOT of his
own time figuring out what is what, or come to you for help. Use variable names such as x, i,
and t extensively. This will pretty much guarantee you that you will work on this module forever,
without fear that some whipper-snapper will take over some of your turf.
If your language is case sensitive make sure not to standardize any capilization.
Remove Documentaion
Don't comment a thing, and if you're working on someone else's module, remove the
comments as you go. This coupled with Obfuscate Intent is very effective.
If using C# or Java, make sure not to comment in a way that can be picked up by NDoc, JDoc
or any other documentation building tool.
Hide Easter Egg
Mask warning messages in your compile with local compiler settings so that the Jr Dev
thinks it's something he's done and wastes a lot of his development time trying to fix them.
Never check in buildable code, especially if a Jr Dev requires it as a dependancy. By the time
figures it out, he'll be too tired to complain.
|
|