“Premature optimization is the root of all evil” is quite a famous quote. In this regard do you / should you think about optimization while writing code; if yes, to what extent, and where do you draw the line. I understand this is a not a very clear question; but I hope answers with clear examples from experienced developers will absolve me of this problem.
If no, why not? Overall what is your process?
I find that if I don't refactor for readability as I go, then I likely won't have the opportunity to come back to it. Such is the life of a programmer in government work--only things that are on fire get attention.
I do. I don't necessarily do it while coding, but most of the time I do, if I'm thinking about it. I had a colleague who once said his motto is: "If you don't do it right the first time, when will you?"
I find that if I don't optimize right when I'm thinking about it, either I'm forced to later out of necessity, or I never do.
This same principle applies not only to optimization, but to configuration, small value lookups, etc.. Do I throw configuration into a file? In a config table in the database? Do I make my very small set of values of this thing a hard-coded set? An enum? A lookup table in the database? If I put these things in a database, do I make a front end for it to manage it, or just deal with direct DB management? Stuff like this. All are decision points that affect how much time one spends on a project.
Of course, sometimes, there's projects that just have to be done quickly. In that case, optimization and other decisions that would extend the implementation time go out the window in favor of getting the project complete. Then later, I make sure to go back and take care of those other things to make my left easier down the road. I view it as implementation and post-implementation duties. I try to have very few post-implementation duties as there's always another project looming on the horizon, limiting my time for such things.
It's never ending process. So first goto market with core stuff.And then do whatever you want to do man.But don't trouble your mother. :)
Yes!
In fact it is the best practice to think about how you can optimize your code before hand. I have been there where we write our code to just finish the sprint and then think will optimize it later...not gonna happen!
What works for me is I read all the rules listed in the Sonar Cube runner with example and wrote the code by keeping in midn that it needs to pass those rules.
Think about it, organize things, but your direction will change many times in how you code a project, so will how you organize that project. Just remember that and try and make things as clear as you can when you do any larger parts and you will be fine.
I tend to do a mix, thinking about how it will be and making blank functions and files for them, but that always tends to change at the end of the day and find myself changing function names all the time.
"Premature optimization is the root of all evil" - means optimization in sake of optimization, micro-optimization to save some ms, optimizing before you know what exactly must be done.
Before writing a code engineer should have a clear plan what must be done and how step by step. Your first "optimization" is done when you plan.
My process always starts from:
You can optimize only when there is real working production code to optimize, there is enough data, code to measure and slow parts, duplications, patterns recognized.
You always start from copy-paste, later when you will see a pattern, you would be able to change something. Even later small copy-paste is absolutely ok.
With my years of experience let me save you a lot of time - until you have at least simple specification - what results you want to see, it is pointless to write a code. You will be walking in the circle and changing, always changing your code. May be first realization won't be the best but it will work. You always can change later but only if you will walk out from the circle and that "later" will come.
I don't. My primary focus is correctness first, then readability.
Reasons why I don't micro-optimize:
KISS rule compliance required ! We've got time to thinking after producing in general.
Yes, in my current project I've started writing TODO'sat the top of the file of my code.
I'm a big believer in making something work and then start optimising it. But, that doesn't mean you can't start thinking about it. So I've written many TODO tasks in my files that are later reminders to optimise certain sections of code. These TODO's can include links to articles or github repos/snippets online etc.
I use TODO's instead of GIT issues or similar because generally the code is functional and therefore having a single issue for every single optimisation can become a big list. So instead I tend to just use a simpler git issue such as optimise code base/file xxx.
Not sure if any developers will agree with my method but I tend to find it works, as it's not intrusive of specific methods/functions but does provide a thought towards the future of the code base.
tl;dr Yes, I start thinking about optimisation while writing code.
Of course I think about optimization when writing code, sometimes you can make the things a little better and other times you put a TODO if the code is a big mess.
In my company we have a document called Refactor and we put things to make better, to decoupling, integrate third party libraries and so on.
I think it's important to make nice functionalities but it's so interesting to make things faster and optimization when times allow.
Gergely Polonkai
You have to believe in things that are not true. How else would they become?
Should you think of it? Absolutely. Should you do it? Now that's a hard question.
If you are an experienced developer, you will pretty much always have two solutions in your head: a quick and dirty, and a slow but clean. Most of the time you will yearn to use the latter, but have time only for the former.
At my company I do exactly this. Between last November and this May I wrote a lot of quick and dirty code. I was aware of such solutions (at least most of them) at the time of writing, so I added a small TODO comment to each of them. At the end of May most of our partners went on a long vacation. Business became slow, so after finishing some features I took one of my favourite scripts from my library called
fixmes-by-age, collected all the TODO comments from the code base, and started to get rid of them one by one ordered by impact.This is called a technical debt in my book (and all over the Interwebz). It's a luxury only programmers can allow themselves: imagine an architect not adding windows and doors to a house, just big holes because "we can optimise it next year by adding some wood and glass", or a doctor not closing a cut because "we can add those stitches later if the patient is OK".
Of course, you should avoid such situations to your best knowledge. For example, never ever write code that has obvious errors. Your code should always work, be it dirty or not. You can optimise for performance and edge cases later.