We can look back of doing more then 10 years of professional web development (in sense of earning money through it). In sense of history, we know where our preferred coding language (PHP) is coming from. We tried doing OOP with PHP4 and wrote a lot of so called "spaghetti code". We learned about patterns, clean code, standards and a shitload about all the tooling around PHP. We went from php.net comment usage, over using PEAR or any other package of code found somewhere out in the internet to composer usage in our days.
We wrote code without knowing about the existence of testing code tools and we were happy many times about the "it works!" moment. Now we feel happy about a well documentated and tested library of code and speaking of happiness and "it works!" moments - we now know how difficult it could be to get to that really magic moment of all things working like expected (is like getting an adult) and look back to that "it works!" moment of former times with a smile on our face (how n00bish, but sweet).
We like clean code and good software architecture! Our definition of good OOP design keeps changing every day with every new experience we make. Software quality is definitly a moving target and it is related to all the changes in the environment. New major language versions, new tools around it, the quality of your code base is related how it adapts to new stuff. You do not need to adapt every single and fancy tool. But it is worth to keep reading about OOP architecture and keep playing with new stuff. We learned to trust ourselves as less as possible.
Humans make failures, we try to get used to that fact and get prepared as good as possible to reduce the amount of possible failures. We communicate the worth of having a testsuite to our customers and engage to get together to the point, where all can sleep without nervous dreams again. In context of failure management: you can have huge bugs in your library although you have a code coverage of 100% - and it's never a question of who to blame, it always a question of how can we make sure, that this does not happen again.
API, REST, Apigility
We know everybody is talking about APIs in our days and that this is new "new big thing" inside the PHP world. So, yes, while everybody is talking about it, we already made a lot of experiences with API related things in the last years and keep looking forward to new API projects.
Apigility was just released as v1 - so there is a great tool now out there that enables us as developer to
more on the business logic part of the api.
We know how hard it can be to get into a good workflow as a coder team. We already did that for over 10 years and have a huge amount of experiences with code style discussions, meetings, tool decissions, bug tracking systems, version management tools and other programmers.
If you need to get started, finding your way through decisions until the point you can show off something
(and we already
know, you want that moment to be as near in the feature as possible) - we can offer a well attuned team that
from first moment on until a real finished product.
Feel free to contact us!