├── coding-practices.md ├── project-week.md └── README.md /coding-practices.md: -------------------------------------------------------------------------------- 1 | # Coding Practices 2 | 3 | ## Folder Structure 4 | 5 | Below are two examples of typical folder structures for a CRA and an Express app. If using different technologies then remember to separate concerns so that your code is easy to navigate and easy to test. 6 | 7 | ### Front-end - Create React App 8 | 9 | ``` 10 | public/ 11 | src/ 12 | components/ 13 | App/ 14 | App.module.css 15 | App.stories.js 16 | App.test.js 17 | index.js 18 | ... 19 | config/ 20 | ... 21 | index.js 22 | utils/ 23 | ... 24 | index.js 25 | index.css // global css rules 26 | index.js // root level (attaching with ReactDOM) 27 | serviceWorker.js 28 | .gitignore 29 | package.json 30 | README.md 31 | ``` 32 | 33 | Notes: 34 | 35 | - Folders are `camelCased` 36 | - Except for component folders, which are `PascalCased` so that we know components live in there 37 | - You may wish to have a `pages/` folder (similar to gatbsy) where using React router you can contain pages and render them when needed. In this case, you may want a `Routing` folder which contains all of the routing logic. 38 | 39 | ### Back-end - Express 40 | 41 | ``` 42 | bin/ 43 | www 44 | data/ 45 | models/ 46 | public/ 47 | routes/ 48 | app.js 49 | package.json 50 | ``` 51 | -------------------------------------------------------------------------------- /project-week.md: -------------------------------------------------------------------------------- 1 | # Specifics we want to see 2 | 3 | ## Think UX 4 | 5 | - Use your user personas to craft a user journey and experience that stands out and solves the problem you set out to solve 6 | - We want to see a custom front-end experience, and hear the reasons why you've chosen to design it like this 7 | - The look, feel, and brand of the product/app should all align and we'd like to hear the reasons you've decided this was the right approach 8 | - Make sure you highlight anything you want people to see in your presentations - we can only know what you show us, so if you've got a cool little animation or feature, be sure to show it clearly rather than expect people to notice 9 | 10 | ## Diagram depicting how your stack is set up 11 | 12 | - We want to see how your technology is set up 13 | - What technologies is your platform built on? 14 | - Where is it hosted? 15 | - How do different parts communicate? 16 | 17 | ## Day 1 Tip: No coding until you're all on the same page, setup to work together, and have a plan 18 | 19 | - The problem should be solved before you start coding. Use Day 1 to work out who you are solving the problem for, what the problem is, how best to align with your target user in terms of creating a brand/user journey and what the priorities are to deliver value to your users and then getting the whole team set up so that everyone is ready to code and on the same page with a well planned backlog of tasks to deliver. 20 | - Use the steps of Disney ideation to ensure you make space for all of the phases of the ideation process. 21 | - Plan out the structure of your app, including a component tree mapping out the states, behaviours, and information/functionality handed down via props before you start coding. Don't be afraid to come back to this plan if something changes further down the line in the project! 22 | 23 | ## Communication is key 24 | 25 | - Keeping in sync with each other is vital, and stand-ups are a great way to do this. There is no limit on when stand-ups should be, that's down to you as a team... many teams do a couple a day to check-in quickly with each other. Remember, it can be rapid - the point of a stand-up is a quick glance at what's going on, and if there are any blockers anyone is facing 26 | - Being clear about who is doing what is helpful when working across a team 27 | - Performing code reviews is a great way of getting more eyes on the code, and keeping people up to date with what's happening 28 | - As you build and progress through your tickets, keep checking the plan and keeping it up to date so everyone stays on the same page throughout. 29 | 30 | ## Team splits 31 | 32 | - Days 2, 3, and 4 should all be spent pair programming 33 | - We want to see a different pairing each day 34 | - For a team with an odd number of members, that might mean one person may be on their own each day or in a three, but this should be a different person each day and only by neccessity 35 | 36 | ## Technical details 37 | 38 | - You should be using environment variables where you think it is appropriate, and be [comfortable with why this is important to do in building applications](https://12factor.net/) 39 | - You should use the core technologies that we have covered on the course so far - think JavaScript, Node, SQL, and React 40 | 41 | ## Friday Presentations 42 | 43 | - 10 minute presentation slots, with some Q&A after. Try to stick to the timings! 44 | - Share the talking evenly around the team; everyone should contribute to the planning, building, and presenting 45 | - Practice beforehand and time yourselves 46 | 47 | ### The Presentation Format 48 | 49 | - Introduce yourselves (10 second intros!) 50 | - Briefly explain the problem you are solving 51 | - Live demo your app, 3-4 mins to explain your solution, how your app works and how it solves the problem 52 | - Briefly talk through how you approached the project (git and github strategy, planning, team roles, etc) 53 | - Finish, and questions 54 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Final Project Guidelines 2 | 3 | Before you start, remember that the entire community, from alumni to mentors, are rooting for you. The aim of these projects is to help you experience what its like to be part of a real-life engineering team building a real-world solution. Sometimes things may feel overwhelming or too stressful - your team are here to support you, and part of the reason you want to work in tech is because it should be challenging, supportive, and fun! Keep perspective, learn as much as you can, and remember that the fundamental thing people hire from School of Code are people with the right mindset and attitude to work in a high-performance tech team. 4 | 5 | ## Team 6 | 7 | - The most important part of any project is making sure the team members are all bought into it and all working together to make the team environment the best that it can be. You will be assessed on your teamwork from the beginning of the project onward as this is crucial in what our employers look for. 8 | - In great teams, each member puts the team above themselves. Egos are left at the door; we're all in it to help each other. 9 | - What are the strengths, preferences, weaknesses, and goals of each person, and how can you all work together to maximise each others' potential? 10 | - How will you keep it a happy, fun, and effective team environment? 11 | - Remember all your teamwork, communication, and self-awareness sessions! 12 | - The key thing here is to learn and have fun in an engineering team, and deliver a great product… That’s what you’ll be doing hopefully for the rest of your careers, so start off in the right way. 13 | - Spend time crafting your team manifesto, and keep referring to it throughout the project - use it as a living document, especially when the going gets tough. 14 | 15 | ## Manage 16 | 17 | - Managing yourselves as a team is vital to success. 18 | - Everything moves more slowly if you can’t ship code quickly and roll back/forward quickly when you break stuff. Spend time in the first sprint getting work workflow slick. Every commit goes to prod - build that momentum. Elite teams prioritise developer experience. Think about picking a tech stack that has very good docs, consider picking items in your tech stack that are designed to work well together. For instance - it is very common to use React with Redux. Because it’s common there are lots of docs, straightforward tutorials and brilliant developer tooling. Another example might be, it’s possible to create your own React application from scratch, containerise the application and and have it deploy a Azure Container Instance … but it’s a lot easier and quicker to use two or three commands to spin up a blank Next.js app and hook it up to deploy on Netlify. If you have limited time it better to lean towards common tech stacks and easy deployment. 19 | - Agree up front how you will manage the project including: 20 | - How you will keep in contact (regular stand-ups, retros, and getting together as a team however often you see fit to help each other stay on the same page and address any issues) 21 | - How you will resolve conflicts (if there's a deadlock of ideas, how will you move forward?) 22 | - How you will make sure everyone is heard (good tactics are using the [SOC Spinner](https://soc-spinner.netlify.app/) or throwing around the virtual ball so that everyone gets a turn to have uninterrupted speaking time) 23 | - How will you facilitate brainstorming online (such as using a Jam Board or other tool, take a few minutes at the start of a session to allow everyone to write down their ideas, and then go through each of them - this can help all thinking styles get the most out of the session) 24 | - How you will make decisions as a team (What happens when there isn't a unanimous decision?) Remember the tools covered during mindset sessions such as dot voting and Roman voting, and agree which you’ll use. It’s also worth looking into decision-making frameworks such as [consensus decision making](https://www.seedsforchange.org.uk/shortconsensus) and [consent decision making](https://medium.com/humans-of-xero/making-better-faster-decisions-that-are-good-enough-for-now-how-to-use-consent-based-decision-eef45ed8c976). 25 | - Who will facilitate each meeting - will it be random or a rota? Or one person for each type of meeting? 26 | - What are your responsibilities? (e.g. is someone keeping the team on track with time? Is someone the deciding vote?) 27 | - How will you handle taking regular breaks or knowing when you are going too deep into a problem and need to chat to get perspective? Will someone be in charge of keeping an eye on time for breaks? 28 | - Decide on a strategy for dividing up work and still keeping people in the loop and working as part of a team. **Your code is team-owned - no member should be going off and adding code without communicating/agreeing as a team.** 29 | - Remember, no plan survives contact with the enemy - you don't plan so that you rigidly stick to it even when it's not working. You plan so you are prepared and can iterate towards a solution. But the more thinking you do upfront, the more robust your plan is and the cheaper it is to iterate through possibilities and changes. 30 | 31 | ## The Direction 32 | 33 | - For your project, you and your team are coming together as problem-solvers who will identify and agree on a real-world problem or opportunity that you’ll focus your development on to solve as a business team. 34 | - Start with a problem - don’t start with an idea. If people are kicking in ideas of what to build stop and start again. Find a real problem. 35 | - In industry, people talk about four risks to manage when building a product, and they’re worth being aware of as you figure out what problem you’re going to solve with your product. 36 | - **Product market fit.** This means does this solve a problem big enough/annoying enough that someone will pay for it. It’s the most important thing to get right. 37 | - **Feasibility.** So we’ve found a hard problem/valuable problem, when we start doing ideating, could we actually build the solution? 38 | - **Usability.** So we’ve found a hard problem, technically we can build a solution. But is it useable. You want to build something people love using. 39 | - **Viability.** Does the solution work for the business. Or does the cost of building/providing mean it’s not worth it. Maybe there’s strong competition. Maybe it would cannibalise the market share of a product you already have? The key here is active decision making. Be aware of the competitive/business risk. You can make something others have already made, but be clear how you’ll be different. 40 | - Put users at the centre of your project. How can you use technology to solve a problem affecting your user? How can what you build make their life easier? Ideate, plan, and build a full-stack application that addresses this problem for your users. 41 | - Is your solution viable as a business idea? Is it sustainable and maintainable? 42 | - Brainstorm about the problem you want to solve as a team. Have some time to think through individually, and then list the ideas you’ve all come up with and discuss and agree together. Once you’ve chosen your idea as a team, you can move on to the next phases of understanding the problem, ideating, and planning. 43 | 44 | ## Understand the problem: Part 1 45 | 46 | - Take time to understand who the user is and what their problem is. 47 | - Don't take the problem at face value - delve into it. If Henry Ford only listened to what people were asking for, he would have just bred faster horses. Instead, he analysed the deeper problem of people wanting to get from A to B as quickly as possible. Understand the why! 48 | - What is the underlying value this software should provide? 49 | - What are the existing solutions? 50 | - What is bad/good about them? 51 | - How will success be measured? 52 | - What are the most important things to the user? 53 | - What are the most important things to the customer? 54 | 55 | ## Ideation: Part 1 56 | 57 | - Discuss your initial thoughts and find the holes in your understanding 58 | 59 | ## Understand the problem: Part 2 60 | 61 | - From the initial discussions in your team, ask any other questions you need to 62 | 63 | ## Ideation: Part 2 64 | 65 | - Use Disney ideation to bring to life lots of different solutions, and hone down your favourites 66 | 67 | ## Planning: Part 1 68 | 69 | - It’s important to show companies your skills in planning, including the whole system - if you left tomorrow, your plan needs to be at a level of detail that another team could still pick it up and build the software as you designed it. This is the true value you have for companies! So spend plenty of time in these planning stages, and be sure to document as you go so you can articulate about them and tell the story of your planning process to employers at the end. 70 | - Be strict on what is in the MVP and what isn’t. Draw a line on the board. Only allow a certain number of features above the line (MVP). Be very ruthless about what is below. Those bits can be stretch goals in later sprints. 71 | - Create [user personas](https://www.hubspot.com/make-my-persona) to get to know your users 72 | - Create [user stories](https://www.atlassian.com/agile/project-management/user-stories) to help map through what a user wants to do and why 73 | - Start planning the tech behind that solution 74 | - A large part of this time should be spent on research: 75 | - What is out there that can help? 76 | - Who can you speak to/get information from for user research? 77 | - Find some inspiration for designing and branding your platform 78 | - Plan what assets you may need for the client and what you are missing 79 | - Create low-fidelity [wireframes/sketches](https://www-freecodecamp-org.cdn.ampproject.org/c/s/www.freecodecamp.org/news/what-is-a-wireframe-ux-design-tutorial-website/amp/) of the user experience, and really think through what makes a good, smooth, and easy user experience 80 | - Good tools include [Draw.io](http://draw.io/), [Figma](https://www.figma.com/), and many more. 81 | - Check out sites like [Awwwards](https://www.awwwards.com/) for design inspiration. 82 | - Plan what data is needed in your application and what models are needed to represent that data 83 | - Try and use diagrams to share a vision between your team. These diagrams can and should be used for anything and everything - it’s easier to know you are all looking at the same picture when it’s in front of you, rather than getting wires crossed 84 | - [Here’s a guide for drawing Architectural Diagrams](https://www.lucidchart.com/pages/architecture-diagram), and you can use apps like [LucidChart](https://www.lucidchart.com/pages/) or [Draw.io](http://draw.io/) 85 | - [Here’s a guide for designing databases](https://www.lucidchart.com/pages/database-diagram/database-design), and again [LucidChart](https://www.lucidchart.com/pages/) or [Draw.io](http://draw.io/), but also other tools like [DBDiagram](https://dbdiagram.io/home) 86 | - As well as the diagramming tools, you could also try a diagram language, such as [Pintora](https://pintorajs.vercel.app/docs/intro/) or [Mermaid](https://mermaid-js.github.io/mermaid/#/) 87 | - Remember, Draw.io has a great [VSCode plugin](https://marketplace.visualstudio.com/items?itemName=hediet.vscode-drawio) and [installable app](https://www.diagrams.net/) 88 | - You will for sure be making assumptions about what your solution should be. The goal is to make a hypothesis, then build the smallest/fastest test you can, show it to users, learn, and pivot. An example of this might be that it’s often fastest to test something by having users play with a Figma, record their audio and screen. Watch it back and pivot what you build. 89 | - Think of the contracts needed between each part of your application: 90 | - What is the agreed upon interface to interact with a certain part, for example: 91 | - Plan the API needed in order to allow you and other developers to interact with that data 92 | - Specify what routes you will have and what the response will be 93 | - Establish that design as the contract, so that before the thing is built, consumers of the API know what routes to call and what they will get back, and developers of the API know what routes to create and what to return in a response; this will help front end and back end teams to develop concurrently while knowing that when they connect, there won’t be any surprises! 94 | - As you develop, you may find you need more functionality than you first predicted… This is fine, and you’d just have a quick conversation along these lines between the consumer and the developer of the API to again establish the contract. It’s useful to keep your schema in a shared doc where you can have edit/comment notification and can change/diff easily. 95 | - As an example, [Swagger](https://swagger.io/) is a great tool to use for teams in industry when planning and documenting APIs. We wouldn’t recommend using it for your projects, as time is tight and it’s very involved, but you can see an example of the documentation produced and manually use the same sort of approach. 96 | - Delve deeper into the front-end: 97 | - What is critical to build, and what isn’t? Critical can be for your learning experience but also critical to the product. Some portions of the UI aren’t as important to build as others, and it’s important to identify and prioritise this in your planning. 98 | - What should it look like? 99 | - What is the theme / feel / color scheme 100 | - [Coolors](https://coolors.co/) 101 | - [Color Palette Generator](https://colors.muz.li/) 102 | - [Color Mind](http://colormind.io/) 103 | - [Adobe Color](https://color.adobe.com/create/color-wheel) 104 | - What assets will you need? 105 | - What will the user be able to do? 106 | - What will you show the user? 107 | - How will you get the data into your front-end application? What data will your front end expect? 108 | 109 | ## Planning: Part 2 110 | 111 | - Break your plan up into epics, milestones and issues. 112 | - Keep track using Jira, Trello, GitHub Projects, or another kanban/project management system. 113 | - Estimate the complexity using [story point poker](https://www.atlassian.com/blog/platform/a-brief-overview-of-planning-poker#:~:text=Planning%20poker%2C%20also%20known%20as,and%20accurate%20than%20other%20methods.) (here’s an [online tool to help you do it remotely](https://storypoint.poker/)). 114 | - Prioritise - you can use any method, such as a [feature priority matrix](https://media.nngroup.com/media/editor/2018/05/21/screen-shot-2018-05-21-at-101407-am.png) or a [MoSCoW board](https://online.visual-paradigm.com/repository/images/16fef711-2669-4444-9320-5abe23b3acd8.png). 115 | - Find out which issues are blockers for others (which things need to be completed before something else can be started). 116 | - Plan your sprints: 117 | - Your sprints should be no longer than a week. 118 | - Sort what is in each sprint, what constitutes your MVP, what is in your stretch goals, and what is the future vision. 119 | - Delegate to sub-teams (these could be dynamic, and different sizes for different tasks) 120 | 121 | ## Track 122 | 123 | - Record anything that could be good when reviewing your project. Take pictures and record from the start and all the way through! 124 | - Remember that you will be telling the story of your project later, so record anything that would help (photos, videos, diagrams, etc.) 125 | - Enable yourselves to tell the whole story - ideas that didn't make it, problems that you encountered, how you resolved them or found solutions, etc. 126 | - Do you want to measure how effective your estimation was? Agree upfront, and then measure how long it takes compared to what you thought before starting the task 127 | - Each team member should keep note of individual achievements in a [brag document](https://jvns.ca/blog/brag-documents/). 128 | - Keep notes for feedback for your teammates as you move through each sprint as well. What did you love about working with people? What could have gone better? Keep a record - note these down in the moment because you’ll forget once it isn’t fresh in your mind. You should be sharing your feedback with your group members at the end of each sprint as part of your sprint retrospectives. Be sure your feedback contains actionable elements your teammates can take into the next sprint. 129 | 130 | ## Tech: Initialise 131 | 132 | - **Do not start this section until you have thoroughly planned!** 133 | - This phase is best done as a whole team sprint with a preference for mob programming so you are all on the same page 134 | - We will provide GitHub Classrooms links to allow you to get started; if you need more, just ask. 135 | - There are many options for how you organise your project. Here are just two examples: 136 | 137 | Monorepo 138 | 139 | - In a monorepo pattern, all your project files live under one git repo 140 | - Think about how you want to architect the files and folders in there to keep things neat - e.g. a front-end and back-end folder, or folders for each service 141 | - When you come to deploy, you will likely need to specify how to navigate from the top-level folder to the specific folder you're deploying 142 | - The benefit is all code in one place 143 | 144 | Multirepos 145 | 146 | - In a multirepos pattern, your distinct services will have their own git repos - e.g. front-end and back-end 147 | - Deployment can be done through each top-level repo easily 148 | - Disparate codebase will need communication to be clear 149 | 150 | In terms of initialising the rest of your environment, decide as a team on any core libraries or integrations you will need to achieve your goals, and make sure to align your configurations so that code standards are consistent across team members (using shared configuration files for services like Prettier, and/or pre-commit hooks like husky can be a good idea). 151 | 152 | ## Tech: Build 153 | 154 | - All team members should now pull down the repos into the same structure. 155 | - Start working on your features. 156 | - Remember the process: 157 | - Do not push to main! 158 | - Agree on a Git strategy up front with your team. For example, you could branch off main, creating a dev branch, then branch off from dev, naming your branch whatever the issue/feature you are working on is. 159 | - Make small commits as often as possible to ensure nothing can go too wrong! 160 | - Co-author your commits - it'll be important to share the credit in your git history and to show you've contributed even when pairing/mobbing; [click here to see how](https://help.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors). 161 | - You may find it useful to raise a pull request early on in the process, and then you can ask for a review as you go (the request can be open whilst the branch is actively worked on, and will just update automatically until approved and merged). We'd suggest when you think you are 30% done. Ask the team - "here's what I'm thinking - any suggestions early on?", and when you think you are 90% done: "I think I've cracked it. Any last pointers before it's ready to submit?" 162 | - A healthy development environment encourages positive comments, constructive comments, and pondering! It’s great to see engineers geeking out and praising people in PR comments. 🙂 163 | - When your issue is complete, raise a pull request (if you haven’t already) against your development branch. 164 | - Have someone else from the team pull it in - take time to review the code together and make sure someone else knows what's happening, and get some feedback if possible. 165 | - Once the merge is accepted, delete the branch. 166 | - You can then raise a pull request from dev into the master/main branch. 167 | - For APIs, Postman is still invaluable, and has a lot of support and guidance online for developing APIs. 168 | - Remember that Jest and Supertest are good libraries for testing APIs, but you can also look into how to achieve this with Postman or through any other method. 169 | 170 | ## Tech: Prototyping 171 | 172 | Have you ever done the teambuilding activity where you’re given dry spaghetti, string, and a marshmallow and are asked to build the tallest tower with the marshmallow on top? The most successful teams will test their structures with the marshmallow from the very beginning rather than building a rickety, swaying tower, popping the marshmallow on at the last minute, and seeing it crumple. 173 | 174 | The moral of this can be applied to your projects as well. Prototype your core functionality from the start. What’s most important? What does everything else depend on? What makes you the most nervous? These are your marshmallows - put them into your early sprints to get the most out of working an an agile way. 175 | 176 | ## Tech: Pragmatic Testing 177 | 178 | Practice pragmatic testing. 179 | 180 | Recognise that when you start building a product the requirements will change often since you’re discovering what works in real time. Sprint goals should pivot depending on demo feedback from stakeholders and user feedback from discovery. If what you’re building becomes a stable product, add more tests to aid future refactoring and to document the full requirements. 181 | 182 | An example of this might be - if you have ten core user stories then write ten high level Cypress tests. In the real world people tend to test everything from the start, or they test nothing, both not great. The first of these ways is too slow (speed is the life blood of start-ups), and the other is too risky. 183 | 184 | ## Tech: Coaching 185 | 186 | You will be working like an independent company of developers to execute your goal together. As coaches, we’re an extra layer of support if needed - we will act in a coach/mentor capacity. We’ll be asking you for updates on how the team is getting on, and we’ll equally be on hand if you’re stuck in a rut that as a team you cannot escape from. 187 | 188 | You can also request code reviews from your mentors, each other, or School of Code Coach for segments of work; these reviews can help keep you on the right track, prompt you to take in best practises, and keep us informed on your progress so we can spot problems early! 189 | 190 | ## Presentation: Plan 191 | 192 | - Plan your presentation, and bring the audience along the journey 193 | - All of your team should contribute to the presentation 194 | - Don't fill your slides with text! Tell the story yourselves, and use imagery and data to help paint the picture and emphasise points 195 | - A guideline structure for a project presentation could be: 196 | - Introduce the team 197 | - Problem: Introduce the problem how you saw it 198 | - Market: Who is this for, and is there a wider need for the solution? 199 | - Solution: LIVE Demo time. Show off your solution 200 | - Journey: How did you get to your solution - from ideation to delivery 201 | - Management: How did you manage your project 202 | - Analysis: Give a summary of how the project went, or what value it delivers 203 | - Vision: Where could this project go - and have you made any steps to help see not only the far-off vision, but where you could take it immediately given more time? 204 | - Q & A 205 | - Practice by running through the presentation a few times with your team if possible, especially the live demo and product walk-through 206 | 207 | ## Tools 208 | 209 | Agree as a team which tools you will be using for the job. Here are some possibilities, but it's by no means limited to this list! 210 | 211 | **Decision Making and Project Guidance** 212 | 213 | - [Untools](https://untools.co/) 214 | - [Atlassian](https://www.atlassian.com/agile) 215 | 216 | **Project Hosting** 217 | 218 | - Netlify 219 | - AWS 220 | - Heroku 221 | - Docker 222 | 223 | **Database Hosting** 224 | 225 | - AWS 226 | - Heroku 227 | - ElephantSQL 228 | - Google Cloud 229 | - Azure 230 | - Firebase 231 | - MongoDB Atlas 232 | 233 | **Designing/Ideation/Discovery** 234 | 235 | - Figma 236 | - FigJam 237 | - JamBoard 238 | - Balsamiq 239 | - Mural 240 | - Whiteboards (apps, in Zoom, or physical) 241 | - Draw.io (download the VS code extension!) 242 | - Google Sheets 243 | - Good old pen and paper 244 | 245 | **Project Management** 246 | 247 | - Jira 248 | - GitHub Projects/Issues 249 | - Trello 250 | - Notion 251 | 252 | **Boilerplate Applications** 253 | 254 | - Next.JS 255 | - Create React App 256 | - Gatsby 257 | 258 | **Linting** 259 | 260 | - Prettier 261 | - ES Lint 262 | 263 | **Documenting components** 264 | 265 | - Storybook 266 | 267 | **Testing** 268 | 269 | - Jest 270 | - Cypress 271 | - React Testing Library 272 | - Supertest 273 | - Postman 274 | - Selenium 275 | 276 | **Continuous Integration and DevOps** 277 | 278 | - GitHub actions 279 | - GitLab Runners 280 | - CircleCI 281 | - Travis 282 | 283 | **Infrastructure as Code** 284 | 285 | - Terraform 286 | 287 | **Logging / Observability / Bug Tracking** 288 | 289 | - Sentry 290 | - Log Rocket 291 | - Grafana 292 | 293 | **Communication** 294 | 295 | - Slack 296 | - Email 297 | - WhatsApp 298 | - Zoom 299 | - Discord 300 | 301 | **Libraries to help with your building features** 302 | 303 | - … literally all over the web 304 | - Search npm 305 | - Search for cool react libraries that do the job you’re looking for 306 | - Search everywhere 307 | - Component libraries; examples include (but aren’t limited to!) the libraries below. There will be dedicated React versions of most UI libraries. 308 | - Chakra 309 | - AntDesign 310 | - MaterialUI 311 | - SemanticUI 312 | - Remember to check out a library’s documentation (if it’s rubbish, it could be hard to bug-fix later) and usage (the more people it’s used by and rated by, the more likely it is to be good for your project) 313 | 314 | “Good artists copy. Great artists steal.” - Steve Jobs. 315 | 316 | Obviously, we’re being a bit tongue in cheek when we reference this quote, but use the collective genius out there! However, this is a topic where balance and critical thinking is needed. Often it’s better not to build everything, but you should be deliberate in what you choose to use from elsewhere vs. build yourself. 317 | 318 | Using a package or service is a great way to write less code, ship faster and focus on your core product. For instance, there are great UI libraries that give you well built core components (buttons, drop downs etc etc). You can save a lot of time by using them and just customising them to match your UI. This is time that you can then use to focus on other areas of your app. 319 | 320 | But as with all things, there is a balance. When you’re learning or trying to get a job, it’s often worth building something you don’t need to build for the challenge! Be deliberate and note down your decisions - it’s a great thing to show off to prospective employers. 321 | --------------------------------------------------------------------------------