Invitation to Brainstorm: Step-by-Step Guide to Developing Our Project #3
abenteuerzeit
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello Team,
As we embark on our journey to develop the TenantTalk project, a community-driven platform for tenants to rate, review, and share their experiences with landlords and rental properties, I wanted to take a moment to discuss our approach to development and provide a step-by-step guide, especially for our junior developers who are new to coding.
Our project is built using a full stack technology with React and Redux on the frontend, Node.js and Express on the backend, and MongoDB as our database. We're using a RESTful API to facilitate communication between the frontend and backend.
To ensure we're developing our project in the most efficient and effective way, I suggest we follow the Twelve-Factor App methodology. This methodology provides a set of best practices for building software-as-a-service apps. Here's a breakdown of the twelve factors and what they mean for us:
Codebase: We should have one codebase for our project, tracked in a version control system like Git. Each developer will have their own copy of the codebase on their local machine, and changes will be merged into the main codebase through pull requests.
Dependencies: Any libraries or frameworks that our project depends on should be explicitly declared in a file like
package.json
. This makes it easy for any new developer to set up their development environment by simply runningnpm install
.Config: Any configuration values, like database connection strings or API keys, should be stored in environment variables, not in the code itself. This keeps sensitive information secure and allows us to easily change configuration between different environments (like development, staging, and production).
Backing services: Any services that our app uses, like a database or a caching system, should be treated as attached resources. This means we should be able to swap out one database for another without any changes to the app's code.
Build, release, run: The stages of building the app (turning code into executable bundle), releasing the app (combining the build with the current config), and running the app (running the app in the execution environment) should be strictly separated. This ensures consistency and reproducibility across environments.
Processes: Our app should be executed as one or more stateless processes. This means that any data that needs to persist between requests should be stored in a stateful backing service, like a database.
Port binding: Our app should export services via port binding. This means that our web app should be able to listen on a given port for incoming requests.
Concurrency: We should be able to scale our app by running more processes. This means that if our app is getting more traffic, we can simply start more processes to handle the load.
Disposability: Our app should start up quickly and shut down gracefully. This means that our app should be able to recover from unexpected crashes or restarts without any manual intervention.
Dev/prod parity: Our development, staging, and production environments should be as similar as possible. This means that we should all be using the same versions of our dependencies, and the same backing services.
Logs: Logs should be treated as event streams. This means that instead of writing logs to a file, our app should output logs to the console, and we can use a separate service to collect and analyze the logs.
Admin processes: Any administrative tasks, like database migrations or one-off scripts, should be run as separate processes, similar to how our regular app processes are run.
In addition to these, I want to emphasize the importance of Test-Driven Development (TDD) in our project. Each function must have a unit test, and we should strive to maintain a high level of code coverage. For those who are new to TDD, it's a development technique where you write a test that fails before writing new functional code. The goal is to write tests that define the functionality you want to implement. Once the tests are in place, you write the code that makes those tests pass. If all tests pass, then your code meets all the defined requirements.
If you encounter any bugs or issues during development, please report them promptly using our issue tracking system. Here's a step-by-step guide on how to do it:
Identify the issue: Be clear about what the problem is. Describe the issue in detail, including what you expected to happen and what actually happened.
Reproduce the issue: Provide the steps to reproduce the issue. This will help others understand the problem and work on the solution.
Capture the evidence: If possible, take screenshots or record a short video of the issue. This can be very helpful in understanding what's going wrong.
Report the issue: Once you have all the information, report the issue in our tracking system. Include all the information you've gathered, and label the issue appropriately.
This process will not only help us resolve issues more quickly but also serve as a valuable resource for future reference.
I invite all of you to share your ideas, suggestions, and questions. Let's brainstorm together and make this project a success! Remember, no question is too small or too basic. We're all here to learn and grow together.
Best,
Adrian
Beta Was this translation helpful? Give feedback.
All reactions