Slashdot Mirror
Reusing and Recycling Code
An anonymous reader sends us to a writeup about when and how to recycle code, excerpting:
"As developers, once we start separating our code into abstract ontological typologies, we make use of the human mind's phenomenal ability to work with types. Our code becomes less about jump tables and registers and more about users, email messages and images. What once was a problem of allocating resources and operations within the computer becomes an abstract, logical problem within a collection of objects....Over time, by constantly working to reuse our own code, we choose practices that work well for ourselves and discard practices that don't work as well or slow down our workflow. For developers flying solo or those working on small projects, this evolutionary process is a sufficient way of going about things. But there's trouble when we add other players into the mix--other developers, a user interface person, a database person, a sysadmin, a project mana-jerk: as a developer, they don't have access to our 'experience' of the code and we don't have access to theirs. "
If you think about how much energy is needed to produce (good) code, recycling it will also help to save the environment!
Seriously!
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
To quote from the fine article itself:
My psychic abilities tell me you're wondering why this wall of text was worth your time. It probably wasn't.
What he talks about in terms of PHP is precisely what Lisp macros are about: you identify common patterns in your code, and then you generally break the patterns into a couple of short, generic functions and a macro, or sometimes, just a macro will do.
In any other language you build a library of functions, classes, etc. to do the common things that you want to reuse.
The above applies to PHP as well. It has the include filename construct for a reason.
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
That's quite a rant on programming for a Javascript form field validator.
The right answer to this problem was probably WebForms, which added support to HTML for basic form validation. WebForms provided for simple regular expressions in HTML forms like this one for a credit card number: />
<input type="text" pattern="[0-9]{16}" name="cc"
If the field didn't match the pattern, the browser would tell the user, in a standardized way, probably at keystroke time. The browser would also do things like prevent alpha entries in a numeric field, something that IBM green screen terminals were doing in the 1970s. (You could even program a keypunch machine to do that.) It's kind of lame that HTML forms never had any built in input validation.
For some reason, the WebForms proposal made very slow progress and never caught on.
You also have a hidden point in there. A lot code is just not useful for more then the app it was originally designed for, and breaking it down into smaller modules and functions usually just creates simple loops or recursive functions, and thus no point in saving them for later use as they can be replicated in the same amount of code space.
I don't really understand what the OP is trying to convey, anyone who has learned programming in the last 5-10 years (probably longer) from a half way decent school should be familiar with OO design, which is all he's blathering on about. I mean, almost anything I develop relies on a collection of APIs and libraries to do a majority of the functionality, its just a matter of combining the blocks to get the desired effect. The "tedious" functions in most development enviroments have already been done for us, hell the only time I can recall adding anything to the development libraries was when I added a split function to the dumb Delphi Pascal crap we were using.
I'm all for code reuse, as long as it makes sense.
"Now you know, and knowing is half the battle!"
I am currently a database manager where I work, but that title belies the complexity of what I have to deal with on a daily basis. We are producing our "next gen" web application whilst keeping the old, but money generator up and running under the pressures of increasing user load.
Even though I am the database guy, my vast experience with software engineering has given me a "unique" role in knowing the developer's side and having a lot of input on their design decisions, as well as having huge impacts on systems.
One poster mentioned not having access to various skills and expertise in a variety of areas, and yes, there's a lot of that at my shop, so I tend to try to "bridge the gap" as it were, to help my DBA team interactt smoothly with Dev and Systems, etc.
Code reusability is a big issue in our development of the NextGen system, because the old code (that's currently pulling in the $$$$$) is not supportable, being written badly in PHP4 has resisted all attempts to upgrade. The NextGen approach uses OOP ery heavily, and also relies on stored procedures to keep the SQL out of the code and allow my DBA team to tweak and enhance performance without impacting the code base. It makes for a sweet division.
But I do find myself doing lots of talking and less actual "hands-on" development these days. Kinda crazy running around talking to various department heads, managers, project leaders, QA, and the like.
I guess I am speaking to a greater issue than code usability -- human communication to keep us all on the same page and to allow us to leverage each other's expertise. All of our efforts together represent the future success of our endeavors.
Ruby Neural Evolution of Augmenting Topologies
This assumes the code is good. If it isn't, it's akin to eating your own vomit.
In my current project we are using a third party library that is very powerful and comprehensive, but the API is overly complex and poorly documented. It takes a year or two before it stops being mysterious and becomes merely frustrating. Writing code that is easy to re-use is an uncommon art.