Submitting your vote...
Being an extension author and maintainer myself, I often feel that TYPO3 lacks a significant portion of documentation: a guide about writing extensions properly. As a result we have a set of extensions, sometimes quite stupid (because they do the same that you can do with one line of TypoScript), oftenvery bright, complex and clever but all of them suffer from one or more problems that make these extensions hard to understand, use, extend futher. Even extension authors sometimes have problems modifying their own extensions because their extension architecture is not flexible enough to allow futher work on it.
In tjis set of articles I want to show certain techniques that will help developers to create their extensions in an easy, clean and extendable way. These techniques are simple for anyone but they require motivation for using and more typing at the very beginning. It may be hard to follow certain boring rules when you burst with ideas and want implement them ASAP. But you will be really delighted with yourself when you find that these techniques and principles helped you to develop "state of art" extension.
* * *
So, our first technique for extension: plan it. Let's suppose you want a new shining news system for TYPO3. Though there are tt_news and mininews, you are not satisfied. You may do better! What will you do? Go and make an extension in kickstarter? Nope. You sit with a piece of paper and think.
Firsts, outline what whould you like your extension to present to the user. For news extension it is obviously news. Will news be posted by BE users and/or FE users? Will news allow images attached? Will news contain images or other media types? Will news be only text or anything else too? Will news go to some kind of archive? Will there be categories for news? And so on. Do not just think. Write. Draw. Do it the way, which is natural for you. If you do not like paper, take cookies and play with cookies. Personally I have a good imagination and I can draw right in my mond and reproduce those pictures to myself even after several years. But you should use what is best for you. What you should achive at this step is a clear understanding what you extension will do. What, not how.
Next, think how it can look for editor and reader. Again - not how to implement it but how it should look. Forget that you are developer or your developer skills, thoughts and fear will not let you think freely. Think that you are a painter. How would you draw it? Can you imagine that? Does it cover all functionality?
When you are done with this step, you are ready to go futher. But remember one thing (which has the outmost importance in the software world but almost always underestimated): cost of change is lowest at planning phase and highest as you move through developent to maintanance. I am not only talking about money (if you write commercial extension) but also about hardness of rebuilding of an extension. Imagine that building architect forgot about plumbing in the building and need to add it after last layer of paint is already there. You don't want to be in the position of that architect, do you? So do not rush! Think!
It is so important that I will repeat.
Do not rush with implementation. Think what you want to achieve!
