Best practices for front-end teams: delivering fast and high quality modern apps at scale

By Nick Ribal, March 2019

• Over 10 years of web development, mostly front-end

• ​Variety of
  • Targets: web, mobile, responsive, APIs
  • Products: websites, apps, widgets
  • Companies: small to big start-ups, large and corporate giants
  • Company styles: product, project, consulting
  • Technologies: each client/company is different, in BE and FE
  • Work formats: employee, team leader, tech lead, consultant, architect, on-site and remote

1. ​Technological (easy)

   • Architect, choose technologies

   • Lay a solid foundation, which hopefully won't need to be thrown away and rewritten

2. Cultural (hard)

   • Improve individual and organizational development speed and quality

   • Explore the complex interactions between code, people, culture and organizations using tooling, rules and conventions

• Senior developers

• Team leaders

• Tech leads

• Architects

• Anyone who cares and thinks about how people, code and organizations interact

• Pull Requests (PR)

• Code reviews (CR)

• Maintainability

• Development speed

• Mindset and guiding principles

• Cultivating team & organizational culture

• Tools and methodology

• Soon to come: detailed blog post

• Avoid:

  • monolithic

  • opinionated

  • hard to replace parts

• Don't reinvent the wheel:

  • You can probably reuse 90% of others' work

  • Do your research

  • Only write glue code and your unique core product

  • Roll your own as last resort

• Prefer:

  • small

  • single purpose

  • modular

• Don't adopt everything new and shiny
• See whether something gains real world traction
• Give new tech time to mature
• Have it battle tested and polished at someone else's expense

• Most people do something just because everyone else does the same
• Don't do that. Use tech which solves YOUR problem

• business domain
• constraints

• What's bad today may mature tomorrow
• What's good today
  • may become unmaintained
  • will be replaced by something better
• Apply critical thinking and constantly revisit your decisions

• TypeScript
• eslint
• stylelint
• Spell checker

• Dependency graph analysis
• editorconfig
• And more...

• Use prettier: focus on business, not whitespace
• Linters: find possible bugs
• Have tests: they make refactoring easy and catch mistakes early

• npm scripts - "just work" with npm/yarn
  • Part of your dependencies, versioned
  • Single purpose, composable, cross-platform
  • Integrate with editors/IDEs using node's resolution
• husky 🐶 - "git hooks made easy"
  • Installed with your deps
  • Simple: run commands (npm scripts)
• lint-staged ⛔💩
  • Runs commands according to globs of git staged files

• Not "special"
• Does not require planning or tasks
• An integral part of daily routine

• Architecture is not special
• It is just code
• It is not set in stone or sacred
• It should serve you
• It should evolve along with what you're building

• Invest the time to analyze the problem
• Try to avoid preferring what you know just because it is easier
• Choose the best tool for the job, instead of the best tool you know

• technological freedom
• real involvement in product
• true sense of purpose

• independence
• challenges
• perks are last, least

• Encourage expressing concerns and opinions
• Ask for feedback, and listen
• Allow anyone to challenge any decision
• Nothing is set in stone, anything can be changed

• Smart people don't need micromanagement
• Supervise, observe, learn people's strengths
• Delegate to those who will do better than you!

• Development is creative, not an assembly line
• Feeling stuck in an office but worrying about home is a recipe for bad results
• Let people work when and where they'll do their best!

• Assume good intent - not ignorance, stupidity or laziness
• Be nice: how would you feel if someone wrote that to you?

• "How can we improve here?"
• "Why did you choose... ?"
• "I would do this..."
• "We have to..."

• Even very partial work should be subject to review
• Use labels to communicate PR status: WIP, Ready, In review, etc.

Async CRs set a record and clarity in every PR. Anyone is be able to understand, review and test any feature or change - without prior context.

• Open Source Software is remote, distributed, asynchronous and public
• Adopt and practice this workflow in your organization and your developers will know how to contribute to OSS
• Encourage them to contribute to OSS and they will love you!
• Appeals to candidates when hiring

• See something unclear? Clarify it!
• Took you too long to find that bug? Why? How can you make it easier for the next person?
• Go the extra mile. Demand it from your devs.

• When delivering quick and dirty, invest the time to pay back the debts and fix the faults
• Don't let the bad stuff accumulate
• Don't get to a place where you're only putting out fires

• Shuffle people and tasks
• Get everyone involved with all parts of the code
• Start with easy, simple tasks and expand
• Set a policy which not only allows, but encourages everyone to review anyone else's code
• Clarify why it matters and allocate time for CRs
• People learn a LOT from reading others' code

• Make sure devs know git. Git requires a non-shallow understanding to use it effectively. A lot of devs avoid learning it and use a GUI, which poorly abstracts git.
• When faced with a non trivial issue or any deviation from their standard workflow, they are clueless. Fight it by encouraging using git via CLI and understanding what they actually do when solving git issues.
• Teach people to make small, atomic, meaningful and descriptive commits

• A strict change per branch policy: even if two changes are in the same codepath, it is safer to have "feature/A" and "bugfix/B" branches. When an integration is necessary, a third branch is due: "feature/A-and-bugfix-B".
• If the two are closely related, git will allow you to express that relationship by: merging, rebasing, cherry-picking and using patches. Most people don't know this though :(.
• Back to previous point: devs should know git!