3

I've been working on a Python(Django)/JavaScript(AngularJS) based application for some time now.(I learnt all of these on the way, had previously been a Java only programmer)and have hit moments where the code was really unmanageable:

Single js script for the entire application, around two-dozen controllers, a dozen or so services and other components, all squashed into a single file.

I refactored that successfully, though, added a Grunt for minification and proper generation of final code for the application, shifted to bower for package management and in turn basically made my life easier.

Only if I had optimised things earlier in the development cycle, things would've been easier. So one thing that I've been wondering is what would be the right time to optimize my code? Weekly..Biweekly or just when and how do I assess code quality everyday, everytime I run a build.

There's probably a lot of tools out there for what I want to do, but what I want to know is where I should get started with this and what is the right way to optimize source code to use good programming standards, given that Python and JS are statically typed languages, with no particular coding standards enforced by default, as compared to Java, where I found it easier to write good code.

ratchet freak
  • 25,706
  • 2
  • 62
  • 97
Divij Sehgal
  • 143
  • 6
  • I already read it while searching for a similar question. My question is focused specifically at ways to optimise python and javascript code, and what would be good programming constructs in these languages? – Divij Sehgal Jul 11 '17 at 12:37
  • I'm unclear on this - is this a question about optimization or about avoiding technical debt? – Dan Pichelman Jul 11 '17 at 13:02
  • @DocBrown I re-read and you are right, this isn't a duplicate (not retracting close vote though because question looks unclear to me anyway) – gnat Jul 11 '17 at 14:51
  • 2
    Possible duplicate of [When to refactor](https://softwareengineering.stackexchange.com/questions/135845/when-to-refactor). @gnat: don't mind, I found one. – Doc Brown Jul 11 '17 at 15:02
  • Hey, @David Amo said, refractoring is what I actually meant. I'll edit this, just in case. – Divij Sehgal Jul 11 '17 at 15:45
  • @DivijSehgal: you did not mean "refractoring", that word does not exist. – Doc Brown Jul 11 '17 at 18:41
  • 1
    @DocBrown this is the internet, [of course](https://www.packtpub.com/mapt/book/hardware_and_creative/9781849685702/4/ch04lvl1sec05/refractoring) [it exists](https://www.safaribooksonline.com/library/view/agile-it-security/9781849685702/ch04s05.html). Don't make me find porn of it. :) – candied_orange Jul 11 '17 at 19:06
  • 3
    @DocBrown Well, we do have Code Reflection, CodeMirror and Code Lens, so... I guess we can keep going on Source Code Optics and add Code Refraction to it, too. – T. Sar Jul 11 '17 at 19:41
  • @T.Sar: I admit, in times of alternate facts its quite normal new words like "Covfefe" are invented, even if the inventor has no idea what that should mean ;-) – Doc Brown Jul 11 '17 at 21:07
  • This is turning out to be a fun conversation ;-) – Divij Sehgal Jul 12 '17 at 05:05
  • @DivijSehgal: I took the freedom and did what I should have done in the first place, corrected the spelling by myself. – Doc Brown Jul 12 '17 at 12:49
  • So I'd been spelling it wrong this whole time. Didn't realize that. – Divij Sehgal Jul 12 '17 at 15:56
  • One often hears "Red, Green, Refactor" when hearing about TDD. This translates into "Make it work, then make it tidy" which is pretty good advise. Besides that one has to consider that while software grows the underlying structure begins to rot as requirements change and thus the code slowly degrades until refactored again. Having a timer for this cleanup does not seem helpful to me. I think it's best to refactor when pain points start to form. When the code begins to hurt refactor as soon as possible. Just like I don't go to the doctor every week but only when something starts hurting me. – BlueWizard Jul 15 '17 at 22:32
  • Rightly said. In retrospect, that is what I did. – Divij Sehgal Jul 16 '17 at 16:40

2 Answers2

14

First of all, no Java does not have enforced coding standards. Anything you can make work in JavaScript I can also make work but look worse in Java. Working, in any language, doesn't ensure that it's well written. Need proof? See Code Golf.

Coding standards exist in you. Not the language. You're likely feeling this way because you've looked at enough Java code at this point you have an expectation of how Java code should look. You haven't developed that sense in your new languages yet.

Important to understand is that up-to-coding-standards is NOT the same as optimized. Optimized is about not wasting memory or CPU cycles. Up-to-coding-standards is about not wasting programmer time with hard to read code.

The best "tool" for this is a fellow programmer who can look at your code and tell you how easy it is to read. We call this a code review. If you're not doing it every time you write new code you are making things difficult for anyone that wants to work with the code later. Including you.

When to refactor?

One of the best times to refactor is just before adding a new feature.

Before you have an actual feature in mind you have no idea how to code is going to need to change. It's tempting to over generalize. Flexible code is good but unfortunately sometimes we attempt flexibility by imagining how it will change and accommodating imagined change. This creates needless code, needless abstraction, and needless indirection. The result isn't flexible.

However, you should expect that the code will need to change. The key is to minimize the assumptions you make about the future. Assumptions you must make should be isolated from each other. Make decisions in one place so that change can occur in one place.

When you have an actual feature in mind you can refactor to create a good place for this feature. For example, this is a good time for a class name with the suffix Impl to get a real name that differentiates it from the new implementation class you're about to add.

So, yes, right after a test passes is a time you could do a refactoring. Just be sure you know why you're refactoring.

