Blog

Checklist in Web projects

This is a simple list I want to check when starting a Web project. This is not specific to a language choice but all this rules will really help you during the process. There are questions you have to answer before starting the code.

Development environment

  • How do new collaborator join the team?
  • What do they need before starting to code?
  • What is the exact process for installing the environment?

Tests

In my mind, there are three kind of test that you can do:

  • Unit: The goal is to test internal business logic to keep the core system clean. The access to databases, the interaction between your classes, and the performance for each critical parts.

  • API: If you’re building an RESTful API for example, you need to test it at 100%. Each call has to be tested in different scenarios (different input data). This will drive you development for internal logic and external client.

  • Integration: The most difficult I think. Test the way a user interact with the application. You can use several tools for that like Selenium and Capybara. This tests mean real scenarios for the final user. Focus on it because it’s the app you expose to the world.

  • What kind of tests do you need?

  • What is the goal of your tests? Are you doing an API, a mobile app, a library?
  • What to test or not to test?

Fixtures and fake data

For the same reason tests are crucial, having fake data for testing is a complement to test the behaviors of your app in different use cases. Take the time to write scripts to fill your development and test database with this data and check if the UX is still ok with that. For example:

  • What append to the navbar if the username of the current user is very long?
  • Is this blog post title h1 ok if it contains more than 150 characters?

This kind of checks can be made by fixtures. Ask yourself:

  • Have we got a script to generate fake data in the database?
  • How can I fill the test database with fake data for testing purpose?
  • How many fake data I need to test?

Documentation

Some advices for documentation:

  • Comment the code, not too much: You can use a tool to generate a doc from your code. It’s sometime more pain than gain. I prefer having some comments in the tricky part of the code to explain the problem and the solution. But not everywhere. Clean code is your doc.

  • README: Create a README file (I use Markdown for that) for each part of the project. Explain how to install the tools needed for running the app.

  • Tests: Document how to run the entire test suite or a specific part. Tests are useless if their are not running several times every day. Make it clear to your team. They will find bug quickly thanks to the tests.

  • Build and Deploy: Same thing. Make all the team aware of the deployment process. Everybody should be able to patch the code and push it to production in some minutes.

Communication

Please consider communication as a feature. The quality of the communication in a project can change everything. You need to install and configure everything before starting.

Ask yourself:

  • Who’s doing what right now?
  • How do I express a need for a feature?
  • How do I report a bug?
  • Where are the important informations about the app? (Git repo, login for admins, Amazon credentials, other information that the team need to code, test and deploy)
  • If I make a change, who are the people I have to prevent?
  • Who’s responsible for feature decisions?

The quality of your communication is the most important skill you have to develop. Stay professional when you express a bug, explain all the context and the step to reproduce it. What makes a developer better than other? His/her ability to stay up to date during the development process. It’s all about the non-technical aspect.

Deployment

If you’re building a Web application, you should be able to quickly change a part of the website (CSS, Views, logic, etc) and your changes can be visible to the world across all devices in minutes. This is the beauty of the Web VS. native applications. To publish your changes, ask yourself:

  • How much step I need to deploy the latest code to the test server and the production server?
  • Are this steps well documented? Can other developers deploy in a simple way?
  • What are the things to check before and after the deploy?
  • Can I rollback quickly if an error appears on the last deploy?
  • Is it better to pay $50 / month for this or to spend two weeks for administration and annoying stuffs?

Monitor

When your app will be online, you have to monitor it to find bugs before your clients.

  • Can I check the errors on the production servers?
  • What is the state of the app? (long SQL queries, bottlenecks)
  • Can my collaborators (managers, team members) check the content of the database?
  • If a user report a bug, Can I isolate it in the logs?

Conclusion

All this parts are important and there are no priorities. Our experience show that you have to combine this skills to be productive and deliver quality applications.

One more thing

There is no “small” projects. Every project follows the same pattern. You start small ans growth. Prepare your team, your code, and your process to growth without pain.

Damian Le Nouaille