Anti-pattern for October Franken Code
The title of the Anti pattern is Franken Code, the sub-title is” It's alive! What could go wrong”
The elaboration is read as: Code consisting of bits and pieces of other, possibly unrelated, code that only barely performs its function and is prone to error. Much like Frankenstein's monster, such code can wreak havoc on users
This link provide some further reading on the anti-pattern (including an interesting photo). For your convenience, I copied some here:
Frankencode refers to code that was never designed to work together, being pulled into a single application and held together with duct tape, baling wire, and maybe some Adapter design pattern usage. While software reuse and compatibility are desirable, frequently software that has been developed independently is written using incompatible assumptions and design decisions. Thus, when integrated together, the result can be clumsy and poorly architected, at least when compared to software that was designed to work together within the problem domain being considered.
Quotes
Quotes
"...learn from my miseries, and do not seek to increase your own." - Mary Shelley, Frankenstein
The following is a story a close friend of mine told me:
Not long ago, I came across a Web application. The project was established as a fixed bid contract by iterative delivery scheduled on features. in each iteration. The developers are working hard just for that feature assigned to him or her. There was no refactoring effort, no design effort, and you guessed, no unit test case as well. Just coding and coding...
I have tired very hard to tell the engagement lead, project manager and the "Solution Architect", ( I put the quotes on the solution architect, as it is a Net project, but the solution architect is a Java guy who could barely able to move around within Visual Studio) that this would create problem down the road. with feature based iterative delivery, without refactoring, you would have a collection of disorganized code block; without automat unit test, refactoring would be very risky to the stability of the codebase.
3 months into the project, we got a codebase with lower performance, low maintainability and high cyclomatic Complexity. From vertical point of view, each feature looks like the only feature in the system. From horizontal point of view, All methods and classes look disorganized to the extend beyond anyone's imagination.
In this project, they did not get the Franken Code from somewhere else, they produced Franken Code themselves.
Ok, This is the story I got about producing your own Franken Code. in Software development business, loosely coupled and high cohesive are every architect's goals. If you are doing traditionally water fall process, do have a proper design after you collected all requirements; if you are doing agile or any feature based iterative delivery, Collective ownership, unit test and refractory are your best friends. if you are taking bites from other source like Nuget or download them from the internet, that is fine as we all do that. but you need to do it with your eyes open. the following are some important aspects to be aware of when you do that:
1. you want to get something in the framework level, for example, the library to interact with Web Api service, the library to interact with database. you would not want to get a third party package take care of your business logic.
2. you want to get it from reputable source. Microsoft, Nuget.org, Codeplex, GitHub
3. you want to get the package that is meant for the net framework version and the visual Studio version. any compatibility issue would cost you trouble down the road
4. you want to review the code after you get them into your project
In this project, they did not get the Franken Code from somewhere else, they produced Franken Code themselves.
Ok, This is the story I got about producing your own Franken Code. in Software development business, loosely coupled and high cohesive are every architect's goals. If you are doing traditionally water fall process, do have a proper design after you collected all requirements; if you are doing agile or any feature based iterative delivery, Collective ownership, unit test and refractory are your best friends. if you are taking bites from other source like Nuget or download them from the internet, that is fine as we all do that. but you need to do it with your eyes open. the following are some important aspects to be aware of when you do that:
1. you want to get something in the framework level, for example, the library to interact with Web Api service, the library to interact with database. you would not want to get a third party package take care of your business logic.
2. you want to get it from reputable source. Microsoft, Nuget.org, Codeplex, GitHub
3. you want to get the package that is meant for the net framework version and the visual Studio version. any compatibility issue would cost you trouble down the road
4. you want to review the code after you get them into your project
