Aiming at excellence πͺπ»
πΆ Eat Your Own Dog Food: test your code manually (incl. on mobile format)
β All Hail The Green: ensure the specs are passing on the CI server
π§πͺ Be a Citizen of the World: put all text in the I18n config
π· Tiny Is Beautiful: compress all images and put picture in .JPG format
π L'Orthographe m'a Tuer: no spelling mistakes will be tolerated
β© Consistency is the New Zen: ensure you respect your own naming and formatting conventions and that of the code
π You Are Not Alone: watchout for collateral effects in CSS, across products, across helper methods
βοΈ Sunshine Test: when we're a $1B start-up what you wrote will be read by thousands
π° DRY: it never hurts to repeat that you should never repeat yourself
β€οΈ Love Your Craft: be proud of what you code
Watchout for the demons of mental overload! πThey'll devour you if you have more than 3 cards in WIP π€―.
Never put instance variables within the view! π Help yourself with helper methods instead π‘.
π Any attempts of improvement made anywhere besides the bottleneck are just an illusion of improvement ππ.
We are what we repeatedly do. Excellence, then, is not an act but a habit π¨βπ. Continued self discipline in the execution of our craft, delivering an outstanding work, this is how we will one day reach perfection πͺ.
πDeploying to production is a non-event. We are a DevOps team working hard on continuous integration and deployment π£. If you are scared to break everything, youβve probably waited too long. The added business value is now at risk β οΈ.
Always start with the background context. Force yourself to level-up π, structure your thoughts before even trying to come up with words to explain them. Otherwise, only you can understand the π©you are trying to throw at us π¦.
Silent corrections kill learnings π¨βπ«. When reviewing a PR always ask the reviewee to perform all corrections by themselves, so they can learn by doing π¨βππ.
DRY antipatterns can be far reaching! β A good watchout: avoid duplicating content in the doc AND in the code. Thatβs why we say that good code is its own documentation π.
A model must never be responsible for the way it is displayed π. Instead, use a decorator π±ββοΈthat will shape the DB according to the context.
The view is dumb π§ βand must never contain any business logic π€. It shouldnβt handle anything else than display flags (show / donβt show) π©.
A presenter interacts with several models , while the decorator is used to add functionality to a single model (f.e.: CheeseBurgerDecorator πcan decorate the Burger model π).
Before diving in to coding π», make sure to fully understand the business goal of your work π¨βπΌ! Do not hesitate to ask questions until you know what the needs really are π―.
Last updated 3 years ago