4 ms·

- How to refactor legacy code in a team setting. - How to prevent more bad code from being written in a team setting. - How to architect applications at a hig

by _virtu 10y ago

- How to refactor legacy code in a team setting. - How to prevent more bad code from being written in a team setting. - How to architect applications at a higher level. - How to mountain bike like a beast.

nevon 10y ago
The top two are on my list as well. The tricky part is that my "good code" is someone else's "bad code" and vice versa. Slowly trying to introduce functional concepts into a team of developers who are used to working with what can only very loosely be described as MVC.
- brown-dragon 10y ago
  > The tricky part is that my "good code" is someone else's "bad code" I feel your pain...
- _virtu 10y ago
  While you're at it a style guide may be in order. Try to convert your team's current patterns into the set of new patterns that you think are better. This would help to give others a sort of rosetta stone while they're making the switch. I always try to add a why after each good vs bad code comparison. Having a document external of your brain helps others to feel like they have a tangible set of goals instead of some arbitrary set of goals that nevon wants to have happen. I made my team's style guides repos on github so it's super easy to edit since it's straight markdown. Keep the pedantic discussions to a minimum. Sometimes it's just best to choose something because it's a single way of doing it.
brown-dragon 10y ago
I have been thinking about problem (1) off and on for the last year. The best strategy I've come up with so far is to set up a ritual that I will end the day with 10-30 minutes of code cleanup. Being systematic about it helps me get acquainted with a lot of the code while clearing technical debt.
- _virtu 10y ago
  This is exactly what I've been doing. I'm trying to make it an every day ritual, time permitting of course. My main approach for this is to create a long term goal for a relatively small unit of untracked work. For example I've identified that our common folder for our front end code is not broken up into logical units. So every day I try to hop in there and simply reorg the folder structure. While I reorg I'm exposed to the files, what they do and whether or not they are actually being used as well as how they're being used. This is enough to learn about what other people are doing/have done and helps me to identify other refactor goals as well as architectural goals. Another idea that I've found if you're on a longer release cycle is a post release mental hook. Once the team has deployed the latest bits, I try to hop into main and rip out or refactor code that may be more sensitive. This gives your more risky changes a much longer time to get eyes on them before the next deploy.
  - brown-dragon 10y ago
    I love the "post-release" mental hook strategy. I'll try it out :-)

by _virtu 10y ago

nevon 10y ago

The top two are on my list as well. The tricky part is that my "good code" is someone else's "bad code" and vice versa. Slowly trying to introduce functional concepts into a team of developers who are used to working with what can only very loosely be described as MVC.

brown-dragon 10y ago
> The tricky part is that my "good code" is someone else's "bad code" I feel your pain...
_virtu 10y ago
While you're at it a style guide may be in order. Try to convert your team's current patterns into the set of new patterns that you think are better. This would help to give others a sort of rosetta stone while they're making the switch. I always try to add a why after each good vs bad code comparison. Having a document external of your brain helps others to feel like they have a tangible set of goals instead of some arbitrary set of goals that nevon wants to have happen. I made my team's style guides repos on github so it's super easy to edit since it's straight markdown. Keep the pedantic discussions to a minimum. Sometimes it's just best to choose something because it's a single way of doing it.

brown-dragon 10y ago

I have been thinking about problem (1) off and on for the last year. The best strategy I've come up with so far is to set up a ritual that I will end the day with 10-30 minutes of code cleanup. Being systematic about it helps me get acquainted with a lot of the code while clearing technical debt.

_virtu 10y ago
This is exactly what I've been doing. I'm trying to make it an every day ritual, time permitting of course. My main approach for this is to create a long term goal for a relatively small unit of untracked work. For example I've identified that our common folder for our front end code is not broken up into logical units. So every day I try to hop in there and simply reorg the folder structure. While I reorg I'm exposed to the files, what they do and whether or not they are actually being used as well as how they're being used. This is enough to learn about what other people are doing/have done and helps me to identify other refactor goals as well as architectural goals. Another idea that I've found if you're on a longer release cycle is a post release mental hook. Once the team has deployed the latest bits, I try to hop into main and rip out or refactor code that may be more sensitive. This gives your more risky changes a much longer time to get eyes on them before the next deploy.
- brown-dragon 10y ago
  I love the "post-release" mental hook strategy. I'll try it out :-)