So I've been working with a lot of startup type companies recently doing agency work
You have to sacrifice a lot of code quality and professionalism in fast paced environments, its almost always better to under-engineer than to over-engineer
Here's my opinions
- codereview - there's never any resources for QA. I just check teammates PR if it builds and passes a few manual tests, then merge. I don't spend more than 15 minutes on this. Coding standards highly depends if I've worked with teammate before. Sometimes I disagree with something but still OK it anyhow if its just me being nitpicky
- Test coverage - not in early stages. If you use typescript it eliminates a huge need for test coverage, but you'll still eventually want end-to-end testing. Just not until production is near deployment
- Normal development workflow - No tests, its a high opportunity cost, but again depends on what software your building. I'd say 90% of apps don't need testing early on
- CI/CD - yes, its good practice to still use protected branches and specify workflows for PR'ing and naming things
At the end of the day, you realize you have to cut corners and need to weigh out the value proposition each tool set offers. As well as how your team composition works.
Sometimes you have to defer tasks for later dates to revisit because its over-engineering and things aren't fleshed out enough yet
The most important thing early on is elminating tech debt too. Each decision you make is cascading. For instance code patterns you set today are going to be used several months from now, ideally you want to minimize the need for refactoring early on.
Write clean code with good variable names, and sane folder structures. Likewise with sass styling etc. KISS (keep it simple stupid), just follow those rules
You have to sacrifice a lot of code quality and professionalism in fast paced environments, its almost always better to under-engineer than to over-engineer
Here's my opinions
- codereview - there's never any resources for QA. I just check teammates PR if it builds and passes a few manual tests, then merge. I don't spend more than 15 minutes on this. Coding standards highly depends if I've worked with teammate before. Sometimes I disagree with something but still OK it anyhow if its just me being nitpicky
- Test coverage - not in early stages. If you use typescript it eliminates a huge need for test coverage, but you'll still eventually want end-to-end testing. Just not until production is near deployment
- Normal development workflow - No tests, its a high opportunity cost, but again depends on what software your building. I'd say 90% of apps don't need testing early on
- CI/CD - yes, its good practice to still use protected branches and specify workflows for PR'ing and naming things
At the end of the day, you realize you have to cut corners and need to weigh out the value proposition each tool set offers. As well as how your team composition works.
Sometimes you have to defer tasks for later dates to revisit because its over-engineering and things aren't fleshed out enough yet
The most important thing early on is elminating tech debt too. Each decision you make is cascading. For instance code patterns you set today are going to be used several months from now, ideally you want to minimize the need for refactoring early on.
Write clean code with good variable names, and sane folder structures. Likewise with sass styling etc. KISS (keep it simple stupid), just follow those rules