

Do you worry about the quality of code? - xackpot

I have recently submitted our app to the app store after weeks of coding and hacking things to work. At this point I have realized that the quality of code has deteriorated considerably even though it works. The structure of the code is not lost, but in order to make it work, I have put a lot of hacks.<p>When I look back at the code, I can&#x27;t believe I have written it and there are 1000 other ways to write it better. But I am hard pressed for time since my team has to ship it fast and validate a few points for our next round.<p>So I wanted to find out from HN members, how do you keep track of the quality of the code? Do you try to keep it well structured and re-factor your code often? What steps do you take to maintain the quality of the code. I mean, not just writing &#x27;good&#x27; code, but what do you do to ensure that it is easily re-factorable?
======
acron0
For me, this is something that has just gotten better with experience and
practice.

Of course, we all start out with a clear and rigid vision about how the code
should be - you use good design patterns, you let your data dictate the flow
of your code and inevitably, some scenario comes up that doesn't play into
your structure well and you concede a hack. Then a couple more. But with
experience comes being able to identify areas that are more likely to attract
smelly code and thus you are able to prepare in advance.

One of the paradigms that I am always reiterating to my team is that their
code only needs to be 'good enough' and of course, this is relating to
productivity. It doesn't need to be the shiniest example of a memento
implementation I ever saw - first and foremost, it needs to work. And it needs
to work when I need it to work, not 2 weeks after because you just had to
refactor it just one more time. This is the reality of being a professional
developer, working with customers.

~~~
xackpot
Fair enough. I agree that the code has to be working but sometimes, even after
laying down the guidelines on how to write code a better way to structure out,
things go out of hands with multiple contributors. In my opinion, the solution
to this problem is to refactor the code as soon as the code is checked in. Not
necessarily refactoring the whole code, but to make it conform to the existing
design and structure.

------
bjourne
I'd assert that if you're a great developer, then the code you write quickly
is not worse than the code you write slowly. For every problem there is a
perfect way to solve it, and every hack and other kind of ugliness your code
acquires increases the distance of your code from the ideal one.

If you write code too fast it gets those imperfections because you are not yet
good enough. But you are on your way to improve since you are able to reflect
on your work and see how it can be better.

A good way to get better is to write code as slowly as possible. Take your
time and focus on making every detail as good as you can. It will take time
but as long as you do it slowly enough you will learn a lot. You will get
better as your "slow and perfect" time improves and your brain adapts. You
will improve much faster than in "fast and sloppy" mode which trains your
brain to not mind the ugliness.

~~~
dave_sid
I'd have to disagree there. No matter how good a developer you are, if you're
in a rush, you're not going to output the same quality. There's always going
to thousands of decisions in a programmers head where they could take time to
make something more efficient. If time is the top priority, then well designed
code isn't.

And for what it's worth, I don't think that code needs to be perfect. If
you're testing out an idea, your code may just need to be good enough to test
the idea. Then when the idea has been validated, you can worry about
perfecting the code.

~~~
bjourne
Well I disagree with you. :) Being in a rush almost by definition means that
you have to perform faster than you're capable of. But the point is that you
can push your limit on what "being in a rush" means by practicing. A few hours
might be impossibly rushed for one programmer while it is ample time for
another. Furthermore the more you train yourself on writing good code, the
less of a speed advantage it is to write bad code.

------
bennyg
I absolutely think about clean and quality code. The easiest way to do it, in
my opinion, is to write the most customizable and modular code from the
beginning. Because, inevitably, mid-project you'll want to use something
you've already written with a slight twist or use a class somewhere else where
you didn't know you'd need it - but now you can just drop that sucker in and
spend no time making a totally new class for something so it doesn't break
something you've made earlier. It really doesn't take too much extra time to
do this either, especially if you're constantly thinking like that - future
proofing your code for the unknowable and very changeable design requirements.
Loosely sticking to MVC has greatly improved my app coding. Here's how I set
it up:

* Controllers

* Data Objects

* Utility UI functions (making shadows, or anything that can happen anywhere)

* Data Managers (sometimes Singletons)

* Web Services

If I start with this model in my head, the code is self organizing because I'm
not writing data parsing in a controller because I KNOW with 99% certainty
that I'm going to parse something later in another controller or something
even higher is going to handle that data at some point in the future.

