Posts Tagged ‘framework development’
Like any type of design – software design has it’s trade offs. As example, if you componentize the process of binding and updating an object graph with a view you get great code reuse but if you step out-of-bounds you are usually stuck out in the code. But if you don’t componentize the process then your stuck with “copy/paste inheritance” which is another kind of madness in and of itself. So what to do? Good question. I don’t have the answer, but I think I have a few ideas. And that’s the point. There are no magic keys, no “golden hammers”, no CASE tools that leave you saying “I know Kung Fu!” Of course the hard part is knowing when your in this situation. For me it’s when I start telling my self “It takes an act of …” to get this done, or to work around. Here are a few things I have learned:
1) There is no one right way to solve a problem.
Have you found three methods of solving a problem? That’s okay, just make sure you give them a clear member name and you’ll be fine. If necessary just create a utility class, or better yet if you can use Microsoft .net 3.5 create a set of extension methods as necessary.
2) Keep the “have to” scenarios narrowly scoped yet flexible.
Have a required process to load controls into a UI framework? That’s fine, but don’t have the same component force other contracts on the control, and make sure you have several methods of being able to inject controls. For example, a required contract for loading UI controls could allow for using metadata, controllers/presenters or even configuration (if you really need it) to load the controls. You probably want to delegate everything else to the control.
3) Throw out that old code! (When you can …)
Over the course of a project you’ll more than likely come up with a new class or method to solve a similar problem that an older class or method couldn’t handle. Consider obsoleting the old code and extending the new code to handle necessary scenarios. Maintaining old code paths can be very frustrating and time consuming. Of course it depends on what the opportunity cost is. This often cannot be done in one release or update. Choose the right time to make the changes.
4) Overcome your complexity in the solution.
Most of us programmers love the puzzle solving in the process of software development. But sometimes the solutions are nightmare. So when you write that complicated solution to a problem there are at least two questions can be asked. First, has someone else solved this problem? And by that I mean not only another programmer but a software company. For example, there are better tools than StringBuilder for working with XML in the .net framework. (System.Xml.Linq) Is the solution “too big to fail”? Strongly consider breaking it up. Not only will the code base be easier to manage but you’ll have more options for code reuse that you may not have considered along the way.
5) Keep your code granular.
Your shower more than likely does not double as dishwasher. Tables usually don’t double well as chairs. Shoes don’t work well as gloves. And on and on. We should aspire to keep this in mind as we program. But this is not always easy. But if you can think of your code as individual parts of a digital assembly line and let every part play its role with utter simplicity. So more, no less. And besides – that’s how nature does it. We programmers could learn a lot from Biologists and Chemists.
Frameworks. They ease pain and inflict it. They make life easier, once you understand them. They seem so sexy to develop, and are yet so difficult to create that they can cause a person to throw in the towel all together. Okay all admit it – I am a Framework junky. I am still working on a 12 step program.
The truth of the matter is that writing frameworks is incredibly hard. The more ambitious the goals, the more likely you are to fall short. And if you’re one person, attempting to write a large framework, especially if it’s not your day job, can lead to deep personal frustration and exhaustion. I set my most recent attempt to write a large framework down several weeks ago with a mix of total relief and personal disgust. I had pushed way past personally imposed deadlines. I had added a ton of features along the way and started throwing them out at the last minute to bailout the project. Yet it wasn’t enough. A demo of the project revealed that there just wasn’t enough time available to get the project to the finish line, and it may not be marketable even if we got that far. I took a few weeks spending my personal time on other diversions. This is my first attempt to make any sense of it. I’ll try to boil down a few pointers as I can. What about you? Have you had any experiences writing frameworks in a team or individual setting that you would like to share?