Blog
Dennis-Jans blog
 |
ing. Dennis-Jan Broerse Professional Services Consultant |
  |
| Dennis-Jan Broerse is a Professional Services Consultant in the Netherlands and one of our trainers. He has trained many developers at many companies in a wide range of topics. He is an advocate of agile development and helps companies improve their development lifecycles. |
Monday, September 7. 2009Migrating a dev team to an OO team (Part 1)
For many years Object Oriented Programming was rare in the PHP world. Many PHP programmers don’t know OO simply because PHP isn't natively an OO language. But with PHP5, PHP really entered the world of objects.
Still many PHP programmers feel that OO is too much for PHP. They don't see the benefits of object oriented programming. This is the start of a series of blog posts to investigate the topic. Being a trainer for Ibuildings, I noticed that the main topic of almost every course plan for customers is object oriented programming. So OO is popular and demand for it is rising. However, while PHP support for OO has been present for a couple of years still many companies that I visit are maintaining and developing procedural applications. Those companies often see the benefits of OO and they want to migrate their application to an OO structured application. But because of their legacy code base it is really hard for them to change and often they don't know how to change their development habits.
Whenever I'm teaching OO, I try to teach students not just the theory of OO but also how to put it to practice. During the training the developers often complain however that they can't practice their new knowledge because they are working with a big procedurally written application and have no idea where to start. At some point, I did an extensive OO training at a company but when I went back there after a couple of months to check back in on them, they said "The training was really good, we enjoyed it and we learned a lot about Object Oriented development, but as it happens we are still maintaining and developing procedural applications." What went wrong? The commercial time pressure! There was simply no time to sit back and 'sharpen the saw' by introducing OO to the existing projects. Under pressure, it's a common pitfall to fall back into old habits. In the next post I will provide some insight in how to overcome this problem, and how to migrate to Object Oriented development successfully. But before we go there, I'd like your input. Have you migrated your team to an OO team? If so, was it successful? How did you do it? Let me know in the comments below. Share         Trackbacks
How to migrate your dev team to an OO dev team (Part 2)
It's been nearly six months after my initial post on converting procedural teams to Object Oriented teams. After reading all the insightful comments on that post I've compiled a list with 10 steps to migrate your development team to an OO development team
Weblog: Ibuildings Blog
Tracked: Apr 09, 12:20 Comments
Display comments as
(Linear | Threaded)
One of the biggest challenges we faced was that 'using classes does not make it OO'. There's a whole theory behind OO development, and if that theory is not understood, and classes are just used as a way to group a set of functions together, then eventually problems will arise. Once we had a few developers on board that had been OO developers from the start, we noticed that eventually proper architecture became part of the codebase, and that was when we really started to see benefits. Before that, it didn't bring a lot of benefits and sometimes even caused more problems than it solved.
We have just started re factoring a legacy application written procedurally. We wish do it with unit tests. I will look forward for your next post in this series.
One thing about OO:
Saying from oneself "I can do OO" is presumably wrong  . Programming OO, or designing OO is a learning thing. The best programmers i know are humble and still open to learnings, especially when it comes to say such things as teach other peoples OO. So everybody teaches OO themselfes by doing it. There are so many philosophies out there as I can make typos in a 3000 Word document. And even saying there is ONE Theory behind OO is false aswell. It really depends on the language and the avail. language constructs what kind of (PHP-)OO you do (4, 5.3?). For example: The Javascript Objectmodell has different OO than PHP than Java than Python. As soon as you have made a trip to python your concepts of PHP-OO Change drastically. Anyway, if there is a well trained team of NON-OO programmers, you know, there is clean well-written, and even reusable non-oo code too. Coming to the point: It really depends what you do, but php is in some areas, just a wrapper around some unix libraries. And as much as i has evolved, some things a re better left as they are and executed immediately. Making it ALL OO won't cure anything, it wont deliver you that feature, and there is no Universal Rule that NON-OO Code will come out of the grave and eat your programmers at night.
We are a department of 20 programmers into 4 teams of 4-6. We have been using OOP PHP for 3 years now, developing closed source software for our company. We had the advantage to start building all that software with OOP in mind, so we had no problems with migration
 If you want to migrate a never-OOP team to OOP, start a new project. Do not waste resources on replacing programs that work just for the sake of OOP. OOP is just a tool, not panacea. Is it worth migrating to OOP? Yes!