This kind of abstraction is how I do it currently, and I've only gotten here
through experience, and I'm sure that I'll find even better ways as I continue
to code into the future (I'm already thinking of base iOS project templates
that contain that structure already).

~~~
xackpot
Awesome. This is something I try to follow. I use the same concepts that you
have listed here. Conforming to the MVC pattern makes it easier to develop.
Since my team is using Parse, we don't have to worry about Data Objects and
Web Services, but we do have Controllers, Data Managers and Utility functions
in our app.

I checked out your github account for the HN app and it is a beautifully
written one. Great work.

~~~
bennyg
Thanks man, I've been refactoring and learning as I go on that one as well. It
used to be not-so-nice not too long ago haha.

------
blueblob
I am currently a graduate student and I can say that I, without a doubt, worry
about the quality of my code. I worry about this because I have to rely on
other student-written code that often does not perform as advertised. I
refactor both my code, and code written by other students very frequently even
though the code is really only "proof of concept" because I need to refactor
other people's code to get mine to work. I cannot stress enough how important
it is to refactor (and document) code.

~~~
xackpot
Working across teams and developers is one more reason to worry about the
quality of the code. Sometimes the code written in not as per our vision and
we end up refactoring it. But again, all these things are possible if there is
some time at hand. For startup like ours, we are continually iterating and
adding code proof points. This makes it difficult to maintain the quality of
the code how much ever we want to. I like your idea of documenting, though
again, it's time consuming. We do it with helpful comments, but I think it is
not enough.

------
dmlorenzetti
The main thing I do is try to implement very thorough unit tests. I find that
the act of writing the tests helps me think through the interface to the code,
which in turn helps me isolate the caller from implementation details. It also
helps make sure an individual module doesn't try to do too much or too
little-- the unit test will start to feel "baggy" in the first case, and will
look pretty thin in the other.

If you haven't read "Working Effectively with Legacy Code" by Michael
Feathers, I would strongly recommend it. The book officially is about how you
get existing code under test, but its techniques orient around moving the code
to a better organization.

The book "Large Scale C++ Software Design" by Lakos lists some actual,
computable, metrics for assessing how interconnected your code is (and hence
how hard to change). Never having used those metrics, I can't recommend them
one way or the other; I just know they exist.

~~~
xackpot
Thanks for the suggestions. I checked out the book by Michael Feathers and it
definitely looks helpful. I have embarrassingly low number of unit tests which
I need to take care of and introduce more rigorous testing into our code.

------
ragatskynet
Code quality means a lot in my opinion. A nicely structured and organized code
not only shows its programmers' expert skills but makes it easier (and
faster!) to modify or extend the present functionalities. Also if you care
about code quality it really helps you to develop your skills.

As others stated it is needed to start a project in a way that you care about
the quality. Even when there have not been a single line written. Also being
agile also means that you refactor and redesign from time to time when it is
needed.

I always check my code after implementing a functionality. If it is needed, I
refactor my code. Also there are numerous tools to check code quality (e.g.
Sonar). A very good approach is to have code reviews as well if you can.

There is a very nice book in this topic which the others have not mentioned,
but if you are interested I advise to read it: Clean Code by Robert C. Martin.

------
Diamons
If I'm working on a homework assignment, yes I go over it a few times and
clean it up.

If I'm working on our startup, I often google / copy+paste, whatever gets the
job done. If I find myself struggling to make it work how I want or I'm
spending more time fighting with the code than I'd prefer, I go back and
refactor the code.

~~~
xackpot
Yeah, google comes to the rescue more often than not, but I also believe that
such code that we put in leads to hacks which may bloat up as messy in the
grand scheme of design/structure. For me a good code is something that has
proper structure, good mechanism for communication between related modules and
maybe, free from hacks :)

------
andrewcooke
it's a constant battle. sometimes you have to compromise, sometimes you can
claw some time back to fix up previous compromises.

finding the right balance pretty much defines what being a good professional
software engineer is, imho.

------
meerita
I do first code. Then refactor. I cannot do clean, perfect code since there's
always pressure from management. i try to refactor once I have everything
working.

