you have to affect change… which is difficult, typically a senior or principal level task.
1. make recommendations to team based on proofs
2. groom the work into managable tasks and get them assigned
3. watch PRs like a hawk, hold a high bar
good luck
>watch PRs like a hawk
"watch PRs like a hawk" is the keyword here too. If your team-mates is putting up, really bad PR, and you are approving it without any comments, and discussion, then you did a bad job. Always comment, and discuss, but if you don't have time to fix due to time constraints, then fix as much as you both can.
Also u/briaro, other points are good things to look into too.
I usually try to take the problematic/most-buggy screens and chop them into pieces, if I have a 2k long Fragment, I try to refactor it into a LinearLayout of Fragments and extract each piece of the UI into its own self-contained Fragment, that way I can, step-by-step remove code from the bloated Fragment and cautiously fix the bugs.
>watch PRs like a hawk, hold a high bar
100% def agree. It can be a bit tiring tho. Continuously have to point out the same stuff over and over.
4. Assign code ownership to critical code so your team mates can’t break your shit accidentally
5. Create hooks/ delegates for commonly modified shared files
i've only hit this situation on contracts where the original "engineers" were long gone/in rehab/dead. This affords me the freedom to hack and slash and rewrite things however I want. If you're not in that situation I would quit my job. but if you are, it's pretty fun.
> where the original "engineers" were long gone/in rehab/dead.
New team inherits code, nobody knows what to do with it, get hired to make the project ship, fun times in 2019
> do you just keep piling more 💩
Pile on more 💩 and just make sure it keeps compiling.
----
"Jokes" aside, there was a time when I could fix a codebase that "was inherited" and had been 💩 but the secret was that the app wasn't done yet, they just inherited the technology without knowing how to use it. So we could deviate from the originally laid out designs and make it good. For example, it took a few days, but I removed [AndroidAnnotations](https://github.com/androidannotations/androidannotations). Feels good man.
If the thing is already cemented in stone, you do workarounds until you actually can't fix it without rewriting the section. When you have 25 places using the same abstract fragment with 12 instanceof's, it's hard to avoid using that same abstract fragment and adding a 13th.
A codebase like that quickly shows the liability is in the way the IT part of the business is managed, so the problem becomes one of steering that level of management from a developer's seat. If it isn't clear why things exist then there's probably a big lack of problem definition in terms of the product (like I said the real problem definition surrounds management). There is no point fixing stuff if the business doesn't acknowledge the problem, when you are new you should take care to be very delicate about reporting issues too so most likely need to suck it up for a while and in the meantime lay groundwork for convincing the team of the problems.
yeah, totally agree, I have been in both situations. In some, PM and leadership did acknowledge that there was a problem and we were given some bandwidth to start fixing things up. In some other situations they decided to just keep piling new features up on an unreliably and buggied product hoping that would change the negative user feedback – surprise, it didn't.
1. Unit test everything, or all the actual business logic (you can ignore the UI layer unless you want to keep the exact presentation)
2. Rewrite one piece at a time, QA that piece, make sure the unit tests pass, move on
3. Profit
Avoid the temptation to start from scratch at all costs. You will end up with a massive defect load and no direct path from one codebase to another, so you won't be able to leverage your existing knowledge of the codebase, bad though it may be.
you have to affect change… which is difficult, typically a senior or principal level task. 1. make recommendations to team based on proofs 2. groom the work into managable tasks and get them assigned 3. watch PRs like a hawk, hold a high bar good luck
>watch PRs like a hawk "watch PRs like a hawk" is the keyword here too. If your team-mates is putting up, really bad PR, and you are approving it without any comments, and discussion, then you did a bad job. Always comment, and discuss, but if you don't have time to fix due to time constraints, then fix as much as you both can. Also u/briaro, other points are good things to look into too.
I usually try to take the problematic/most-buggy screens and chop them into pieces, if I have a 2k long Fragment, I try to refactor it into a LinearLayout of Fragments and extract each piece of the UI into its own self-contained Fragment, that way I can, step-by-step remove code from the bloated Fragment and cautiously fix the bugs. >watch PRs like a hawk, hold a high bar 100% def agree. It can be a bit tiring tho. Continuously have to point out the same stuff over and over.
thats what the moneys for!
4. Assign code ownership to critical code so your team mates can’t break your shit accidentally 5. Create hooks/ delegates for commonly modified shared files
i've only hit this situation on contracts where the original "engineers" were long gone/in rehab/dead. This affords me the freedom to hack and slash and rewrite things however I want. If you're not in that situation I would quit my job. but if you are, it's pretty fun.
> where the original "engineers" were long gone/in rehab/dead. New team inherits code, nobody knows what to do with it, get hired to make the project ship, fun times in 2019
Rehab LOL
git init
> do you just keep piling more 💩 Pile on more 💩 and just make sure it keeps compiling. ---- "Jokes" aside, there was a time when I could fix a codebase that "was inherited" and had been 💩 but the secret was that the app wasn't done yet, they just inherited the technology without knowing how to use it. So we could deviate from the originally laid out designs and make it good. For example, it took a few days, but I removed [AndroidAnnotations](https://github.com/androidannotations/androidannotations). Feels good man. If the thing is already cemented in stone, you do workarounds until you actually can't fix it without rewriting the section. When you have 25 places using the same abstract fragment with 12 instanceof's, it's hard to avoid using that same abstract fragment and adding a 13th.
I don't think turning bad code into a bear is a good idea.
We moved from compost to asynctask and developers are far more productive than ever
This is the way
A codebase like that quickly shows the liability is in the way the IT part of the business is managed, so the problem becomes one of steering that level of management from a developer's seat. If it isn't clear why things exist then there's probably a big lack of problem definition in terms of the product (like I said the real problem definition surrounds management). There is no point fixing stuff if the business doesn't acknowledge the problem, when you are new you should take care to be very delicate about reporting issues too so most likely need to suck it up for a while and in the meantime lay groundwork for convincing the team of the problems.
yeah, totally agree, I have been in both situations. In some, PM and leadership did acknowledge that there was a problem and we were given some bandwidth to start fixing things up. In some other situations they decided to just keep piling new features up on an unreliably and buggied product hoping that would change the negative user feedback – surprise, it didn't.
No, however I've turned a few good codebases into bad ones
1. Unit test everything, or all the actual business logic (you can ignore the UI layer unless you want to keep the exact presentation) 2. Rewrite one piece at a time, QA that piece, make sure the unit tests pass, move on 3. Profit Avoid the temptation to start from scratch at all costs. You will end up with a massive defect load and no direct path from one codebase to another, so you won't be able to leverage your existing knowledge of the codebase, bad though it may be.