The hardest obstacle which eventually comes up is that migrating goes hand in hand with refactoring large code bases. And refactoring is not really refactoring without unittests. And the unittesting frameworks we have are jUnit ports which by default biased a lot to help writing tests for OO code in the first place.
I think an extension to, say PHPUnit, which could make putting procedural code under test easier would come in real handy. OO can be much better understood by doing radical TDD. The TDD way of thinking sheds a lot of light to the core concepts of OO, like polymorphism, interfaces, responsibilities of a unit, dependencies, etc.
In fact i started out with writting tests for NON-OO Code. Using simpletest this was easy, but i think you can simply use phpunit the same way. Same collisions in the bad test smells as in OO code, just more and earlier.
Currently I'm maintaining procedural projects (although they use classes) and I don't see any benefits from refactoring to OO code, just because of hype or because it's cool. Especially when you only take care of code (bugfixing) it does not make much difference. Only real advantage is a practice that you'll get after this refactoring, but it's not direct benefit to the company.
One of the bigest caveats in above scenario is a change itself. There's bunch of code that needs to be encapsulated, abstracted and polished. Not an easy task for experienced OO developer, so don't be surprised that beginners are scared To make things harder there's little QA tools, like unittests, to make sure that changes will not blow up whole system.Don't make me wrong - I'm really OOP advocacy, thinking and coding in objects for over 10 years, but sometimes it's not worth the effort and good programmer should when do OO and when not.
We had aLOT of PHP3/4 code projects. Last year we decided to go PHP5 and OOP. A senior and a junior were set on the project to start migrating one of the projects to PHP5 and OOP.
We started off with migrating the most important part of the project first, the order process, after some research, experimenting and building we had migrated the order process part of the project to PHP5 OOP in about 1,5 month. Now, about a year later we've migrated almost all projects bit by bit. Whenever we need to make an improvement or bugfix, we take some extra time to migrate that specific old code to the new OOP code. All-in-all, the code is much smoother, bugfixes are done much easier and.. most importantly, there are much lesser bugs in the newly created code. With the old code we had times of having to fix 30 bugs per 2-weeks per project, with the new code we're down to zero to 3 maybe 4 bugs per 2-weeks in total! (total == over all new code projects, all == about 9 project and increasing). One major thing to watch out for, take good care of the non-OOP or starting-OOP programmers. Take them on the hand, review their code, educate them. They can destroy your good OOP design in seconds, let them know what they did wrong and show them the good/better way. I'll will follow this series with major interest, maybe I'll learn some more 
I am working in a small team and willing to migrate into OO team.
Thank you very much for this entry, I can't wait for the next one in this series.
I'm in the same position as Karn, thank you very much for the insightful info, looking forward to the next post in the series!
For me automatic tests for project is main case why I use OO. It is more simple to inject for object resources than make them global for "functions". So, I don't hear your classes, but I think that you are on right direction - practice, practice and practice. Every theory need to be show in practice.
PS: I hate theory without practice.... and try do not say what is right and what is wrong.
We moved our main app over to PHP OO bit by bit. That was the only way it could be done. We watned to move to a MVC architecture and we were using Smarty so the V was pretty much taken care of. We started implementing controllers for our main parts of the system. That helped a lot but not so much due to OO but more so because it was really messy before (too much being done in one place).
We've also implemented a fairly sophisticated model layer for the application and that has really made a big difference in terms of good architecture, easy maintenance and flexibility. We haven't been able to bring in unit testing, this is something we'd really like to do. There are still parts of the system which are completely out of the picture in terms of OO and we plan to move everything over one day but I think for most existing code bases you have to live with a bit by bit migration. |
