-
Notifications
You must be signed in to change notification settings - Fork 0
⚙️ Tools for development
Micael Levi L. Cavalcante edited this page Sep 20, 2021
·
21 revisions
- Refined GitHub: Firefox | Chrome
- Octotree
- React Dev Tools: Firefox | Chrome
- Redux Dev Tools: Firefox | Chrome
- OctoLinker
- JSON viewer: Firefox | Chrome
- npmhub
- Editor de código: Visual Studio Code
- Gerenciador de dependências para o NodeJS: Yarn (v1.21)
- para criar diagramas Mermaid: https://mermaid-js.github.io/mermaid
- para criar diagramas variados: https://app.diagrams.net
- para criar diagramas UML: http://www.plantuml.com
- para desenhos variados: https://excalidraw.com
- para diagrams variados: https://whimsical.com
- cliente REST para desktop: Insomnia (com o plugin insomnia-plugin-faker); pode ser usado para gerar a documentação da API
- versão web inspirada no Postman: Hoppscotch
- administrar SGBDs: DBeaver
- modelar diagramas de Engenharia de Software: https://mermaid-js.github.io https://plantuml.com
- visualizar o grafo de dependências de um package do NPM: http://npm.broofa.com
- para buscar bibliotecas no NPM registry: https://npms.io https://libraries.io/
Responder não para:
- possui alguma vulnerabilidade? (conhecida): usar o https://snyk.io/advisor para verificar isto.
- está sendo mantido?: ver o score dele no npms.io; ir no repositório consultar a data do último release, histórico de commits, número de issues e pull requests abertos; além da presença de algum disclaimer do autor/comunidade nesse sentido
- possui bugs que afetarão os seus casos de uso? eg: conflitos com outros packages; edge-case issue; problemas específicos de desempenho.
- tem um tamanho aceitável?
- como se compara em relação aos demais que resolvem o mesmo problema? verificar no NPM compare ou no https://jsdiff.dev
https://somehowmanage.com/2021/09/05/things-to-do-before-and-after-you-write-code
- Entender o que você está construindo. Do you have specs or requirements? Are they clear? Do you understand what users you’re building for and how they’d use what you’re about to build?
- Entender como isso poderá mudar no futuro, so you can design for adaptability. Are there any assumptions you’re going to make now that might hinder your ability to adapt your code in the future or expand your functionality.
- Entender por que está construindo isso. If you’re building it, there should be value to your users and the business. What is that value? Do you agree with it?
- Entender por que fazer isso agora. Presumably, there are other things you could spend your time on. Why is this important right now? Is it creating more value than other options? Does it unlock other dependencies that require that this be completed?
- Ter uma plano para como construirá isso. Depending on the complexity and the stakeholders, this plan could be a couple sentences you run by a team-mate, like "I’m going to have to modify our data model, which will involve a migration, and change one API call." For more complicated changes with many stakeholders, this might involve a Request For Comment document, or a fully-fledged Design Document to discuss with your team and other stakeholders. There must be some thought. If you can’t put it in words, you’re not ready to put it in code.
- Pense nos efeitos colaterais. Will you stress certain parts of your infrastructure? Have to refactor a part of the code base?
- Desenvolva um mapa mental das partes interessadas. Who might you need to check with or communicate with as you build? Your product manager? Designer? Executives/leadership? Someone else on your team who’s irrationally excited about this feature and has been championing it for months? Anyone who would be surprised by any your work, positively or negatively, is a stakeholder.