Follow the path of what I know, then try to implement correct coding practices, or start with good coding practices and try to fudge my way through?

Question

First off, I want to say that I am used to doing Procedural Programming as my hobby - I'm trying to learn OOP in a couple languages, and understand the theory, just not the practice.

I have a pet-project I wanted to build, specifically in PHP with a database backend (didn't care what one). My main reason was for the app to be used on any device, so a WebApp seemed like the logical choice.

I understand that to build maintainable PHP WebApps, it should use OOP, Classes, Frameworks, Libraries, etc. This sounds logical, so I decide to try some of the popular ones. However, after an entire weekend of just trying them and trying to get through the tutorials, I'm left both confused and frustrated trying to adapt the tutorials to my small project.

I decided, mainly for a proof-of-concept, to build the app in another program (Microsoft Access), and accomplished my main goals in only a couple hours - except the Web part.

My question is, should I follow the path of what I know, then try to implement correct coding practices, or should I start with the good coding practices, and try to fudge my way through? For this project, I would like it to be Open Sourced on GitHub, so I would be open to other people using and changing my code, but I also know that if code is written poorly, it would be hard to gather coders to help.

Answer 1

Best practices are mostly suggestions and proposals gathered from experience to help make projects easier to *able.

The key aspects of this IMHO is the experience part. Though these best practices are good ways for people with more experience to share it with beginners, I think one still needs a minimum level of experience to truly understand what makes this is a best practice. Doing otherwise amounts to following them blindly as the rule of law which in the end I think will slow down your learning as you slowly let others do the thinking for you.

In any case, the absolute paramount most important thing do to in a software project to me is ... well... finish it, ship it... in short make it work !

Anything before that point is vaporware, a figment of your imagination. Only once you have something that works can you truly evaluates if it is slow, hard to maintain, hard to test etc. The process of making it work will expose things for which, perhaps, there exist a best practice that would help you rethink it in a way that makes it easier to reach that goal.

So yes, start with what you know first, take note of things you do that are hard. When you hit a wall take a step back and look at that wall, learn what it is made of. In a great many cases you will realise that YOU are the root of the problem. Your lack of understanding of some part of the issue you are trying to solve, your lack of knowledge on how you can better leverage the tools you have or your ignorance of other tools that are right under your nose the whole time but were not ready to start their mastery.

At the same time, keep reading about new ways to do things. Read these best practices and try to see if they apply to anything you are finding difficult in your project. If not, remember their existence and revisit them from time to time. Stay curious. In time you will see that the observations made above just click naturally with the knowledge you acquire here.

Lastly experiment with what you've learned and see if it does make things simpler. keep at this and eventually you will read the best practice for what they are. Just simple advice from people that have suffered and learned a way to make it easier. Heck you may even disagree with some of them and see that your way actually works better for you. But without knowledge you are just walking blind.

good luck

Answer 2

TL;DR

You'll never know it all. There's pretty much always more depth and breadth around every individual "thing" you can know. Learn as you go. Apply the "best practices" you think are relevant now. Make mistakes. Just try to avoid making really costly mistakes. Find mentors if your project could lead to costly mistakes.

---

And now the long answer ...

1. "Working software is the primary measure of progress." (Agile Manifesto)

If you can see the edges of your knowledge, that's awesome! Pursue the edges! Keep learning! But bear in mind, you could learn and analyze forever.

Build something.

---

2. Learn and make mistakes; but don't make "bad" ones.*

Keep pushing the boundaries of your knowledge/skill. You will make mistakes. You can learn from them. But, you don't need to be reckless.

The time you spend finding and working with more experienced developers and mentors should increase in proportion to the business value and risk profile of the project.

If you're making a little CLI for yourself: Get it working however you want.

If you're writing a bank's web portal: Surround yourself with very experienced developers.

---

3. "Best practices" should be written in quotes and spoken with a wink.

"Practices" are promoted to "best practices" when they're observed to be successful at accomplishing X in at least some cases. Someone recognizes the benefit of Practice A for achieving Benefit X and declares it the practice to be a "best practice" on the internet. Others agree — often for good reason. But, from that point on, we generally lose sight of why some practices are "best practices" and others are either "antipatterns" or "stinky."

The trouble is, a "best practice" is never self-serving. "Antipatterns" aren't actually diabolical in and of themselves. And, even a "stench" only sometimes comes from rot. Sometimes, that stink is just a fancy, delicious cheese...

You don't practice things like "dependency injection" (DI) because "dependency injection" is inherently valuable to the business. It's not even remotely essential to building a working product. It accomplishes something that you maybe want in your final product. But, it might also just make your work take longer for no benefit ...

Hmm...

So, should you follow "best practices?" Even if you don't understand them? ... Err ... yes. I mean no. But yes. But, only the ones that really apply to you and your software and its purpose.

Invoke the POAP! ^{(Yup. My blog.)}

Principles, patterns, and practices are not final purposes.

The good and proper application of each is therefore inspired and constrained by a superior, more final purpose. You need to understand why you're doing what you're doing!

(The POAP is not exempt from the POAP.)

So, you may not fully understand every nuance of DI, for example. But, if you understand the intent, you'll know if you "should" use DI, and you'll sort of implicitly understand DI better.

And, once you've release the product, you can reflect on whether DI (or whatever) was really beneficial. If so, articulate why in writing. If not, articulate why in writing ...

---

Bonus reading / Somewhat relevant:

Analysis paralysis is a thing. You need to analysis and learn; but, you also need to get stuff done. Balance.

You might always feel like a cowboy coder.

---

^{* You actually will make bad mistakes if you do anything noteworthy. But, you're human, I assume. So, we forgive you ahead of time... Or, at least I do. Maybe. ... Well ... We'll see.}

Answer 3

My question is, should I follow the path of what I know, then try to implement correct coding practices, or should I start with the good coding practices, and try to fudge my way through?

Maybe try your best but still ship something? There are two different forces between how the users evaluate the quality and appeal of a product and how the developers behind it evaluate the quality of the code. Try to make these two forces as harmonious as possible. Focusing on one too much at the expense of the other is usually how you end up with the most counter-productive routes.

Answer 4

Well, first of all, I would suggest that adopting good coding practices isn't fudging... The trick is understanding the purpose of each practice and how to properly implement it.

Rapid application development environments are seductive, because you can get a lot done in a really short time. I built an entire accounting system in Access once. But you said it yourself: you can't take an application like that to the web without a rewrite, and the tools you need there are really different.

There are reasons why nobody uses visual design tools like Access or Visual Basic anymore. They tend to insulate you from the code that really accomplishes something. Access is a fine tool, but it requires the very thing that web applications are specifically designed to avoid: installation. Customization of its appearance can be difficult; even if you don't need it on the web, an Access application will always look very much like any other Access application. Most folks who write their first Access application don't know enough to write a good application, and Access makes it easy to write a bad one.

So now you're resigned to learning a new technology to get your application on the web. Should you build it the right way from the start? Of course. But learning a new development environment and philosophy is like learning any other thing; you have to slop it up for awhile to get things right.

That's why I think you've posed a false dichotomy. Nobody learns all of the "best practices" first. They learn them as they go. But to be productive in any OOP language, I think you'll need to know some OOP, or at least how classes fundamentally work.

For what it's worth, I don't think PHP is your best choice. PHP is attractive because it is "shallow," meaning you don't have to know a lot to write a working program. Best practices are left largely up to the developer, which means that PHP is not going to help you write "good" programs. This isn't necessary a bad thing, but it does mean that, like Access, you may also be eventually ditching PHP for a more robust platform.

Answer 5

Consider OOP as just another pattern that you can apply at the right time. OOP not a framework that can methodically solve every task. Such a thing does not exist in software engineering.

Also note, that what people claim to be good practices are sometimes questionable. I have often seen inexperienced developers adopts very complicated programming patterns that were unnecessary for the given problem. The complexity of the code should be appropriate for the complexity of the problem. Simplicity is an important value.

Articles on the web, statements from industry experts and advise from senior colleagues can well be wrong. I have seen this a lot.

Therefore I recommend that you apply the simplest solution that solves your problem. Likely, this will encompass the usage of one of the popular frameworks in your space. Within this constraint you can freely choose what kind of code you like. Do not simply think that their way of doing it is appropriate for your case.

Also, understand why certain techniques are recommended. For example, OOP is about encapsulation. You can encapsulate in other ways (procedures are also about encapsulation).

A negative example: Sometimes people write a data access layer to abstract away the database. Here, the essence of this pattern is to become independent of the concrete data store and to expose a simpler interface to higher layers of code. But if you don't need these benefits then you don't need a data access layer and can save the work. Yet, many experts recommend always doing a DAL which is an incorrect recommendation.

I find that good code often is fun to work with. It's fun because you get to work on actual requirements instead of tending to infrastructure concerns. If you find that what you are doing is too much grunt work then likely you have picked the wrong set of patterns.