Ask HN: Best practices for software development? | Hacker News Reader

Ask HN: Best practices for software development?

5 pointstumbledown6 comments

I've been writing software professionally now for about a decade, but I feel like I've never learned how to do it 'properly'. For example, I've never experienced agile methodology, never used unit testing on my code, and only just recently started using source control tools.

What are the current best practices I should consider following? And conversely, what worst practices and non-best practices should I avoid?

My projects have delivered just fine and my clients and employers have been happy with the work I've done, but I feel like I'm missing important techniques. I've mostly worked solo rather than on a team of developers so that might be a contributing factor.

View on HN

Read "Code Complete". Read "Mythical Man Month." Maybe read "The Pragmatic Programmer." If you're interested in learning more about testing, read "How Google Test Software." If you work on a lot of other people's code, read "Working Effectively with Legacy Code"

Good unit tests are absolutely crucial to any kind of future refactoring effort. They are helpful at finding regressions and give you some confidence that you do not break the paths that are tested. If you work in a team larger than one, code reviews are a must. Code reviews allow both participating parties the opportunity to learn, improve the overall codebase, and catch bugs. I also think writing code comments and documentation is absolutely important. Mostly so the "next guy" understands why the code is doing what it is doing. Most of the time the "next guy" ends up being you.

Best practices varies depending on the project & team size. What's best for team of four might be bad for team of 100 or for single developer. For example source control, when I work alone I used it mostly as history of my code and backups but don't care too much about branching, but when I work on something bigger with e.g. ten people involved it's almost impossible to work without setting some rules about that.

Agile is becoming a standard for bigger teams, but it also might be bad for some types of the projects. If you join any agile driven methodology you can pick up basics in like one day and then just follow up - I wouldn't worry too much about it.

Unit testing from my perspective is really crucial even for small projects developed by one person. On the top of unit testing it's at least good to read a about BDD / functional / integration testing to understand how you can test your code even if you find out it's too much for you.

Microservices is another trends worth to read about but it also doesn't mean that you should create every project using microservices/SOA.

Best practises are the very open topic, it is hard to know without knowing what kind of project or languages do you use. You should also keep in mind that following trends might be good or bad if you don't understand what you want to achieve - I saw many projects killed because over engineering. From my perspective code is good as long it is simple.

I think the best source of knowledge is following technical blogs related to language you are using or industry.

If you ever work on a team I can't recommend code review enough. I can't comment on how useful it is to review your own code after the fact by reading it, but you could certainly give it a try that way if you are currently working alone.

Code Review requires two skills (one interpersonal, one technical):

1. How to read code (often in diff format) and run through it in your head to look for technical correctness.

1a) How to read code and look for style issues like code structure and variable/function naming.

2. How to write constructive feedback so that the author of the code feels happier after your review than before it.

The best part of code review is that even in an environment that doesn't officially support it (e.g. no code review tool or source control, or an official policy against pre-commit/pre-merge reviews) you can easily do informal post-commit reviews. In my opinion the two major benefits are to decrease your bus-number, and to slow down the pace of code changes (at least if you have a pre-commit/pre-merge review policy). By decreasing your bus-number I mean that you force someone else to read and understand the code before it goes into "production". Even with half-hearted reviews this usually means you've got at least one other team-member who is can say "Oh yeah, I remember that $IMPORTANT_FEATURE was changed recently." And finally by slowing down the pace of code changes I mean that code spends an extra few hours/days sitting around, which gives more people a chance to look it and spot issues before releases. This is kind of a social hack, it stops from-the-hip code changes from immediately going into your codebase which increases the chances of the author or someone else giving them a sober second look.

I think there's some ebb and flow in what practice is ideal.

There are benefits to a detailed up front design. Conversely there are benefits to jumping straight into code, to get feedback and let the design emerge through real experience.

Unit tests are a nice way to define interfaces. Conversely sometimes it's better to discover an the ideal interface organically rather than setting it in stone up front.

Some of it is just differences in what medium you perform design. People want the medium to be like playdoh so it can be changed. Before they cast it in marble. Some languages are more like marble, some like play doh. But don't ever delude yourself, thinking you have found the best way to design.

Source control is not really software development. It's a very good thing, but in the same way that eating a healthy lunch will assist creating things.

I recommend "Site Reliability Engineering" from O'Reilly. It is about how Google uses Software Developers to achieve scale, and puts a focus on how developers can build and design scaleable systems

Read Clean Code, keep code small and always have a few tests you can auto run.

Reply on news.ycombinator.com