Do you worry about the quality of code?

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.

When I look back at the code, I can'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.

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 'good' code, but what do you do to ensure that it is easily re-factorable?

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.

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.

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

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.