How do you test and improve your programming projects?

This is true, when doing the Grow With Google Scholarship we were tasked with picking our projects. To me this felt like an easy task since I knew what I wanted to create. My project now has over 10k downloads on the playstore and am super proud of it. Fews things I learned that I can add to this. 1. Don't reinvent the wheel(if you have no new ideas) - my project was a budgeting app but built to fit my need. 2. Pick a stack you understand, I was comfortable with Java so this made my project easier. 3. Finally, I went with a simple UI which made work easier for me. Overall choosing a suitable project does indeed go a long way.

Test with unit, integration, and end-to-end testing. Perform code reviews, static analysis, and security audits. Use CI/CD, monitoring, and UAT. Refactor code, learn from mistakes, and stay updated for continuous improvement.

If this is a project of your choosing for a portfolio project (and not just something cool for your personal use), choose something that would provide a business related impact. Something like a CRM application, or a project or bug tracking application. Something that would show you have an eye for business. A cool game app with all of the latest swirling widgets is catchy, but you want to show a basic business acumen during an interview.

Para poder probar un software primero hay que escribirlo y para poder escribir, es importante conocer que es lo que nuestro software debería hacer. Es necesario tener esas reuniones con nuestros usuarios y stakeholders para obtener mayor información y poder determinar como se debería construir la funcionalidad en código. El punto más importante que pongo en juego a la hora de codificar, es la reutilización (en realidad lo tiene todo), tu no reutilizarás algo que no es escalable, algo que está programado mal, etc. Entonces pienso siempre en reutilización y como puedo estructurar mi código para que pueda reutilizarlo las veces que quiera y así también las pruebas sean más sencillas.

Agreed. It helps to divide the project into smaller, manageable tasks or user stories. This breakdown helps you prioritize and estimate the effort required for each task. Use techniques like User Story Mapping or the Work Breakdown Structure (WBS) to organize and structure your development plan.

Ensure that you structure your code, architecture and logic in a manner that ensures easy and granular testing. Keep in mind that including easy and comprehensive testability as an objective in the design process itself can yield significant benefits down the line.

Use a framework. Any of the popular ones will work. Just pick one and organize your code in a commonly accepted structure. If it is MVC, use a models, controllers and views package structure. Don't leave code scattered all over in a personal structure that only you are familiar with.

When the deadlines are descending on you like the weight of the world, it is easy to fudge or stub out tests. Don't do it. You will pay for the time saved now by losing time during your weekends or vacations trying to figure out why your code broke because of one piece of data that you didn't think to test for.

Use GIT and refactor constantly. You can always roll back when you mess up. And you will, so don't be afraid of mistakes. Be bold and try out new ideas and concepts. You learn more from mistakes than successes.

As is often the case, programmers can get better by learning from good writers. They know that you should "kill your darlings" if you want an engaging story with brevity. Likewise, programmers who want maintainable (which is to say readable) code should not hold onto unused code. Don't commit commented code either! You may be proud you solved a difficult programming problem and want to preserve the solution (even tho circumstances dictated that it was no longer needed). Don't do this! You solved it once; you can again if needed. Holding onto unused code is how cargo cult programming starts, and before long you have a code base which takes a lot longer for new programmers to grasp (if they can grasp it at all).