Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Hire an external security company to do an audit and paint the worst case scenario with big lawsuits and money loss.
Convince customer to do a rewrite.
@heyheni actually there are client side security auditors with big experience but may be knowing Java only & not knowing Android basics or may be don't want to increase their headache as too large & too many changes are needed.
Highlighted same issues orally in my team but nobody wants to work on tasks which are not given by client.
Difficult situation. Clients usually will not pay for anything like refactoring that doesn't produce tangible value. Security can be different, but that should have been in there from the beginning, so the client won't pay a second time just so that the company does the job right now.
The only route I see is to convince the management of your company that negligence has cut cost to the point of having ruined the technical product basis - introduce them to the concept of "tech debt".
They will have to invest a lot of money if they want the product to have a place in the future. Which isn't guaranteed, maybe it's being phased out anyway.
If they are not willing to invest, and if the product is vital to the company, look for another job. After the first security breach, the company will be bankrupt anyway.
Btw, the "devrant" tag is only for stuff related to devrant.com itself - not for "developer rant". Since there are only devs here, every rant is supposed to be a developer rant.
@Fast-Nop earlier this maintenance project was with some other company & this product was initially an in-house development of our that client, an IT enterprise company.
About techdebt that enterprise company itself should understand as source repo is still under their control.
I am quite surprised as code is never really reviewed with any seriousness in whole 8 years. No excuse can justify this.
To avoid rework in new features or change requests, I had suggested best practices to my team when I had recently joined this project, but project lead don't want to follow it. He is just interested in visible things like UI only to impress client.
They don't want to do even memory profiling to find high memory usage or leak which I can already see due to Android anti-patterns used in new implementations also.
Sorry about devrant tag, didn't know it's for devrant.com only.
Enterprise IT service companies are generally lowest common denominator. If you care about quality, enteprise is the worst place to be.
You might also improve your life by being a little less theological in your approach. OOP is just one paradigm, clean code is mostly marketing with a little common sense, memorizing lots of library featuresets spreads your time thin and prevents you from going deep. Focus on engineering principles bottom up and the rest will follow.
@heyheni I have tried 2-3 times by sending mails to project lead with highlighting these issues but he ignores.
Project lead is having very good relations with manager & I am just a month old in this 2-3 years old team. This way also I can't do anything.
Now I see only one way as making long term improvements list & keep it in backlog somewhere so that by chance in future somebody from client side higher management find out it.
@SortOfTested I am also not in favor of working in service company, but till now in my life I have worked on our client product companies' projects to build a product from scratch, including in this company. This is the 1st incident of this kind in my experience.
I don't overuse OOP, I use it only where it's logical to do so, helps to reduce efforts, redundancy, gives re-usability benefits etc.
Clean code name is given to attract people who generally don't apply common sense in coding due to some reasons.
About libraries, I think we shouldn't re-invent the wheel when it's open-source, free to use in commercial product by proper license, have long history of improvements, fixes, dedicated team to fix library specific bugs etc.
It's basic principle as 'less is more', less custom code will give you more time to focus on your business logic than common trivial tasks which libraries already do efficiently.
kiki193071yTackle your perfectionism instead. There is no need to make it all religious
prash3259357dWell dont change anything. Continue your good practices in new development