• Eager Eagle@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    2 months ago

    tldr

    1. Keep Commits Small: Ensure commits are small and manageable to facilitate easy reverts and debugging.
    2. Continuous Refactoring: Prioritize frequent, minor refactorings to simplify future changes.
    3. Deploy Continuously: Regularly deploy code to ensure it works in production, as working software is progress.
    4. Trust Frameworks: Avoid over-testing framework capabilities; focus on application-specific logic.
    5. Create Independent Modules: Place functions in new modules if they don’t fit existing ones, preserving code organization.
    6. Write Tests Early: Use tests to design APIs and guide development, but don’t be rigid about TDD.
    7. Avoid Duplication: Prevent repeated code by abstracting similar implementations after copying once.
    8. Embrace Change: Accept and adapt to evolving designs, understanding that change is intrinsic to software development.
    9. Manage Technical Debt: Focus on minimizing immediate blockers and plan for potential future issues.
    10. Prioritize Testability: Ensure that your code and design facilitate easy testing to maintain code quality and coverage.
    • xep@fedia.io
      link
      fedilink
      arrow-up
      0
      ·
      2 months ago

      Manage Technical Debt: Focus on minimizing immediate blockers and plan for potential future issues.

      This is a tough one the bigger the project gets. Might be the toughest one.

      • Technus@lemmy.zip
        link
        fedilink
        arrow-up
        0
        ·
        2 months ago

        It’s an ideal that’s only achievable when you’re able to set your own priorities.

        Managers and executives generally don’t give two shits about yak shaving.

        • nous@programming.dev
          link
          fedilink
          English
          arrow-up
          1
          ·
          2 months ago

          Just factor it into your estimates and make it a requirement to the work. Don’t talk to managers as though it is some optional bit of work that can be done in isolation. If you do frequent refactoring before you start a feature then it does not add a load of time as it saves a bunch of time when adding the feature. And helps keep your code base cleaner over the longer term leading to fewer times you need to do larger refactors.