Recently, a friend of mine joined a big company and complained to me that the code of their big company was not very good. Even he could see the logic flaw and no one changed it. Makes him wonder a little bit about life. So why is some big company code so bad?
The first reason many people give is history. Maybe this is the most important point, if it is an old project, almost everyone is coming to take over a project, if the previous maintenance of the project, high level, code flow, code specification, logical rigor is very high, congratulations, you have a growth starting point to learn excellent code. Lucky for you, fish brother before contact such a project, is really well written, clever design pattern, logical, and read the system source code. But if you’re not lucky enough to be working on code from a team that’s not very good, then you have something to do, rewrite, or refactor. Bad code is the same as a lump of shit, a lot of time is and a lump of shit coexist do not dig deep, perhaps where to dig down to bury you, throw a tuo code to the excrement mountain, to achieve their own purpose, can run on the line, you have to figure out the mountain of excrement which tuo is who pull, pull what people eat, it doesn’t mean anything. You can throw a pile of code into a big mountain of shit and get your work done. After all, who hasn’t maintained bad code? Big enough, it’s shit mountain, and no design pattern matters. This is the time to spend overtime to rewrite, or you can’t do it, waiting for you or leave.
It is easy to understand that the business logic of large companies is complicated. A system is integrated with N multiple systems, a business object has hundreds of fields and dozens of states, and a process has dozens of links. Large company personnel change a lot of development or outsourcing personnel, outsourcing personnel mobility can be imagined. Upgrading technology is too costly. But no one dare to tear down and start all over again, only modified after the test workload can not be underestimated. And change good no work (no performance), change the problem who can not be responsible for, so as long as the code can work, the development behind are in the above tinkering, resulting in the overall code riddled with holes miserable. Technical leaders only focus on functions, not codes. In fact, many leaders do not write codes at all, but directly become “architects”. To be honest, they can’t write codes themselves, which is also a major reason.
Also, the leader doesn’t care what technical implementation you have, whether you have 10 lines of code or 1000 lines of code. So, in this context, it’s very difficult to write code that looks like it was written by one person and understood by another. As long as the old code is fine, no one will polish it, no one will do the thankless work, and code refactoring/code review is often a mere formality. Some big projects increase code volume by 50% per year, which is a lot of negative equity.
Well, isn’t everyone in a big company very skilled? If you have this idea, you are totally wrong. Every year, large companies recruit many new graduates. Some of them become successful and run away after a few years, and some of them do not grow up and still have to write code continuously. It’s gonna turn into a shit hole. When it comes to interviews, there is a price to be paid, and many companies won’t do it because of the cost.
A team, at all times, should distinguish between what is really bad and what is business complex; If you can’t tell, don’t fix it.
We should also actively seek: if the business is complex, can it be more simplified and abstract; If it is rotten, can be changed in the limited cost of some better.
