Que faites-vous si vous avez besoin de gagner du temps en tant que développeur d’applications ?

Choosing the right tool is important but more important than that is mastering the tool. For example, if you choose to use an IDE, master the IDE by learning keyboard shortcuts to refactor, format, debug (step into, over, out), navigate etc. While these seem very basic, when you are in the zone doing development, these shortcuts make you much more productive. Also, CLI is your friend as a developer, master the same be it to compile or execute code, push code into a repository or view logs. Likewise for build tools, CI/CD tools etc. Choice of these tools can be a polarizing subject, there is no right answer IMHO. Pick the tool that you feel comfortable with but master it, own it and you will see the difference in your productivity.

Believe it or not a great tool is a white board. It helps you break down the task mentally, create charts if needed, and to just organize your thoughts and make sure that you fully understand what you are about to embark on. You also want to make sure you stick to platform standards as much as possible. If you are about to reinvent the wheel, stop and look for ways it may have been done in the past so you can avoid having to resolve problems people already solved.

For me, the IDE is my favorite tool. The right one will provide automatic linting, suggestive code completion, debugging, and more. Another great time-saving tool helps organize to-do checklists for my day and project. Such products can include Jira, monday, Trello, and the like. Finally, a good flowchart comes in handy with flow so I'd recommend a good flowchart tool.

There is no need to reinvent the wheel and waste time when someone has already done the hardwork! We used many JIRA and Confluence plugins in our development environment which directly or indirectly helped speed up the Application Development process.

Don’t reinvent the wheel, see if you can leverage an open-source package to help you achieve a quicker throughput by not starting from scratch. Tools like GitHub Co-pilot is another example of a time saving tool, just by the fact it’s contextual, keeps you in your IDE and can infer its answers based on your code base, so the result are more relevant. But it is not a silver bullet and it’s up to the individual how they choose to use the results given by it.

As a team agree upon a set of coding standards, guidelines and conventions that will be followed by everyone in the team. It could be as simple as re-using the existing convention for Java as provided by Oracle or taking a copy of it and modifying it to make it your own (per team preferences) Quality of a good code base is that even though multiple people have contributed to it, it should read as if it were written by a single developer (hence styles, conventions, guidelines) Code is written once but read multiple times during its lifetime. Coding standards not only help be more productive when you are writing code but months later when you are reading it also, it makes you productive since it is familiar to you

Most IDEs have linter abilities that can compare your code to the company's code standard policy. This helps get proper code format. Clean code, on the other hand, is something each developer has to always pay attention to. Well-written code is self-documenting and should not need comments to explain what the code is doing. Comments should be reserved to explain things like the business rules the code is being applied to, or the reason for the code. Functions should be well-named and do exactly (only) what they say they will do in the name. Having clean self-documenting code helps you make changes as the business rules change, and will help someone else understand and make changes later. Code reviewers must demand clean code.

Following 'Coding Standards' in today's AI enabled and sophisticated is not at all difficult. Only thing is which standards - tooling - linting process is suitable for your project, needs to be identified. Once the process is set, every team members need to adhere to that. Often it is observed that developers tend to bend the rules and bypass these coding standard checks or simply break the rules avoiding the additional work or taking systematic approach. I have seen the developers taking short cuts in the initial stages of development, often spend more hours in debugging their code for finding what went wrong later on. I would not entirely blame developers only, sometimes the managers push the developers for super-quick deliveries too.

Follow Agile, Architecture design patterns and do not never leave tests behind! They may seem like a waste of time when trying to save development time, but ultimately they are not if errors appear everywhere late in development.

I agree! Proper formatting allows for quicker review. Commenting with the purpose or intention and citing your source (reference number from chosen methodology) where relevant and appropriate provides the origin and history regarding code or process evolution in one place.

One thing I look for in functions is the ability to reuse them by passing different arguments to handle different scenarios that all fall under the umbrella of that function. If the argument list gets confusing or long, I prefer to pass a data object like a map or dictionary. The name=value pairs are easy to read or modify and can provide power to the function to work in numerous situations. Another important thing is to locate reusable code in a "common" or "utility" base file that is global to the rest of the project code. Then each project or code branch can borrow or extend those objects to meet their own needs and not reinvent the wheel.

Crea un banco de funciones; esto es de utilidad para cuando tengas que recurrir a operaciones similares en diferentes codigos, aunque ocurre algo curioso con la IA: es muy buena haciendo esto por ti. De este mismo modo, crear funciones concisas te ayudara a poder reutilizar estas en futuros proyectos.

