Team Style Guides and Mind Set
Been sharing this info with team members a bit lately and want to post it here for reference. Though there is no ONE way to do any of this there are ways that scale better than others. But more importantly having one way as a team to do things can be key to projects from beginning to end (eg the rest of the projects life!)
Project Style Guides
The Clean Coder by Robert Martin book is a look at being a "Professional" coder and all that comes with it. It is a great look at not only how one should be in the role of a Programmer but what to expect of each other as a team.
Domain Driven Deisgn A great look at being a programmer that not only makes code but more importantly bridges the gap between the vision of the business with the goals of the code.
PHP Style Guides
Back to Robert Martin again on this to start Clean Code
It is not about PHP directly but it all applies to good Oo PHP design patterns and thinking. There are so many classics he quotes that could be added here as well.
Angular Style Guides
I use to start with Angular Seed but always thought it fell short when the project grew and this guide made it clear to me why. IMO it is a much better approach to Angular John Papa. This guide includes examples which is great.
There are a number of great books on this as well. Right now a short and simple look at how to make an API, I think, is Build APIs You Won't Hate by Phil Sturgeon. Great code example too on Behat and API testing
A unified means to communicate ideas to each other and to product owners. Before digging into code this is a great way for teams to communicate all the way from higher level overview down to the classes and constructors.
Seems the Gang of Four book, Robert Martin books and Domain Driven Design all point to this as a way to sketch out ideas or even use it as a long term blueprint to go hand and hand with deployed code. The UML 2.0 in a Nutshell along with the more in depth O'Reilly book UML 2.0 second edition.
BDD / TDD
Testing is really key I think know one anymore doubts that. What you end up with is Code that you can refactor and make better over time with confidence. And as a team that is important. It also leads to one of the best sources of documentation. This presentation talks about BDD and article really take it to the next level. As the test become the glue between the goals of the business and the code of the developers.
Robert Martin really hones in for me why testing is so important. It is not about TDD in the end but maintainable and changeable code. And so even though much of the above seems like more work upfront it really leads to better code and better experiences as a coder and more importantly as a team.
Also Pair programming is a great use of time and should not be feared. Too much of it wears me out but just the right amount can be a powerful way to get a team member up to speed on a new part to a project or just to check in with each other and spend some time coding and growing as a team. It is scary to share in something as personal as coding but in the end we all can learn from each other.
Not as key as the ones above imo but still super helpful. Though POODR could easily be moved above.