Kim Arnett [she/her] leads the mobile team at Deque Systems, bringing expertise in iOS development and a strong focus on accessibility, user experience, and team dynamics.
Couple of things, based on the feedback from the Twitters.
Learning how to write effective, short, sweet, to the point commit messages.
Start your commit message with the story or task id you worked on. Things like that help too.
If you're tinkering, and not sure if you'll use the code tomorrow, it's totally fine to comment it out and save it. However, don't forget about it. Typically I'll put "tinker" code in a branch and clean it up before merging.
The end goal is to create clean, maintainable code that other developers can continue building on. If they have to sort through many dead functions, it's not going to give them a fresh perspective to fix the problem. Instead, they'll be inclined to resurrect your dead code. A huge issue I have with this - anything I built a year ago, I can build better and more efficient today. Why wouldn't you want that.
Tag your releases or major iterations. Sending it to the app store? Tag it. This has saved us so many times.
Lastly, we've had to resurrect old features that were once deleted due to scope change. So - we went to the last known release tag with that feature in it, checked it out and found the feature we needed.
Again: Create clean, maintainable code for other developers. Your version control is not only for you - even if you are the only developer currently. Someday others will take it over. *deep breath.
I'm looking forward to other input and tips too. :)
Tag your releases or major iterations. Sending it to the app store? Tag it. This has saved us so many times.
We have not been doing that but it's a great call. As a web-first shop it may not occur to us to see any release as major the same way I imagine it would be in iOS world.
Kim Arnett [she/her] leads the mobile team at Deque Systems, bringing expertise in iOS development and a strong focus on accessibility, user experience, and team dynamics.
I could definitely see how the lines get blurred. Releases on mobile are generally driven by feature changes.. so it's memorable like that too. Can't speak to the web equivalent. :(
In somewhat counter to the first point of "short, sweet, to the point commit messages", lately I've tried to stuff some keywords into my commit messages to make searching through GitHub easier. I'm really not sure how reliable this is.
Couple of things, based on the feedback from the Twitters.
Learning how to write effective, short, sweet, to the point commit messages.
Start your commit message with the story or task id you worked on. Things like that help too.
If you're tinkering, and not sure if you'll use the code tomorrow, it's totally fine to comment it out and save it. However, don't forget about it. Typically I'll put "tinker" code in a branch and clean it up before merging.
The end goal is to create clean, maintainable code that other developers can continue building on. If they have to sort through many dead functions, it's not going to give them a fresh perspective to fix the problem. Instead, they'll be inclined to resurrect your dead code. A huge issue I have with this - anything I built a year ago, I can build better and more efficient today. Why wouldn't you want that.
Tag your releases or major iterations. Sending it to the app store? Tag it. This has saved us so many times.
Lastly, we've had to resurrect old features that were once deleted due to scope change. So - we went to the last known release tag with that feature in it, checked it out and found the feature we needed.
Again: Create clean, maintainable code for other developers. Your version control is not only for you - even if you are the only developer currently. Someday others will take it over. *deep breath.
I'm looking forward to other input and tips too. :)
We have not been doing that but it's a great call. As a web-first shop it may not occur to us to see any release as major the same way I imagine it would be in iOS world.
I could definitely see how the lines get blurred. Releases on mobile are generally driven by feature changes.. so it's memorable like that too. Can't speak to the web equivalent. :(
In somewhat counter to the first point of "short, sweet, to the point commit messages", lately I've tried to stuff some keywords into my commit messages to make searching through GitHub easier. I'm really not sure how reliable this is.
Excellent! +1
I've also picked up some habits that I find very useful.
To delete dead code:
To delete a file:
Saved my bacon many time.
And for those who are unfamiliar with clean code, read the book Clean Code by Robert Martin. It's got good mojo.