Workflow Guide
Summary
Introduction
Hello there! I'm Vitor Britto, a Senior Software Engineer based in Brazil with over 15 years of experience in the software industry. I'm passionate about improving skills, learning new technologies, enjoy influencing others and always advocate for technical excellence while being open to change. I have strong experience building SaaS applications and developing software products.
🚀 Feel free to visit my personal website: https://vitorbritto.dev
About this Guide
- A personal Framework with approaches and methods that I use to delivery high-quality softwares.
- Tools that makes my Workflow easy.
- My own code conventions, which is inspired by what is popular within the community and flavored with some personal opinions.
- Major dependencies that I use.
The main reasons
-
Apply rules and be based on a principle and methodology of process which could maintain the structure of my standards.
-
Not only have a code style guide, but relevant informations about my Workflow. Thus I always keep the same logic process and can initiate the development of my projects without any questions when making a scaffolding, building process, automation rotines, unit testing and others tasks.
Workflow Lifecycle
You can find a complete list of applications, utilities, DevOps and Business Tools here:
This is a simple table with approaches and methods that I use at my Workflow lifecycle.
Plan | Design | Develop |
---|---|---|
Research | Concepting | Scaffolding |
Observe | Prototype | Coding |
Understand | Refine | Build |
Analyze | Style Guide | QA |
Timeline | Approval | Deploy |
Tools
Plan
- Obsidian - To take notes of everything
- Trello - Task Management for projects
- Linear - For Issues tracking, Roadmaps and more
- Google Meet - Business Conferences and Chats
- Slack - Team Messaging
Design
- Whimsical - For ideas, mindmaps and more
- Figma - Prototyping and Layouts Presentations
- Miro - Used for System Design Diagrams and Flows
Develop
Scaffolding
Check the Kickstarts organization where I organize and setup my stacks for every kind of project. It's a initial structure and configuration where I can start coding in a few minutes.
Editors
Build
Frameworks | Libraries | Tests | DevOps | Css | Others |
---|---|---|---|---|---|
React Native | React | Jest | AWS | Sass | Typescript |
NextJS | Mocha | Docker | PostCSS | Parcel | |
ExpressJS | Cypress | Serverless | Tailwind | Webpack | |
NestJS | Appium | Styled Components | Rest API | ||
GraphQL |
... and much more!
Guides
For web projects in which I work from planning to delivery, I use the guides below. If I am on a team that already has established guides, I'll follow the rules already adopted.already adopted. No bullshit, just follow the rules.
- [STRATEGY]: Kanban and/or Scrum method.
- [DEVELOPMENT]: Clean architecture, Clean Code and The Twelve-factor app
Be Consistent
The point of having style guidelines is to have a common vocabulary of coding so people can concentrate on what you're saying rather than on how you're saying it. We present global style rules here so people know the vocabulary, but local style is also important. If code you add to a file looks drastically different from the existing code around it, it throws readers out of their rhythm when they go to read it. Avoid this.
License
MIT License © Vitor Britto