Re: The structure of PHP/Web Application coding.
- From: Henk verhoeven <news1@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 01 Jul 2007 17:23:48 +0200
Hi Peter,
From your mentioning of Design Patterns i assume you want to/are practicing OOP. By far the most of my experience is with OOP, so i need to make this assumption to think that my reply is relevant.
Peter D. wrote:
I have been programming PHP for a while now and always seem to run
into the same problem when working on more than trivial apps. Most of
my coding is for personal projects anyway so it really isn't a big
deal but I hopefully plan on doing more serious coding in the future.
My problem is that as I code and the app grows ever larger, I always
feel like I am digging myself a hole I can't get out of in the end. My
code is alright, readable and not too bad to debug but I always get
that feeling like I shoul d be re-considering my design choices now or
I might really be in trouble later.
Do you guys ever get to that point? If not, how do you avoid it?
Certainly! And even with 14 years of experience with OOP and a strong focus on design & reusable code, i don't feel ashamed. A litle bit of History: Much of OOP as we know it was invented during the development of Smalltalk. Smalltalk was strongly influenced by ideas from congnitive psychology and was not only a programmign language, but also a concept and technique of user interfacing, an IDE, and a new aproach to programming as a taks for humans. Other programming languages (and Graphical Operating Systems too) have since the 80's been cherry-picking from Smalltalk, but it still seems not commonly known how brilliant and ahead of its time Smalltalk has been.
Some of the leading old school Smalltalk developers have extended the Smalltalk aproach to programming into a more complete and explicit method: Extreme Programming (XP). One of the most controversial guidelines of this method is not to think far ahead in your design but instead, build "the simpelest thing that could possibly work" for your current purposes.
Of course this can not lead to reliable and maintainable software without a second guidline, that balances the first: "Refactor relentlessly". Refactoring is improving the design of existing code. This is not something to do after several months of coding. Refactoring should start allmost immediately from the start of any project and is to be done so frequently that it comes close to being done "all te time".
As extreme the XP guideline of "the simpelest thing that could possibly work" is in terms of designing ahead, it is in terms of the desing itself: "the simpelest" is defined as "once and only once". Basicallt if you have any piece of code that is the same, or very similar to any other piece of code, you need to refactor it into one piece of code that is reused for both tasks.
Of course reuse has its limitations, sometimes it just makes things too complex, so in practice you allways have to make compromises. But the message remains the same: You need to re-consider your desing choices *much much sooner* to avoind getting into trouble. A design is only a temporal optimum. If you add some code, the optimum will change. That is not something to be avoided. There is no need to be ashamed about it. It just needs to be done right away, and not to be postponed until it is a big task. The hunt for simplicity is allways on, relentlessly!
I know that with the right amount of planning anything can be
accomplished in a reasonable amount of code/time. I guess what I
really want to know is if there is any kind of code strategies that
work well when designing an application.
For more info on refactoring, you may read the well-known book "Refactoring" of Martin Folwler.
For more info on Extrme Programming, you may read "eXtreme Programming eXplained, Embrace Change" from Kent Beck.
Of course the desing depends on the application. But if you are developing similar applications as i have been doing, you may consider using a framework. IMHO a framework is simply the outcome of applying the principles of XP over the development of several similar applications. Withing a single project the principle of "once and only once" will already leads to some code being heavily reused. If you try to use that code in a second project, it will inevitably need more refactoring. I have been doing that refactoring in such a way that part of the code can be used in both projects. I have repeated that process over several projects. And i have repeated the entire process of building frameworks three times, each time starting from scatch, but reusing the designs of the previous generation, but also throwing out as much as possible to make the simpelest thing that could possibly work.
Some XP proponents will not like this idea, they will point to the principle of "travel light" and say that the frameworks make you carry around a lot of uncecessary (complex) code, that's not necessary and does not need to be so complex for the application at hand. I agree, but i have several reasons to prefer using the framework over starting from scratch every time:
1. With the framework i have a starting point, a basic design for the application that is based on practical experience from former applications i refactored the framework from. Yes, i loose time on complexity, but i win time on doing sort-of the right thing.
2. In the early stages of application development the framework has proven to be adding most to my productivity. In fact the first prototype will be available ten to twenty times sooner then when i have to start from scatch. That means earlier customer feedback. Earlier feedback means earlier clarification and maturing of requirements. That means less time spent on building the wrong things, and *much* less risk of running out of time becuase of that.
3. In the later stages it may occur that some parts of the application are not similar enough to profit from the framework. That's no point, having the framework does not stop me in any way from building them from scratch.
4. The choice of XP to start simple and refactor later is based on the assumption that the investment of the software community in better tools, practices etc. has payed of, resulting in the costs of change not rising dramatically over time, but instead flattening out. What if the investments in frameworks are doing just that? Traveling light is a good thing who would refuse to use a car when having one and the roads are clear, just because the car is adding a lot of weight?
I've read a lot about Design Patterns (Factory, AbstractFactory) and I
just can't seem to think far ahead enough in my code to be able to
implement these patterns succesfully.
To be honest, i never tried to implement a pattern. It just happens that when i am looking for "similar code" that i may eliminate, these patterns help to find it and give directions on how to get rid of it.
On the other hand, when i am not looking for patterns, my code often tends to evolve into something similar to some patterns anyway. Simply because the problem i am trying to solve is similar and the pattern is the simpelest solution.
But in the end, i do want to get rid of the patterns as well. In the end, patterns that occur several times in the same applications often can be refactored so that the pattern is only on one place...
Are there any sites which clearly give examples on how to design
medium to large applications that are scalable/simple... or am I just
still too new to the game and just need to practise my coding a lot
more?
Maybe you just need practicle examples. In Smalltalk we had the class library and the code of the IDE itself we could learn from. Not allways brilliant code and not really a solution on uncovered grounds like persistency, object caching, transactions etc. but it was a start. Most Smalltalks also offered a powerfull IDE for browsing and searching and did not keep much code 'out of sight' to application developers. PHP does not include a class library, but there is PEAR, and the are several good open source frameworks available.
I think that you can learn a lot from using such a framework. Use it as a white box, not a black box: when building your applications, study the code of the framework, look for undocumented features, for ways to write less application code by using some framework code in undocumented ways. In the beginning this will slow you down. Or more correct: it will slow down your progess with developing your applications, but speed up your learning. If learning happens to be what you want, that's time well spent!
Greetings,
Henk Verhoeven,
www.phpPeanuts.org.
phpPeanuts is a framework for developing business applications in php. On the website the main tasks of application development with the framework are documented and demonstrated in tutorials that come with working code examples. The use and study of the framwork as a white box is supported by the hypercode browsers, that allow you to browse and search the framework and examples code on line.
N.B. From the above you may conclude that the better frameworks are relatively small compared to the functionality they offer. They only offer generic functionality and allow/expect application developers to add apllication specific funtionality without having to modify the framework itself.
.
- Follow-Ups:
- Re: The structure of PHP/Web Application coding.
- From: Peter D.
- Re: The structure of PHP/Web Application coding.
- Prev by Date: Re: Trouble with $_POST data
- Next by Date: Re: The structure of PHP/Web Application coding.
- Previous by thread: Trouble with $_POST data
- Next by thread: Re: The structure of PHP/Web Application coding.
- Index(es):
Relevant Pages
|
