Write some code and plague it with anti-patterns or not write it at all, any escape from this dilemma for a beginner? [duplicate]

Question

I am now working on a project that started as university homework and actually, still is a university homework (not turned in yet...) and, if I'm successfull (that doesn't mean turning it in and getting a better-than-failing grade, that means bringing it to publication quality), this is going to be the largest piece of code I've ever written. I'm noticing I'm violationg I'm violating many commonly believed best practices... and, perhaps even worse, I don't quite see how could / should I refactor my code to make it adhere to them. But, since the deadline is closer and closer, I'm trying to simply finish my work as of now.

I must say, I have (maybe too) high hopes with regard to this piece of code... I mean, I'd like to actually publish it at some point. Of course, I might first turn my homework in, then try to work on it until it starts adhering to common best practices... But I fear this is hardly possible? Because of my lack of experience, my former habit of rejecting people trying to teach me about patterns, anti-patterns and code smells and my lack of deep understanding of those patterns, I'm afraid I'm going to sooner succumb to paralysis by analysis, rather than bring my code to good quality by myself.

What should I do with this piece of code I'm writing now?

Answer 1

Dilemma? I'd call this an opportunity! Definitely write the code! What it will teach you is worth so much more than the cost of having some bad code.

Only when you have experienced the up- and downsides of a given practice can you understand when the use it and when not to. If you never write bad code (and see the problems it has) you will never be able to learn all that is needed to write good code.

Answer 2

Here is another rule:

Perfection is the enemy of Progress

Unless you projects purpose is to demonstrate your understanding of software engineering best practice. Then you are better off with finished working code than unfinished well designed code.

Answer 3

One of the tools I find most useful for working through bad code is code review. Having another pair of eyes can help you see ways to improve a bit of code in a way you hadn't considered before.

First, write straightforward code that works. At least you have something that way. Then, show it to someone else. If you were in a workplace setting, you could show it to your coworkers. Indeed, many teams require code review as part of their process.

Since you are in an educational setting, you have different options. You could take it to your instructor for review. They are there to help you learn, and often offer office hours for this very purpose. They may also have teaching assistants that can help as well. You could even go to a different instructor if you feel more comfortable with them.

Some schools offer help centers for certain subjects staffed by more advanced students, often costing little to nothing. If your school does not have such a service, you could ask other students in your major for help reviewing your code. (I suggest not asking for others currently taking the same class for review as it might be construed as cheating.)

If you really don't feel able to use any of the above resources, you could always post your code on CodeReview.SE. Many people reviewing code there have been professionals for many years.

Reviewing is hard, and you don't need to strictly follow all the reviewer's suggestions, but it should at least help you to see different ways to approach your code.

Answer 4

I think your teammates of the same project(if you work as a team with others) would provide you better advice(s)/feeling, than me, about your program structure design or logic flow, etc.

I agree that those design paradigms are no possible being understood overnight. But I think you could start from SOLID, which is the foundation for all those design paradigms, and each one is a language-independent concept. They will help you change your mindset of designing your program.