Code reuse is kinda where and how question. I have seen people refactoring the code to so much granular level that sometimes it becomes painful to assemble the entire work-flow. Too much refactoring or simply breaking the code in much smaller chunks eventually causes more harm than help. Instead component based or library based implementations help save a lot of time. Keeping some code snippets ready in some org level wiki documentation of confluence page can save tons of efforts. Following SRP and precise/balanced use of libraries makes our code elegant and maintainable. Too much emphasis on 3rd party libraries or tools can be damaging in long run as well. so balancing this is a key.

Follow a test first approach, if you can visualise the method, function you want to write, you can produce a test for it beforehand, even if it's the most basic case possible. Running a test to check the correctness of your code will save tenfold the time compared to spinning up/debugging the application you are working on. The test developer feedback loop is usually measured in milliseconds and not seconds or minutes, which over a month is a lot of time saved.

I agree with Steven Walker about the test-first approach when developing the methods. Before source code is entered into the code repository and made public, a thorough code review should be done by at least one capable person. This could help ensure clean code, correct syntax, etc. When a build is complete on one of the environments (dev, integration, staging, production), various QA tests should be run that verify happy path smoke tests and negative testing. Regression tests should be run to verify a deeper set of functional testing.

Si hiciste una función, pruebala. ¿La integraste en otro modulo? Ahora prueba su integración en ese módulo. Probar justo al implementar es la mejor practica que podrás adecuar a tu ciclo de desarrollo; No dejes todo el trabajo de prueba a los testers.

When starting a new role its vital to have a tour and guide to a very large code base. You don't stand a chance regardless of tools, refactoring, agile methods unless you are able to communicate and collaborate effectively. I have been fortunate to have the benefit of learning by sitting next to folk and understanding how best to add value.

Follow the Agile Iteration methodology until something better comes along... Don't take scrums for granted. Be prepared to tell what you did yesterday, what you plan to do today, and what is blocking. The scrum master should not allow more than one-minute discussions before moving the discussion to the "parking lot" after the scrum. Having cameras turned on during online chats is fun and helps one another get acquainted faster. Have meetings after every two or three iterations to determine what worked well, what needs improvement, or what did not work. Also, keep a team temperature to see if people are doing well or getting burned out. We did team-building via e-cards for birthdays or special occasions. It reminded us we all care.

Copilot and Stack Overflow are good, but nevertheless the help of one specialist of your college at work are highly recommended.

The easiest way to waste time as a developer is to be doing the wrong work. Making sure requirements are understood clearly, and when they're not, making adjusts is critical. This requires, tight, open, concise communication across all team members, including developers, testers, scrum masters and product owners.

Don't take shortcuts. They will slow you down. Work through requirements to make sure you fully understand them. Think a bit about the design. Then do it right. Skip any of these steps and you will waste time redoing things or implementing things in a more complicated way.

These are all good techniques to follow. However, backing up to the original question; how can you save time - go faster when building software? The answer is to write quality code using the techniques highlighted. It never pays to rush. As uncle Bob says - "The only way to go fast, is to go well."

If you are following an agile or scrum methodology, make sure to invest in a sprint zero to get the plumbing set up for CI/CD pipelines plus any other one-time infrastructure set-up. Try to do any R&D/Spike work to help eliminate any knowledge gaps before committing to active development of the project. In my experience leaving these things until later in a project’s lifecycle can often be costly. Plus doing these earlier on gives you the benefit of doing a basic smoke test so you know everything is wired up.

Something I see missing here is Task automation... Task automation is a game-changer in developers workflows both in the job and off It significantly enhancing efficiency and focus. By automating repetitive tasks like code compilation, testing, and deployment, developers can concentrate on more complex issues and innovation. This shift not only boosts productivity by performing tasks swiftly and consistently but also increases accuracy by minimizing human errors. Furthermore, it allows developers to dedicate more energy towards creative problem-solving, enhancing both the quality of work and job satisfaction. Embracing automation streamlines collaboration and maximizes the potential of any development team.

Give developers sufficient time, to think and execute their development progress. Often the commitments are made by higher-ups with tight timelines or poor estimates and developers have no choice but to rush the development (QA are no exceptions here too). Eventually the bad code - bad testing leads to bad deliveries. Agile is a great tool, to incorporate the on-the-fly requirements, however management monkeys use it to pressure the deliveries - keep the cost down. Initially it may work, the development/ testing all gets done, however later the bubble burst when software have some lingering/buried issues which surface later on and taking even more efforts/cost in longer run. Bad code is like a cancer, prevent it with right (code) diet.