If a relatively non-techie person is reading your CV (i.e. if HR is doing pre-screening before passing select ones up the chain for consideration) they won't know to check the code quality, they'll just see that you were important for a significant project which proves you can handle yourself well technically.
If a techie person is looking at your CV, they will understand that a lot of code, especially code that is written in your own time so you don't have to go back and resolve QA issues, is far from ideal. If the project was popular, technically impressive, original, interesting, or any combination of the above if will be an advantage to you. A technical interviewer will probably bring it up in the interview, if they do you will be able to sell the good parts of it (and why they mean you'll be good in the position you are interviewing for) and discuss what you would do differently if you were starting now and why (which will give the interviewer a gauge of your ability to appreciate and learn from experience). Recognising a problem and how it can be addressed is more valuable in judging your real world (i.e. imperfect world) abilities than just talking about things that are right.
Disliking parts of your old code is normal. If you look back at your code from a few years ago and don't find things that make you cringe then either you were a savant, very lucky and "on form", had a lot of time to work on it which allowed for regular refactoring as the codebase grew, or (and this would be the worrying one) you just haven't learnt much in the intervening time.
If a relatively non-techie person is reading your CV (i.e. if HR is doing pre-screening before passing select ones up the chain for consideration) they won't know to check the code quality, they'll just see that you were important for a significant project which proves you can handle yourself well technically.
If a techie person is looking at your CV, they will understand that a lot of code, especially code that is written in your own time so you don't have to go back and resolve QA issues, is far from ideal. If the project was popular, technically impressive, original, interesting, or any combination of the above if will be an advantage to you. A technical interviewer will probably bring it up in the interview, if they do you will be able to sell the good parts of it (and why they mean you'll be good in the position you are interviewing for) and discuss what you would do differently if you were starting now and why (which will give the interviewer a gauge of your ability to appreciate and learn from experience). Recognising a problem and how it can be addressed is more valuable in judging your real world (i.e. imperfect world) abilities than just talking about things that are right.
Disliking parts of your old code is normal. If you look back at your code from a few years ago and don't find things that make you cringe then either you were a savant, very lucky and "on form", had a lot of time to work on it which allowed for regular refactoring as the codebase grew, or (and this would be the worrying one) you just haven't learnt much in the intervening time.