Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
hmm. On my Android 14 it actually still can be allowed from the PlayStore..
but feel free to try skyRant, my custom client! https://github.com/joewilliams007/... -
@joewilliams007 I hate manual testing so much that I refuse to do it if it's a lot.
I'm super speedy at test writing now so I spend my time doing that instead 🍑💨
Seriously though if you wanna be able to change the app in dramatic ways cheaply: tests will get you there -
iceb11561y@MammaNeedHummus Oh oh question about tests.
It's easy to write the tests as you add new things but is it troublesome later on when you make changes to design and have to figure out which tests to change/remove? -
@MammaNeedHummus yesss. thanks for the advice. will take that with me. i'm too busy for big changes now, cuz started studying. And it kind of is just a fun client that i just use alot myself :).
-
Good question @iceb I've heard lots of different ways of tackling that problem but the algo that's worked for me so far is:
1. Research: Prototype your refactor ideas first, see which tests break and why vs. why others didn't to inform your next more
2. Change it safely but be fast: Take small steps to alter the code safely by adding tests (asserting on behaviour of the code rather than state) to get there (with an emphasis on speed here as the smaller refactors you complete in isolation, the less your likely to fuck up and break it)
3. Keep doing step 1 and 2 as fast (yet safely) as you can until your code is in a better shape
Again you can prototype refactors for small scale and at larger scales.
But the important thing is maximising feedback you get from changing the code as it's not until your neck deep in some nested hell do you find issues that stop you in your tracks. -
Only now all your changes are tested and verifiable at the click of a button and you can experiment further with options to proceed that you didn't have otherwise.
Full rewrites rarely ever work. Refactoring is intended to be simple and quick so it's fast and a lot can get done in a short period of time.
To avoid brittle tests you need to look at what breaks in them the most or what you spend the most amount of time changing in tests when you're trying to do a refactor.
Usually it's because the tests are testing some class or function that is doing too much or it's dependencies are crazy.
Often the best thing todo here is to safely split up these classes/function into more manageable, shy, pieces so the side effects from changes to them are minimised to the rest of your code.
Decoupling is very important and tests almost for you todo that out of the box so you usually end up with very solid, "bulletproof" code -
It helps to test at the interface level as much as possible and to be pragmatic in your choice of _what_ to test.
If you wanna read more see Working Effectively With Legacy Code + Pragmatic Programmer 20th Anniversary edition -
iceb11561y@MammaNeedHummus Thank you for the write up. I've heard mentions of these books. Didn't realize the "legacy code" book works for newer code too 😀
-
@iceb everything becomes legacy eventually if it becomes hellish enough.
If you know what to avoid and how to deal with it when you find it, you learn prevention methods and code smells as well to stop it's impact in the first place -
@violet-isle how does it even show a 4.4 rating on your phone and a 4.7 on mine. Google magic :)
-
@joewilliams007 fuck i hate corporations. i wish there was an actual good alternative.
-
@iceb seems the like the germans are more appreciative. But true, the age recommendation USK probably also doesnt exist over in the US.
why does the app not support newer versions of android 😞
question