1) When creating an application in a new way in Delphi that most people using Delphi wouldn't want to, I saw that the result was not so good, but it was doable.
I think many folks end up with similar programs. They aren't really proud of the outcome, but it works!
2) When maintaining somebody else's program that was written in Delphi, I saw how the most common way of developing programs in Delphi resulted in. Lots of events, barely connected one to the other, lots of headaches when creating new modules for the program, mainly when you aren't totally used to the way it should be programmed.
This is common as well. It's how you try to use the best of what your tools offer. You do your best at creating the program, but the result is just good enough because it works, but is hard to maintain.
3) When creating my own libraries and frameworks with the help of Ruby and its community.
It takes a hell of a lot of time. It drains your forces. The means end up becoming too important in relation to the ends. The means are hard to get right, and if you settle down for a poor means, you won't improve it much to make it worth the time necessary to get it to work. But hopefully you can be proud of the result of your work. Maintenance should be easier. The development should be easy. But the time is too expensive and you hardly will use your remaining steam to share it with others, so all in all, you are on your own and probably the means have become crucial to you and your busines.
The problem with creating your own tools, libraries, frameworks, is that creation is much harder than destruction. As you say, it's hard to think about all the necessary features and implement them. On the other hand, program writers basically are destructors. They will use everything that they can and cannot in your tools, because even them need to create, and they won't be happy with the roadblocks of your tools. Basically, program writers will not have time to fix anything in your tools; even if they try to, it probably will be only the minimum necessary to get their projects going.
So, I agree. Planning for reuse is mostly a lost cause. KISS all the way.
> Yes, I was actually hoping for war stories rather than > opinions.
Well, where I work right now we have a custom persistence framework. It takes way more code to use this than it would to just write straight JDBC and the resulting systems are absolutely impossible to follow.
That it actually takes more work to use the framework and it provides no extra value over the naive solution makes it really frustrating.
> How about a document(oftimes JSON or XML) which describes > the steps necessary to the task and the relevant details. > > Then write a program to read the document and execute the > steps. >
Indeed, for a simple case this is a valid approach. However, I doubt it will scale up well with complexity.
> Mine is the above, then. I tried building a framework for > OLAP datastores and it quickly spiraled out of control. I > couldn't even use it easily so I can't imagine what others > would have thought of it. It got very big very quickly.
And my own experience is that you don't get a good design, especially for reusable code, right away. It usually requires throwing away or redesigning many times before you understand the issues well enough. And it seems to me to be more common in this industry -- especially with the low barrier-to-entry afforded by open source distribution -- to say "I've done the work, I think it's decent, so I'll put it out there." Unfortunately, it requires a lot of time and effort by someone else to figure out the framework, and to discover whether it's worth spending time with or not.
I think the point of this goes beyond frameworks. One of the biggest problems I see when people try to make code resuable is that they try to do too much. The kind of thing that I commonly see is that someone creates a helper function to do something like parse data from a properties file. All good so far. Then (I think) they realize that every time they call this method, they take the value and pass it to a method on a certain type. They think, "Oh, i can eliminate all this repetative code" and go back and change the method to take the String to parse and the Object to pass the parsed data to. Later, when somone else comes along, they can't reuse this method because they aren't using that Object type.
This may seem crazy but I have indeed seen code like this but it's not normally this simple. There are usually a few more classes involved but the end result is the same, the useful piece of reusable code has been coupled to a bunch of non-reusable pieces of code.
I think this kind of thing comes from dogmatic adherence to rules of thumb like 'don't repeat yourself'. Some people just know the catch-phrase but don't understand the concepts behind it and sometimes this is worse than knowing nothing about it at all.
> Yes, I was actually hoping for war stories rather than > opinions.
OK, here's one (kind of). Our framework development process changed over time.
Application and framework was developed in parallel by 2 teams with roughly the same release dates (framework just a notch ahead of the app). The release process was highly unstable and it took about 3 iterations to get the next version right.
In order to get predictable releases we switched to building the apps only on released version frameworks. The dev process is then: App v1.0 -> Extract Fw v1.0 -> App v2.0 (using Fw 1.0) -> Extract Fw v2.0 ...
This process is good from a release stability perspective. However, it does not guarantee that the extracted fw is actually usable. Therefore the process will change (most likely) to: App v.1.0 -> Extract Fw 1.0 -> Merge App v1.0 and Fw 1.0 into App v1.5 and Fw 1.5 -> App v2.0 (using Fw 1.5) -> Extract Fw 2.0 -> Merge App 2.0 ...
We hope the early merge of Fw and App into vX.5 is "proof" enough that the extracted framework works as it should.
> OK, my definition of reuse is: > > A) If you did not have to write the code yourself, and it > exists without any pre-existing knowledge of your needs > (that is, another member of your team did not write it > because you asked them to), then you are reusing it. > > B) If you write some code that someone else is able to > reuse (again, without them specifically asking you to > write it), then you have written reusable code.
Hm,... With this definition, you can not reuse frameworks within their domain, right? You just use them.
> The problem with that, which I'll guess is the case Bruce > talked about in the original post, is that this is really > hard to do in practice. I've never successfully built a > framework. I've put together plenty of libraries and a > couple of DSL's, but I hope to never build my own > framework. I have two reasons for saying that.
I think the concept of library is better...frameworks dictate the way to work, which is where the problem is; whereas a library of highly decoupled components can be much easier to extend and manipulate.
> > The problem with that, which I'll guess is the case > Bruce > > talked about in the original post, is that this is > really > > hard to do in practice. I've never successfully built a > > framework. I've put together plenty of libraries and a > > couple of DSL's, but I hope to never build my own > > framework. I have two reasons for saying that. > > I think the concept of library is better...frameworks > dictate the way to work, which is where the problem is; > whereas a library of highly decoupled components can be > much easier to extend and manipulate.
This is also the value of (good) frameworks. They do something really well and allow limited customization by providing hooks. The problem arises when people try to combine the goal of a library with a framework. Frameworks should be pretty focused. The complexity grows exponentially as you add more features and customizations.
My current project (99.016 lines of java code) uses basic Application Layers. Which is separated into the following jar-files, where each groups is only allowed to call down to a jar-files that lay under them.
GUI | JSP - Contains GUI/JSP stuff ------------ Core - Contains all domain-logic ------------ Enterprise - All extra stuff that isnt specific to the domain. Like Money-class, Generic-Dialogs, CollectionTools.
Each new lines of code is written an then moved down as fare as possible but keeping the domain-code in the core, and then removed if there is any form of duplicated code.
This way one can see Enterprice as a form of collection of libraries.
The reason for making the Enterprice layer is that, that is excluded from the "No Dead Code" rule.
The two rules that lead up to this design was "No Duplicated Code" and "No Dead Code".
There is however still duplicated code in the code and a homemade O/R-mappping which I aim to remove.
> > Application and framework was developed in parallel by 2 > teams > > If the framework-team only has the application-team as > their only user then I would recommend merging the two > teams. Thus reducing cost.
There are 6 app teams using the framework. With only one client application a framework is not necessary.
> I think the point of this goes beyond frameworks. One of > the biggest problems I see when people try to make code > resuable is that they try to do too much. The kind of > thing that I commonly see is that someone creates a helper > function to do something like parse data from a properties > file. All good so far. Then (I think) they realize that > every time they call this method, they take the value and > pass it to a method on a certain type. They think, "Oh, i > can eliminate all this repetative code" and go back and > change the method to take the String to parse and the > Object to pass the parsed data to. Later, when somone > else comes along, they can't reuse this method because > they aren't using that Object type. > > This may seem crazy but I have indeed seen code like this > but it's not normally this simple. There are usually a > few more classes involved but the end result is the same, > the useful piece of reusable code has been coupled to a > bunch of non-reusable pieces of code. > > I think this kind of thing comes from dogmatic adherence > to rules of thumb like 'don't repeat yourself'. Some > people just know the catch-phrase but don't understand the > concepts behind it and sometimes this is worse than > knowing nothing about it at all.
I disagree, the problem here is that the developer doesnt refactor, he changes the way stuff work. the problem you describe is that the developer doesnt split the generic functionality "parse properties" from the domain specific object. Instead of building a domain-specific parser ontop of the generic one, the change the generic one, this can only happen if the generic one is in the domain-specific layer.
Not following "don't repeat yourself" quickly become a nightmare when you need to change the system since now you go two places that does the same thing and dont know about it thus changing it in one place.
To the "Oh, I can eliminate all this repetative code" I say: Refactor! Do not change the functionallty just remove the duplicated code!
> We hope the early merge of Fw and App into vX.5 is "proof" > enough that the extracted framework works as it should. > > Thoughts?
Maybe try shorten the release cycles of the Framework team, so that the App teams can contribute more code to the framework team, and the framework teams primarily task then becomes how to transform the suggestions/code/classes/modules from the app-teams into a cohearant framework.
Have you look at the process that Sun uses to decide what is going to be in the next version of Java?
> I disagree, the problem here is that the developer doesnt > refactor, he changes the way stuff work. > the problem you describe is that the developer doesnt > split the generic functionality "parse properties" from > the domain specific object. Instead of building a > domain-specific parser ontop of the generic one, the > change the generic one, this can only happen if the > generic one is in the domain-specific layer. > > Not following "don't repeat yourself" quickly become a > nightmare when you need to change the system since now you > go two places that does the same thing and dont know about > it thus changing it in one place. > > To the "Oh, I can eliminate all this repetative code" I > say: Refactor! Do not change the functionallty just remove > the duplicated code!
I don't think you understood what me. I never said not to follow DRY. I said people who don't understand it are taking it to the nth degree. My example also has nothing to do with changing functionality. It's about inlining code that should not be combined.
Any code is going to have repetative parts to it. For exmple, how many for loops do you have in your code base (assuming it's not in a functional language.) You could write a for loop helper class that would make it so that you only have one for loop in your entire code base. But that's stupid. But if you dogmatically follow DRY, you might think that is a great idea.
This is a common problem. There are many developers who read a good tidbit of advice and then take it way beyond what was ever intended by those giving the advice. For example, there are thousands of lines of code that I deal with where the developer never uses the Java + operator for Strings. They always use StringBuffer. That is very misguided but people will tell you it's good practice. I think a perfect example is the 'drink before your thirst' nonsense that is popular in running. The basic premise (stay hydrated) is good. But some people have taken it so far that they have literally dropped dead from drinking too much water. It's an old saw but a little knowledge is a dangerous thing.
Flat View: This topic has 56 replies
on 4 pages
[
«
|
1234
|
»
]
Previous Topic
