I'm currently maintain a large project with more than 100000 LOC. The code use the MFC as its framework, in genral, it only has interface part which heavily use the mfc api and a business logic part which full of bad code, confusing logic. The company has some small features delivered to the customer each year(most features are adding code to exisiting project, finding some reference of some api or variable and it' s no different with fixing 3-4 bugs ), most of the tasks are to resove issue and optimize performance . Like other company with maintaining position, it value people who knows much logic about its product. There are people who can quickly finish the job on such project, is it worth to train myself like such a programmer? Is there benifits to work on such project for a long time?
Do you mean a long-term benefit to your career? It depends. If your mission is to bring the monster under control, maybe. Then you can become proficient all the techniques in Michael Feathers' Working Effectively with Legacy Code, and sell yourself as a consultant who can clean up messy code, in general.
But if your mission is to keep it working while changing as little as possible, then no. Instead of learning generally applicable skills, you will spend your time learning every detail of this mess, while it slowly degenerates further. Your market value will gradually decrease because you won't have any opportunity to apply new technology. Eventually the application will become unmaintainable, and the development of the replacement will be outsourced.
BTW, 100K SLOC really isn't very large. It should be possible to refactor this extensively in a year or so.
Working on this type of project is the opposite of what someone would do at Google. At Google, someone would be working on cutting edge experimental cool stuff, they are learning a ton of useful knowledge and are getting a lot of praise for it. At this position, you are learning about bad code that is a spaghetti rabbit hole. There is 0 innovation and creativity but lots of frustration and hair pulling.
I like having hair and I like feeling creative and happy. I also enjoy making lots of money which goes along with that as opposed to being under appreciated.
Hasn't Jeff Atwood already given us enough knowledge as to avoid needing to learn what not to do in terms of coding?
Seems like an easy one to choose from.
You state yourself that there is value to it
However, that being said, it depends if you want to be a maintainer your whole career or be a developer. All code has bugs, so being able to find those and correct them quickly is VERY valuable. But, making that your career goal is not a mindset that makes developers. So, working on this project for a "long time"(being a couple of years) is not beneficial when you could be implementing your own projects. There is no substitute to writing your own code. Which will have bugs that you need to find and then correct and later optimize as you grow into being a strong developer.
I do NOT want to downplay the importance of those skills but spending an inordinate amount of time and not creating anything unique that can stand on its own will be detrimental.
Software Development requires you to be a good proof reader but that does not mean you ARE a proof reader. You are first a Software Developer and proof reading is just a tool at your disposal.
One positive thing I can think of is "boredom". Boring can be good sometimes.
Once you have learned everything you need about the project, may not have to learn much new and you can relax and "just do your thing". I think it's a bad career choice, but if you are near the end of your career it may be the right choice for you.
What I would do is work on something new and interesting, and learn as little as possible about that huge ugly beast. Boredom sucks ;)
Getting in the habit of just making it work quickly and move on is a bad habit to have and leads to stagnation. This does not, however, mean that you should take the opposite tack and demand full rewrites. The ability to incrementally improve code as you get things done is good to have.
What I've tried to do in these situations is use deadlines as a time box to work in. If I have a month to do the task but I can do it in two weeks, I get the rough outline of the work done as fast as I can and then spend the rest of my time cleaning up as much as I can. The goal isn't to fix everything. The goal is to always leave things better than you found them.
The trouble with full rewrites is that they often take longer than you expect, which means you'll miss deadlines. And as you miss deadlines, you will be given fewer and fewer opportunities to refactor, and will become too rushed to accomplish anything. I've seen large-scale rewrites attempted and watched them fail because of time constraints, leaving the original code in an even worse state, and with the developers looking bad in the eyes of management. On the other hand, I have very successfully used the incremental approach, improving the code while meeting deadlines. The more deadlines I met, the more freedom I got from management to fix the mess.
Being a "just fix it" guy, never improving anything is a trap. There is a reason that we call it "bad code". "Bad code" is hard to work with. It creates schedule risk and makes schedules longer. Refactoring is an investment. By improving the code now, you shorten the schedules later. This is why the incremental approach can work well. Each phase makes the next phase easier.
In terms of long-term career benefit, there are really two things to consider. Delivering on-time gives you a reputation. Working with modern technologies makes your resume look good. I'd say the danger sign career-wise isn't that the code you are working on is bad, but rather the code you are working on is old, and therefore unlikely to give you a leg-up in the future.
Bughunts matter, bad code is kinda awesome for that, 100k lines is a bit rough, all things considered.
Good part is that when you find a bug -log the cause-. A person who isn't clearing their variables at the right time will make the same type of error elsewhere.
Then you find the copious work spent poorly implementing a feature found in the STL..
You find 200 lines of a function that are just convoluted stream of thought coding.
Creating objects when functions are the right choice, forcing OO where it has no place.
After a while you have a black book of horrid things that are done to make bad code. This should have some notes on how to spot them.
Then look at your older code and figure out how to change your thought process to not make the same kind of mistakes.