Code Standards
All code is peer reviewed
Either by pair programming or code review, all code must be peer reviewed before it is released to production.
All code is tested
A proof of functionality is required for all production code - no exceptions! We must be confident in every release to production. Tests should focus on API and user interaction. Internal implementation should not be tested.
- All UI must be covered by an e2e test.
- Business logic, computation, and data transforms must be covered by unit tests.
- Use a code linter and static type checking.
The guiding principle for our testing is:
The more your tests resemble the way your software is used, the more confidence they can give you.All code is monitored
Monitoring and reporting is required and must directly notify the responsible team in the event of:
- an outage
- a runtime error
- a performance degredation affecting customers
Accessibility
Wander apps are accessible to all customers, including those depending on accessibility (a11y). Become comfortable with ARIA, using screen readers, scaling fonts, and other assistive technology and actively use them as part of your development.
Internationalization and Localization
Wander is for diverse cultures and languages. Language is not a barrier for future growth, we internationalize (i18n) and localize (l10n). All text, numbers, and presentation are to be built to support a user's native experience.
Encapsulation and co-location over globals
Code duplication is preferable to abstraction.
Chances are, if you've made a "Wander Button" component, you've created the wrong abstraction and coupled every single usage of it together. It's only a matter of time before that component requires an endless amount of parameters, expands to a mountain of code, and making even the simplest of changes will be very expensive. Consider instead using the UI framework's button and applying a style instead.
The best way to prevent coupling is to keep code co-located. Things that change together should be located as close as reasonable, unless otherwise specified by convention of a framework in use. Only bring code "up" and into a shared place when needed and the correct abstraction realized.
Use community and platform best practices
We build to the patterns and standards of the community and/or platform.
For mobile, this means native apps following the Human Interface Guidelines for Apple and Material Design for Android.
For coding languages, this means using the built-in libraries and common conventions of the community.
No cowboy code. What might be time savings or preference for you may in fact be maintenance cost and complexity passed on to the team or down to future engineers.
Buy instead of build
If it's not our bread and butter (trade secrets and business logic core to Wander), we prefer to buy it from a provider that specializes in and will maintain that service.
No assembly required, precompute on server
Avoid creating business logic on the client. Compute as much possible on server or use a query mechanism such as GraphQL or Data Loaders to request the data in the way it will be consumed on the client. If you find yourself writing a lot of conversion and data manipulation code on client, consider moving the work back to the server.
All clients function offline
Our users are wanderers, even into places without Internet connectivity. Going offline is to be supported on all of our client apps, including web. If a user goes offline, the UI will use its available cached data and respond appropriately if a feature cannot proceed without reconnecting to the Internet.
Documentation
README is the entry point for each project. It contains the purpose of the project, instructions for setting up a development environment, how to run tests, and how to ship work to production.
All APIs are to be documented as if to be shared as a public API external to the company.