I've been working on a LAMP application(a social network), and am about 4000 lines of code in, and have a working prototype. I learned PHP this way, and thus it isn't programmed very well, and am now realizing I should've used a MVC framework; either my own, or better yet, a pre-made one such as Laravel or CakePHP. If I plan on continuing to work on this project, should I go back and fix it?
closed as too broad by gnat, amon, 8bittree, Bart van Ingen Schenau, Frank Hileman Nov 6 '17 at 19:29
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Certainly. If you're only learning, it's more important that you rewrite code to learn from your mistakes, instead of trying to finish by force a poorly written system that competes with the thousands of other social networks out there.
The "build one to throw away" philosophy works very well for learning, less so when you're financially dependent on the system being finished.
Refactoring heavily (even throwing parts away completely, 4000 LOC is nothing) also allows you to identify problematic areas where you know you've done things in a clumsy way, put some questions to codereview.stackexchange and improve your code quality at the same time as learning a proper framework. I'm not a PHP developer, but I believe that Laravel is a popular and widely used framework.
It's ultimately a judgement call. For example, if your functional requirements are still somewhat of a moving target, then refactoring now may well be a waste of time -- later on, new or changed requirements may suggest another altogether different functional decomposition. That's what usually happens to me on the first cut of any new development project.
A more balanced approach may be to "mess around" with your code for a while, until you get a reasonably good feel for the project's ultimate "destination". Then you can better think about the best way to get to that destination. Of course, at that point you may have a (much) larger "mess" of code to refactor. That's the judgement call part.
Refactoring should better express the functionality as reusable abstractions, i.e., as intuitively sensible abstractions that can be composed in a reasonably straightforward way to implement the desired functionality. So, when is the functionality well-enough and stably-enough defined to permit that?
If you refactor too early, you'll either have to do it all over again, or you may be tempted to live with your first, sub-optimal, refactoring effort. Either choice is bad, or unfortunate. Alternatively, as mentioned, refactoring too late involves juggling a bigger mess.
I've done both. Indeed, you can't really ever get it exactly right (if there is such a thing). Since you're asking the question, I'm guessing you don't have much experience at this sort of thing. And in that case I'd further guess you maybe should "mess around" a little more. Refactoring at the first moment the idea crosses your mind is (I'd guess) likely too early. 4000 lines of code may sound like a lot, but it really ain't.