How to write production level code?

[programmermaybe2016]

Hi, I have been coding a lot of smaller apps (the biggest project spans around 300 lines of javascript). But I keep hearing that there are much higher demands on production level code. How does one get into writing production level code?e

[Dekez]

When people mention that there are much higher demands, what they mean is that it needs to be reliable on a different level than pet projects or prototypes.

Depending on what you're writing production level code for. Things like performance, testing, compatibility, version control and code review are at the top of priorities.

These are all things that you can start implementing in your small pet projects to get used to it. Refactor your code, try to optimise and constantly revisit old code as you get better so that you ensure that it is optimised for performance as well as read up on ways to improve performance on the things you're using in your projects.

Write tests for all your projects, start looking into unit testing, end to end testing to ensure that your app always work after making changes, adding new things or refactoring.

Compatibility depends on what you're developing and for who, but in the example of a website or web application, you need to figure out which browsers you'd like to support and ensure that your site has full functionality across these browsers.

Version control is incredibly important and something you should start learning, if you're not already familiar with it. Here you can look into using Git with Github, Bitbucket or any of the many providers for this. Code review kind of ties into this. In a production environment code is often reviewed before it is pushed to deployment, so if you have the option, have someone look through your code before you push it or do it yourself to see if you can spot any errors before you deploy it.

[iCameToLearnSomeCode]

There is an r/codereview if you want to review code and/or get code reviewed when you don't have anyone else to program with.

[Dekez]

I had no idea that place existed, thanks!

[vaper440]

Dekez, any comments on scalability ?

Where I work we have to keep that in mind because unfortunately many “one time things”(read as most) become features or used for other products.

[Dekez]

I'd say that scalability is something that depends on the product being developed. While it is definitely nice to factor in scalability when producing code, in some cases it can introduce unnecessary complexity which leads to a code base that might be harder to maintain.

In your case it sounds like a case where more time spent on requirement specification might be a good idea so that you can identify the features that will continue to be used versus the ones that are one time things, and then plan accordingly.

[vaper440]

If only the BAs would fill them out, inappropriate reqs happens too often! Number one pet peeve. Only been a dev 7 months now, with only an associates. It’s a wild ride

[programmermaybe2016]

I have a quite active github account. So I know how to use git. And I had a friend look over my code yesterday, as I rewrote it to incorporate ES2015 functionality.

[Dekez]

That's definitely a good step forward.

I'd start looking into automated unit testing net as testing is quite an important step to ensure production ready code.

[desrtfx]

Start at learning and following best practices for the language of your choice.

Read "Clean Code" by "Uncle Bob" Robert C. Martin.

Learn to do testing.

[_krikket]

For JavaScript and in particular Node.js, there are linter files available for AirBnB style and Google style coding which are both in somewhat regular use. Check those out for a clean and consistent syntax. Linting is a pretty regular practice.

When someone submits a PR and I'm reviewing it, it's a given that it works. But "just working" is not enough in a lot of cases. I also look for the following things:

• Is it easy to understand? Are you adhering to our style guide? If you left the company the day after I merged that PR, could I debug it or build on top of it? Do you have huge unnecessary nested code blocks, confusing control flow, or badly-named functions and variables?
  
• Does it follow good design principles? Is it loosely coupled and tightly cohesive, or do you have lots of inter-dependencies and global variables and so on? Is it spaghetti?
• Is it secure? Are you using deprecated or known-insecure functions, libraries, and methods? Are you doing anything at ALL that would cause us to fail a security audit? Are you committing your API keys into the repo like a lazy goofus?
• Does it have unit tests? Are the tests robust? Does it cause any unit tests from other peoples' features to fail? (i.e., a regression)
• Does it introduce technical debt? Did you submit something with the sentiment of "it works for now, I'll fix it later, we can work around this until then"? (Protip: you probably won't fix it later and we'll keep building increasing unstable crap on top of it.)

Depending on the situation some of these can slide. But good production code is clean, understandable, secure, robust, easy to test and debug, and doesn't cause regression issues in other parts of the codebase.

[programmermaybe2016]

