先从已知经验写代码再规范，还是先循规范再摸索？PHP OOP实践疑问

Hey there, I totally get where you're coming from—jumping into frameworks and OOP when you’re comfortable with procedural code can feel like trying to run before you walk, and that frustration you’re feeling is totally normal. Let’s break down your question and figure out the best path for your personal PHP WebApp project.

The Two Approaches: Pros and Cons to Consider #

1. Build First, Refactor Later (Your Current Plan) #

• The Upside:
  • You get to leverage your existing procedural skills to quickly crank out a working proof of concept (POC). There’s nothing more motivating than seeing your app actually do what you want it to—this keeps your momentum high and gives you a clear, tangible goal to build on.
  • Once you have a working base, you’ll see exactly where OOP would add real value (like reusing database logic across pages, or organizing user management into a reusable component) instead of forcing patterns into places they don’t fit yet.
• The Downside:
  • If you’re not careful, you might end up with messy "spaghetti code" that’s harder to untangle later. But this is avoidable with a little basic organization (more on that below).
  • You’ll have to unlearn some procedural habits when refactoring, but that’s just part of the learning curve—everyone goes through it.

2. Start with Best Practices Up Front #

• The Upside:
  • You build good habits from day one, so you don’t waste time fixing messy code later.
  • Using OOP and frameworks properly can make your app more scalable if you plan to expand it a lot down the line.
• The Downside:
  • The learning curve is brutal right out the gate, which can lead to burnout (exactly what you experienced with frameworks this past week).
  • Without a clear sense of your app’s actual needs, you might over-engineer things or use patterns that don’t solve any real problem for your project.

Tailored Advice for Your Project #

Since this is a personal hobby project and you’re still getting comfortable with OOP, your plan to start with a POC is absolutely the right move—with a few small tweaks to make refactoring easier later:

• Keep your procedural code organized: Even if you’re writing procedural, split your code into logical chunks. For example:

  • Put all database connection/query logic in a db.php file.
  • Store user authentication functions in auth.php.
  • Keep HTML templates in a separate templates/ folder.
    This way, when you’re ready to switch to OOP, you can easily turn these chunks into classes (like a Database class or an Auth class) without rewriting everything from scratch.

• Learn OOP incrementally: Once your POC is working, pick one small part of the app to refactor into OOP. Maybe start with your database functions—turn them into a reusable Database class that you can call from anywhere in your app. This lets you practice OOP in a low-stakes way, without overwhelming yourself.

• Hold off on frameworks until you know what you need: Frameworks are great, but they’re built to solve common problems. If you don’t yet know what problems your app has, trying to fit it into a framework will feel like forcing a square peg into a round hole. Once your POC is solid, you can look at frameworks again and see which one solves the pain points you actually encountered (like routing, form validation, or handling database relationships).

• Don’t stress about "perfect" code: This is a hobby project and a learning experience! Even professional developers write quick-and-dirty code for POCs before refining it. The goal is to build something that works and learn along the way—perfection can come later.

Final Thought #

Your comfort with procedural code is a superpower here—it lets you get things done quickly. Use that to build your POC, then use what you learn from that process to gradually introduce OOP and best practices. It’s not an either/or choice; it’s a progression. You’ll be surprised how much easier it is to understand why OOP matters when you have a real app to apply it to.

内容的提问来源于stack exchange，提问作者Canadian Luke