
Ask HN: Best practices for software development? - tumbledown
I&#x27;ve been writing software professionally now for about a decade, but I feel like I&#x27;ve never learned how to do it &#x27;properly&#x27;.
For example, I&#x27;ve never experienced agile methodology, never used unit testing on my code, and only just recently started using source control tools.<p>What are the current best practices I should consider following? And conversely, what worst practices and non-best practices should I avoid?<p>My projects have delivered just fine and my clients and employers have been happy with the work I&#x27;ve done, but I feel like I&#x27;m missing important techniques. I&#x27;ve mostly worked solo rather than on a team of developers so that might be a contributing factor.
======
aaustin
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.

------
surprised_dev
Hi

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.

------
kspaans
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.

------
dontJudge
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.

------
fiftyacorn
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

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