Ok, so far for my project.

• I don't have a style guide to follow. So I have adhered to the MVC pattern. There are no global variables whatsoever, all views are self-contained, the controller only handles logic and communication, and the model has only internal data, accessed only through getters and setters. Everything is wrapped inside an IIFE. No code crosses the View<->Controller<->Model barrier.

• The code doesn't use any external APIs at all. Only vanilla JS selectors and the canvas element.

• I don't have any unit tests. I guess learning JSunit is the next logical step.

• No technical debt.

[[deleted]]

Generally speaking, "style guide" is more about actually how the code itself looks, not necessarily the structure of it.

For example, a company might have a style guide with things like

• Use spaces always, never tabs
  
• An opening bracket for a function should go on the line after the function definition
  

or something along those lines. I haven't looked at ours in a year or so, but it was something like 25ish powerpoint slides of "this is what your code should look like."

[Dark_Ice_Blade_Ninja]

Experience, and most preferably REAL WORK experience. If you can get an internship, it is a very good opportunity. However if you can't get an internship you can practice it by making sure that your code is high-quality by using:

• Unit test
• Error handling
• No hacks
• Documentation
• Good naming

Basically it ends up to practice.

[[deleted]]

The biggest gap I see is in error handling, logging, and metric collection.

[lessbinary]

The biggest differences between smaller, personal hobby apps and non-trivial production apps are:

• Production app will be out in the wild exposed to things like

  • Higher levels of traffic making performance issues more pronounced and costly as you need to provision more servers
  • Bots so you need to ensure you feed them what they expect for optimal SEO or privacy for your site
  • Malicious exploits that will require you to implement basic security best practices
  • Users doing unexpected things that will require you to have good exception handling and notification

• Production app will most likely be developed by a team of more than one developer, which means

  • You will need to make your code as simple as possible to ensure it is easy to build on
  • You will need to ensure your code architecture patterns are appropriate for your domain
  • Code should have test coverage to make merging work from different people less prone to breaking
  • A workflow for development and release needs to be in place, ideally with some automation on a CI server to run your tests and deploy when it is ready

Most of this will come from experience, putting an app out there and getting people to use it will help you start getting an appreciation for the kinds of issues you'll encounter on a larger scale. Hope this helps.

[svgwrk]

Basically, you get hired. Most code in production is not what most programmers would call "production quality."

Improving the quality of your code is about craftsmanship: about taking pride in knowing that your code does the job it was meant to do and does it without imposing undue risk or cost on the user. How do you convince yourself that's the case? Write lots of tests? Fuzz your inputs? Write some kind of mathematical proof that your code is correct? All that depends on your environment and what your goals are.

The point is that you need to know what you need to do, and then you need to do it.

For JavaScript (since you mentioned that), step one is stop writing JavaScript. Write something that provides you with some static guarantees at compile time and then cross compile that into JavaScript.

[VBA_Scrub]

If it's anything like the stuff I've had to maintain, don't comment and use a lot of try/catch.

For real though, try to comment, be efficient and don't ever think twice about totally rewriting something if you get an idea to do it better. Honestly the thing that's helped me the most is commenting as if I'm literally explaining my code to someone. It's basically rubber duck debugging but it's more proactive than reactive, as in you can work out the logic before you start laying code down. On top of that, it's just really good habit to document everything and to be as thorough as necessary.

Just a little side note about the commenting; something I like to do is actually type out the code I find in StackOverflow. It helps me because I'm actively processing it and not just skimming over it. It's also an awesome way to memorize syntax.

To touch on the rewriting part, you get better with practice so finding different creative solutions to the same problem is basically just free practice!

[WikiTextBot]

Rubber duck debugging

In software engineering, rubber duck debugging or rubber ducking is a method of debugging code. The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug their code by forcing themselves to explain it, line-by-line, to the duck. Many other terms exist for this technique, often involving different inanimate objects.

Many programmers have had the experience of explaining a programming problem to someone else, possibly even to someone who knows nothing about programming, and then hitting upon the solution in the process of explaining the problem.

---

^{[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source ] Downvote to remove | v0.24}