|
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. A guy like me, that is after his job. These techniques I call UnFactoring, since they are largely the antithesis of Refactoring(Fowler). Unlike Refactoring, which attempts to reduce complexity in stagnating "Factored" code, unfactoring is ... the opposite.
Stuff Method Whenever you see a method that takes an Interface as a parameter, replace that interface with each and every field from that interface. If you can add one or two extra parameters that are used for control flow you are on your way to a nicely unfactored project. I also suggest adding at least one parameter that is not used.
If your method has a return type of an interface or class, replace that with 'out' parameter. Ten to twelve parameters is a good rule of thumb. If you can get away with more, it is preferred 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 is also a good to make visual static analysis tools unusable. Collapse Hierarchy will freeze any Jr. Developer in their tracks, forcing them to understand all potential cases of the class. This technique is useful for adding the rigidity desired to 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 HolidayDates, it must be fixed only by you.
Introduce Coupling Sometimes decreased coupling occurs after a Jr. Developer has read a new fancy book. Logic separated into layers can also 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. Make sure to fill the UI widget directly in your 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 were contributed from a friend:
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 capitalization.
Remove Documentation 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 at the end of your day, especially if a Jr Dev requires it as a dependency. By the time figures it out, sometime after hours, he'll be too tired to complain. Using these techniques will insure the slow the progress of any OOP Developer that joins your team. Your managers will grow to respect your value over time. Expect to return from vacation with a raise after you save the day magically.
|
|
|