this post was submitted on 10 Sep 2024
57 points (98.3% liked)

Programming

17022 readers
476 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 1 year ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
MaungaHikoi@lemmy.nz
57
Good software development habits (zarar.dev)
submitted 1 week ago by bugsmith@programming.dev to c/programming@programming.dev
14 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] eager_eagle@lemmy.world 28 points 1 week ago (3 children)

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 7 points 1 week ago (1 children)

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 6 points 1 week ago (2 children)

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 6 points 1 week 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.

[–] FourPacketsOfPeanuts@lemmy.world 1 points 1 week ago

In my experience when showcasing at the end of a sprint it pays to leave the visuals very unpolished and focus on functionality. Even if it's trivial to use a UI library or other standard components. I deliberately make it look basic to help management / uses accept "it's working but needs polishing". That polish might then be me spending 10% of time on neatening UI, and 90% of time refactoring / fixing tech debt.

[–] JackbyDev@programming.dev 2 points 1 week ago

Re: trust frameworks

I often find myself writing scratch work within tests because it's just the easiest way to get stuff up and running. Sometimes I'll leave these as a way to show that my assumptions about a less used feature (by my team) of a framework works the way I believe it does. But it's rare.

[–] MonkderVierte@lemmy.ml 1 points 1 week ago
  1. Embrace Change: Accept and adapt to evolving designs, understanding that change is intrinsic to software development.

Sounds like bad management to me.

And sure, start your project flexible and adabtable from the ground up, but that needs planning and time!