Você se depara com comentários sobre sua estrutura de código. Como você pode lidar com uma revisão completa de forma eficaz?

Feedback should always be welcome, and we should be open to discussing it. If the feedback adds value and simplifies the code, then we should consider implementing it. However, we need to recognize that what is essential for us may not always be a business priority. To address this, we create a backlog and prioritize items based on minimal business impact. Incrementally, we incorporate the changes.

Feedback - Its all in the delivery. It's really easy to only look at the negatives when reviewing someone else's work. No one actually likes to hear negative feedback about their work. Start with something positive even if it's something simple. Don't be negative but suggest improvements or alternative ways of achieving the same solutions. And ALWAYS end on a positive.

Feedback is an opportunity for growth. Take the time to fully understand the concerns raised about your code structure. Approach it with an open mind, seeing it as a chance to improve your work. This mindset sets a positive tone for the overhaul process and ensures you're addressing the right issues from the start.

Lo más importante cuando escribes código, es entender lo que has hecho y que funcione. El siguiente paso es la estructuración. Lo has escrito en varios pequeños ficheros en lugar de uno grande. Los has escrito en un fichero grande en lugar de en varios más pequeños. Depende de como esté el proyecto y la reusabilidad de los métodos. Lo mejor, siempre es estructurar el proyecto, y en función de como esté, seguir las mismas pautas. Hay que tener en cuenta que puede que tu código necesite ser modificado, pero también es posible que sea mejor que el proyecto cambie de arquitectura. Es muy importante que haya consenso entre todos los participantes del proyecto.

Break down the feedback into actionable tasks and prioritize them. Identify which parts need refactoring and consider how these changes will affect other sections. For example, when Airbnb overhauled its front-end framework, the team carefully mapped out interactions between components before diving into the code. A well-thought-out plan serves as a roadmap, guiding you through the process and ensuring that critical feedback is addressed efficiently and effectively. Prioritize, plan, and execute.

Before making changes, outline a clear plan. Prioritise the most critical areas needing attention, and break the overhaul into manageable steps. A solid plan keeps you focused, reduces the risk of missing important details, and makes the process more organised and less stressful.

Plan thoroughly by outlining a clear strategy before making changes. Identify the key areas that need improvement and break down the overhaul into manageable tasks. Set specific goals, deadlines, and prioritize tasks based on their impact and dependencies. This detailed plan will guide your efforts, help manage complexity, and ensure a more organized and effective implementation of the changes.

Are we refactoring or restructuring? The two don't mean the same thing. Restructuring is going to almost certainly involve rewriting code interfaces and method signatures, which is a larger change than refactoring - wherein only the internal logic of an exposed method is changed but, to an external consumer, nothing is different.

En mi trabajo recibir una retroalimentación es bueno ya que permite corregir, depurar y optimizar hasta donde es posible una solución para el desarrollo actual y/o futuros.

Don’t try to change everything at once. Instead, tackle the overhaul in small, manageable chunks. Focus on one section at a time, which makes it easier to spot issues and test your changes. This approach reduces the risk of introducing new bugs and keeps the process from becoming overwhelming.

Ensure test coverage, make a change, ensure test passes. Rinse repeat until the code has been shaped appropriately. Unit tests are crucial to code restructuring and refactoring.

As a software developer, my first goal is to get the job done and once you are done with prototyping only then progress to refactoring. Over the past few years I have learned no matter how much experience you have you should only do ONE thing at a time, yes that's correct doing one change at a time will save us a lot of time if anything goes wrong during refactoring

Refactor gradually by making incremental changes rather than overhauling everything at once. This approach allows you to isolate and address issues step by step, making it easier to test and verify each change. Start with smaller, manageable components, and build up to larger structural changes. This method minimizes risk, helps maintain stability, and makes it easier to track progress and troubleshoot problems as they arise.

Tests should be integrated into a continuous integration environment, whereby changes to code are automatically compiled (if appropriate) and unit tests are executed to ensure there are no breaks to functionality.

Testing is crucial during an overhaul. Write and run tests as you refactor to ensure your changes don’t introduce new issues. Comprehensive testing helps maintain code quality and gives you confidence that your refactor is on the right track, making it easier to identify and fix problems early.

Test rigorously by conducting thorough testing at each stage of your refactor. Use a combination of automated and manual tests to ensure functionality remains intact and new issues are not introduced. Validate changes against requirements, perform regression testing to check for unintended side effects, and utilize edge cases to cover all scenarios. Rigorous testing ensures reliability and quality in your code overhaul.

Sin pruebas los programas que hacemos no son óptimos, ya que en la práctica es que se encuentran las eventualidades que el cliente final va a tener. Para mi es muy importante hacer ensayos exhaustivos para no tener que hacer reprocesos mas adelante.

Good documentation answers "why" code does what it does. To understand what it does, I can simply read the code (assuming it follows SOLID principles and is thus small and understandable)... but to understand *why* it does what it does, what the business problem is that is being solved or why something works one way and not another, then I need documentation. Code-level documentation can do this for components, and larger-scale structures can be documented in a wiki or equivalent.

Document changes by keeping detailed records of the modifications made during the refactor. Include explanations for why changes were implemented, what issues were addressed, and how they improve the code. Update any relevant documentation, such as design documents or code comments, to reflect the new structure. This practice aids in maintaining clarity, facilitates future maintenance, and helps communicate the rationale behind changes to team members.

As you make changes, document them thoroughly. Clear documentation helps you and others understand the new code structure, making future maintenance easier. It also serves as a reference for why certain decisions were made, which can be invaluable for ongoing development and team collaboration.

Facing feedback on code structure can be daunting, but an effective approach can make it manageable: 1️⃣ Understand the Feedback: Thoroughly review the feedback to grasp the core issues. 2️⃣ Seek Feedback: Discuss with peers or mentors to gain additional insights and suggestions. 3️⃣ Plan the Overhaul: Break down the changes into smaller, actionable tasks. 4️⃣ Iterative Improvement: Implement changes incrementally and test thoroughly. For example, after receiving feedback on a project's architecture, discussing it with a senior developer can reveal best practices and alternative approaches, leading to a more robust and maintainable codebase.