candied_orange
  • 102,279
  • 24
  • 197
  • 315
  • "*Up-to-coding-standards is about not wasting programmer time with hard to read code.*": That's the ideal, and if the coding standard is good and has the neccessary flexibility it tends to be a reasonable match. Many are too old, too rigid, for very different environments, or are tragially misguided though. – Deduplicator Jul 11 '17 at 13:01
  • 3
    @Deduplicator which is why the best enforcer of coding standards isn't a tool or a piece of paper. It's a fellow coder that believes they might have to actually work with what you're writing some day. – candied_orange Jul 11 '17 at 14:21
  • 1
    Yes, pragmatic self-interest can do wonders. – Deduplicator Jul 11 '17 at 15:23
  • @CandiedOrange What I really meant about coding standards was that since I was pretty used to Java and (as you later mentioned) I have not become so comfortable working in Python/JS. And about the fellow programmer part: I am working among a couple infrastructure people who don't really write code, and I don't remember many of my friends working on a similar stack so I cannot ask them for suggestions. Best Case: I could put it up on github, but it is proprietary code, so I guess I am pretty much on my own.(funny)The fellow coder who'll work with my code is himself a network/infra person. – Divij Sehgal Jul 11 '17 at 15:33
  • @DivijSehgal Working without a fellow coder flat out sucks. I'll take a clueless newbie who hasn't even graduated yet to work with rather then code alone. The important thing is attitude. If the person looking at your code cares enough to ask you real questions about it you have a programmer doing a code review on your hands. That's what you need. Teach them Python if you have to. You just need someone who's trying to understand how it works. Seriously. – candied_orange Jul 11 '17 at 15:50
  • Exactly, till I find someone willing to work with, SO is my fellow programmer(see the pun :P) – Divij Sehgal Jul 11 '17 at 16:52
  • @DivijSehgal not that you aren't welcome here but have you heard of [Code Review](https://codereview.stackexchange.com/)? – candied_orange Jul 11 '17 at 16:57
  • Nope. Not before. Will check it out. – Divij Sehgal Jul 11 '17 at 17:18
  • @DivijSehgal: *"I am working among a couple infrastructure people who don't really write code, and I don't remember many of my friends working on a similar stack so I cannot ask them for suggestions."* try to attend [code retreats](http://coderetreat.org/) at your location to get in touch with other coders concerned about code quality... – Timothy Truckle Jul 11 '17 at 18:47
  • @DivijSehgal Have you actually asked any of of the infrastructure people? Being a programmer is far more an attitude about code than it is a title. You might also suggest that they hire someone else who is willing to code. – candied_orange Jul 11 '17 at 18:55
  • 1
    @TimothyTruckle As a matter of fact I am going to PyData Delhi next Saturday. – Divij Sehgal Jul 12 '17 at 05:02
  • @CandiedOrange I am an intern working in the IT department to develop an internal tool. They have a separate development wing, but it is at another branch. – Divij Sehgal Jul 12 '17 at 05:04
  • @DivijSehgal I'd still talk to the infrastructure team. If these guys intend to use this when you leave it'd be good if someone had their head around it anyway. Odds are one of them is willing to admit they know how to code. Don't ask them to do your work or actually code. Just ask them to look at what you're writing and give you feedback on how understandable the style is. If there is a development wing I'd at least pay a visit. Get to know them and seek out advice. You never know how it might pay off. – candied_orange Jul 12 '17 at 08:33
  • Valid point. But the way things are going, it seems nobody is going to work on it later on. If I get this done, good. If not, it might as well be scraped off later on(things are weird here). So I'm doing my best to write decent enough code that is not cryptic to the new person who comes along after me and looks at it and also writing documentation for the same. – Divij Sehgal Jul 12 '17 at 08:52
4

From your question, it appears your are confusing "refactored" with "optimised" and are actually referring to the former.

When should you refactor? That's easy, straight after (never before) your previously failing test "goes green". If you aren't using TDD though (and if not, why not?), then there's rarely an ideal time to safely refactor as you might break something in doing so. It becomes a case of "refactor at your own risk". The only real rule then is "the longer you leave it, the greater the chance of breaking things when you do refactor".

David Arno
  • 38,972
  • 9
  • 88
  • 121
  • 1
    As a matter of fact, that is what I meant. TDD is next on my list. I recently got my second internship(I wrote real code here, more like learning basic stuff on the previous one), where I learned python and js and more focus was on learning how things are working, than writing tests or refractoring code(tdd is a must now) and `at your own risk` is what had been going on for a while now, which is why I asked this question. This answer sums up what I had in mind about TDD. Thanks :) – Divij Sehgal Jul 11 '17 at 15:41
  • 1
    You are welcome. Also, I'm please to see you changed your mind and opted for @CandiedOrange's answer as the accepted one instead of this one. Mr Orange's answer is a better fit here than mine. I only added this as I wanted to emphasise the risks of refactoring without tests. – David Arno Jul 11 '17 at 15:55
  • 2
    Mr Orange? Sheesh. Even my father isn't Mr Orange :) Anyway, I completely agree with ever word here (even the punctuation) and find it so appropriate it inspired me to edit my answer. So why wouldn't I give you a +1? – candied_orange Jul 11 '17 at 16:10
  • 1
    I plus oned both your answers, not knowing I could only mark a single one as an accepted answer. Both your answers are written with a slightly different point of view and are both individually valid. – Divij Sehgal Jul 11 '17 at 16:55