Scaling truths, according to Automattic Wordpress VIP dev Matt Perry:
- Wordpress is built to scale
- Truth #1 doesn't matter if your theme or plugin is not built to scale
- Sometimes even fast code is not enough, but it's a good place to start
Start by optimizing your code, since you (developers) have the most control of that. These are the some things the Wordpress VIP team looks for in themes/plugins before rejecting or approving them for Wordpress VIP sites:
Too many queries or a few very expensive queries. Use debug-bar to identify number of queries and query time. Get rid of unnecessary queries or use the WP Object Cache to reduce query time.
External calls are expensive and disruptive. Be very careful with wp_remote_get because all execution is halted while waiting for external response. Cache external calls if required, or load via async
Every AJAX call to your site bootstraps all of Wordpress, so your site has to load Wordpress (n+1) times where n is the number of frontend AJAX calls. Frontend AJAX responses need to be heavily cached.
Be able to invalidate the cache whenever you need to. Take the dev time to make this painless.
The Wordpress VIP team only uses and recommends using the Wordpress-default tables. Performance between both approaches are very similar, but you risk losing performance optimizations if you roll your own tables. Direct SQL queries lose all caching/performance optimization - always use $wpdb when making calls for best performance
Bad OOP in Wordpress is just as bad (or worse) than bad functional programming in Wordpress. It can be even harder to read/maintain if not done properly. Why?
- OOP is hard to do well because Wordpress core is mainly procedural/functional
- It often adds mutable state, which increases complexity
- Constructors/factory methods can add noise to otherwise simple operations
Don't default to OOP if it doesn't make sense to do so. Understand the advantages and disadvantages of OOP versus functional/procedural programming before choosing one across all scenarios.
The intention of code reviews is to make code better.
- Humans evaluate other humans' code
- Bugs are caught in the least costly of development times
- Knowledge is shared among team
- Opportunity to learn, mentor and teach
- Builds a foundation of trust among team
- Code you didn't work on
- 200-400 lines of code
- Timebox review session to 1 hour
- Create an algorithm and/or checklist of things to review
- Either online or in-person, possibly a combination of both
- Avoid general feedback. Be specific with both positive and negative criticism.
- After a review, it's up to the person being reviewed to implement optional feedback. Errors and incorrect formatting or styling should always be fixed.
Use Javascript design patterns! (ebook here)
React is currently the best way to do SPAs, or single-page apps. Why?
- JSX is awesome
- Syntax is simple
- React fails at compile time rather than runtime
- Dev tools are amazing
- Speed (10x faster than Angular, 18x faster than knockout, 3x faster than DOM manip with jQuery)