[Php-objetos] Manual PHP POO

[Mario Gomez Cassou]

Consegui el libro "PHP Objects,Patterns, and Practice" de Matt Zandstra (parece que es medio capo; es programador senior de Yahoo) y parece que esta muy bueno. Tiene mas de 500 paginas y esta en ingles asi que no es precisamente una lectura liviana, pero creo que esta bien escrito. Si a alguno le interesa lo puse para bajar en www.gomezcassou.com.ar/archivos
Copio la primera parte donde describe lo que puede suceder programando en forma desordenada.
Saludos
Mario


------------------------------------------------
The Problem

The problem is that PHP is just too easy. It tempts you to try out your ideas, and flatters you with
good results. You write much of your code straight into your web pages, because PHP is designed
to support that. You add utility functions (such as database access code) to files that can be
included from page to page, and before you know it you have a working web application.
      You are well on the road to ruin. You don’t realize this, of course, because your site looks
fantastic. It performs well, your clients are happy, and your users are spending money.
      Trouble strikes when you go back to the code to begin a new phase. Now you have a larger
team, some more users, a bigger budget. Yet without warning, things begin to go wrong. It’s as
if your project has been poisoned.
      Your new programmer is struggling to understand code that is second nature to you, though
perhaps a little byzantine in its twists and turns. She is taking longer than you expected to reach
full strength as a team member.
      A simple change, estimated at a day, takes three days when you discover that you must
update 20 or more web pages as a result.
     One of your coders saves his version of a file over major changes you made to the same code
some time earlier. The loss is not discovered for three days, by which time you have amended
your own local copy. It takes a day to sort out the mess, holding up a third developer who was
also working on the file.
     Because of the application’s popularity, you need to shift the code to a new server. The
project has to be installed by hand, and you discover that file paths, database names, and
passwords are hard-coded into many source files. You halt work during the move because
you don’t want to overwrite the configuration changes the migration requires. The estimated
two hours becomes eight as it is revealed that someone did something clever involving the
Apache module ModRewrite, and the application now requires this to operate properly.
     You finally launch phase 2. All is well for a day and a half. The first bug report comes in
as you are about to leave the office. The client phones minutes later to complain. Her report
is similar to the first, but a little more scrutiny reveals that it is a different bug causing similar
behavior. You remember the simple change back at the start of the phase that necessitated
extensive modifications throughout the rest of the project.
     You realize that not all the required modifications are in place. This is either because they
were omitted to start with or because the files in question were overwritten in merge collisions.
You hurriedly make the modifications needed to fix the bugs. You’re in too much of a hurry to
test the changes, but they are a simple matter of copy and paste, so what can go wrong?
     The next morning you arrive at the office to find that a shopping basket module has been
down all night. The last-minute changes you made omitted a leading quotation mark, render-
ing the code unusable. Of course, while you were asleep, potential customers in other time
zones were wide awake and ready to spend money at your store. You fix the problem, mollify
the client, and gather the team for another day’s firefighting.
     This everyday tale of coding folk may seem a little over the top, but I have seen all these
things happen over and over again. Many PHP projects start their life small and evolve into
monsters.
     Because the presentation layer also contains application logic, duplication creeps in early
as database queries, authentication checks, form processing, and more are copied from page
to page. Every time a change is required to one of these blocks of code, it must be made every-
where the code is found, or bugs will surely follow.
     Lack of documentation makes the code hard to read, and lack of testing allows obscure
bugs to go undiscovered until deployment. The changing nature of a client’s business often
means that code evolves away from its original purpose until it is performing tasks for which it
is fundamentally unsuited. Because such code has often evolved as a seething intermingled
lump, it is hard, if not impossible, to switch out and rewrite parts of it to suit the new purpose.
     Now, none of this is bad news if you are a freelance PHP consultant. Assessing and fixing
a system like this can fund expensive espresso drinks and DVD box sets for six months or more.
More seriously, though, problems of this sort can mean the difference between a business’ssuccess or failure.



      Yahoo! Cocina
Recetas prácticas y comida saludable
http://ar.mujer.yahoo.com/cocina/
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://www3.fi.mdp.edu.ar/cgi-bin/mailman/private/php-objetos/attachments/20090222/81677b3e/attachment-0001.htm