Introduction

Rules:

Quick overview of rules to consider as a front-end developer at Snakeware.

  • Use BEM notation
  • Check your work in all supported browsers!
  • Quality above quantity.
  • Use English variable names etc.
  • Add new knowledge to the docs when you found something new or have an improvement.
  • Get your code checked by your colleague front-enders. Code review is important!
  • Read the following guide atleast once: Scrum
  • When you are unsure giving a time indication, discuss it with a colleague front-ender!

Information for new Snakeware developers:

Applications you will need:

Optional

Developing tools you will need:

================================================================

  • Simplicate - Online administration tool we use for keeping track of hours
  • Jira Atlassian - Online ticket system for our projects.

================================================================

  • Teamcity - The tool we are using to build our websites/pr's
  • Traefik - Pull request builds
  • Portainer - Websites/Pull request/(SSR logs) are hosted on these containers
  • Sentry - Online error logging tool (you will need a package for Nuxt)

================================================================

  • SWPlanner - Planner for the different Teams that we have
  • Snkwr - Internal tool with handy things for development
  • FEDocs - FE Documentation

Technical Values

KISS - Keep It Simple Stupid - Complexity is our enemy. We need to solve the complexity inherent in the problems we face using simple solutions, and avoid introducing complexity that isn't inherent. Solution complexity is rejected, rather than dealt with. We ask 5 whys about complexity. What can be relaxed or changed to make the complexity go away?

YAGNI - You Ain't Gonna Need It - This is the answer to much introduced complexity. We force complexity upon ourselves by being so good at asking "But what if...?" Instead, we build for the problems we have today, not for the problems we think we might have someday. None of us are fortune tellers. We're mostly wrong.

No Punting - No one owns an website, a section of code, or a problem. We don’t punt issues off to others just because we weren't involved in the inception. Everyone works on, and fixes everything. Not knowing how something works doesn't mean you don’t work on it or fix it, it means the opposite! We seek out every opportunity to work on things we don't know about (and we fill in any missing documentation as we learn). Everyone on the team is front-end. No specialists.

Technical Priorities

  1. Simple & DRY with a single responsibility
  • Simple - see KISS and YAGNI above.
  • DRY - Don't Repeat Yourself - there's no place for copy and paste. It inevitably bites you in the ass.
  • Single Responsibility - units of software do 1 thing well, and only 1 thing. This applies to lines of code, functions, and classes.
  1. Transparent & manageable - logs, analytics, error reporting, and separation of config from code are good.
  2. Re-usability of components and logic is critical. We don't want to reinvent the wheel. We keep striving in making components and logic better and reliable. Keep informing with colleagues about components and pieces of logic that may have been done before in other projects. Learn from eachother.

By following these 3 top technical priorities, we get two important emergent properties: robustness and scalability

Our full set of technical priorities, in order:
  1. Simple & DRY with a single responsibility
  2. Transparent & manageable
  3. Secure
  4. Consistent
  5. Documented
  6. Tested

Developers are held accountable to these technical priorities. Code reviews are structured around these technical priorities.

Living these priorities requires hard thinking about the technical problems we face. Code that works is not the goal. Code that works by embodying these priorities, and the appropriate trade-offs between them, is the goal.

Process Priorities

Our error logging tool (Sentry) does it best to trap and report errors. Error handling and alerting is a key consideration in code reviews.

Deployment is automated. It's not done until it ships with automated deployment. It ships as soon as possible. Risk is mitigated by shipping small changes incrementally. ( So no uber pull requests :-) )

Documentation

All developers write documentation. Documentation is part of code review: did the appropriate docs get created and updated for the addition/change?

Documentation is well-organized. Even when good docs exist, if the person that needs them doesn't know where they are or that they exist, they do no good.

Code is documented. Comments are good! It’s always critical to comment on why this code is doing what it's doing. It’s also important to comment on what the code is doing, when that's not completely obvious.

Coding Guidelines

We're much more interested in ensuring code follows the values and priorities described above than that it follows any particular coding standard. Code formatting is just the small tip of a very large iceberg; poorly formatted code can be programmatically tidied, but poorly done thinking can't be programmatically rethought. That being said, here are some code guidelines we look for:

  • Do your best to conform to the coding style that's already there in the repository... That means we like it.
  • Don't leave trailing spaces after lines etc. (Prettier plugin - will handle most of the hard work for you)
  • Write comments. Comments are good.
  • Write tests if you can for work on modules. Tests are good.
  • Don't submit über pull requests, keep your changes focused and atomic.
  • Submit pull requests to the main branch of repos.
✨ Well done! You now know all the front-end rules. If you have any questions don't hesitate asking your colleagues!
Table of Contents