Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Going on a limb here but breaking the project in smaller projects/API/modules/packages/assemblies (call them what ever you want) should be the next logical step here.</p> <ul> <li>Started small, few files, small editor, command line builds, all was good...</li> <li>Got bigger, versions got trickier, moved to SVN and IDE... BIIIG boost in productivity</li> <li>Then project got even bigger and the feeling of being overwhelmed creeps back again...</li> </ul> <p>The human brain can only process so many things at the same time, there is just so much our working memory can handle. Hiding smaller details behind a higher abstraction level will enable you to forget about these files until there is something wrong under the hood. If that ever happens you only need to open that particular hood to fix it there. Use different level of abstractions and your projects will become suddenly much smaller where only a handful of units will be meaningful while the rest is just to make them work. OOP is very good at hiding implementation details while exposing higher level functionalists. This being said there are other paradigms than OOP that you can choose from.</p> <p>So my advice to you at this point</p> <ul> <li>Break down your projects in smaller chunks each with an interface that will give you a single point of access to the rest.</li> <li>Use Unit testing and other testing techniques with a good testing framework to test each chunk individually. This will enable you to test the interface and see if it is useful.</li> <li>Never access the stuff behind the interface, if you feel the need, change the interface, the tests and then use the interface. This is the most important part, ignoring this will get you back in the problem you have now (too much coupling), therefore reduce as much as possible the points of interactions between the chunks, hence the interfaces.</li> </ul> <p>This will allow you to reduce dramatically the number of things you have to remember about your project and will scale well to the next order of magnitude.</p> <p>Then your next step will be at looking at OOP more in depth and learn about architecture and design patterns. They will help you reducing even more the domain of your system.</p> <p>usefull tidbits</p> <ul> <li><a href="http://www.simpletest.org/" rel="nofollow noreferrer">http://www.simpletest.org/</a></li> <li><a href="http://www.phpunit.de/" rel="nofollow noreferrer">http://www.phpunit.de/</a></li> <li><a href="http://laughingmeme.org/2003/08/05/a-few-tips-for-writing-useful-libraries-in-php/" rel="nofollow noreferrer">http://laughingmeme.org/2003/08/05/a-few-tips-for-writing-useful-libraries-in-php/</a></li> </ul>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload