4 ms·

Any idea how to do code review, when you are solo-founder?

deleted 8y ago
[deleted]
Sourya 8y ago
When I was the only guy in my team writing code, I found it helpful to put a bit of processes - like having a threshold of test coverage, and running some kind of analysis (flake-8, for example) on my codebase. Another thing I did was letting one of my friends look at a random piece of code in my codebase. He would suggest changes, but what helped more was that I wrote code more consciously than I would if I did it all alone.
arethuza 8y ago
You could switch to working on some other component and then come back after a few days - I find that length of time often makes me fairly critical of my own code!
- pplonski86 8y ago
  Yes, that's the approach that I'm taking right now. I'm a little afraid that with this method I'm not improving my programming skills.
- SharmaKushagra 8y ago
  Unrelated to the original topic but whenever I can, I'd try to work on 3-4 distinct work items in parallel in a sprint... typically doing a context switch once in a day. I've found that it really helps in letting ideas and solutions brew up and mature over time against trying to 'close' a single item quickly. the context switch can be quite useful if you have hit a roadblock or even just to break monotony.
dolftax 8y ago
You could try posting the snippets you need peer reviewed here on code review stack exchange - https://codereview.stackexchange.com https://codereview.stackexchange.com I recently came across https://www.pullrequest.com https://www.pullrequest.com and have heard good things about them.
js2 8y ago
Go through the motions of reviewing your own code separately from writing it. IOW, have a code review tool such as Github or Gerrit and create a PR or change request. Then review your code similar to how you might proof read a paper. I find just the change of mindset and looking at the code in a different context (the diffs in a browser window instead of the code in your editor) helps me to catch mistakes. I usually do this for changes before I have someone else review them anyway. Of course ideally someone else could review the change but if you don’t have someone you don’t have someone. The main limitation here is that while this should help you with bugs, it’s not good for catching things which aren’t idiomatic or having someone point out a better way to do something. But it’s better than nothing.
nradov 8y ago
Add a good static analysis tool such as SonarQube to your continuous integration pipeline. It isn't really a substitute for human code reviews but it can quickly catch a lot of common problems.

deleted 8y ago

[deleted]

When I was the only guy in my team writing code, I found it helpful to put a bit of processes - like having a threshold of test coverage, and running some kind of analysis (flake-8, for example) on my codebase. Another thing I did was letting one of my friends look at a random piece of code in my codebase. He would suggest changes, but what helped more was that I wrote code more consciously than I would if I did it all alone.

arethuza 8y ago

You could switch to working on some other component and then come back after a few days - I find that length of time often makes me fairly critical of my own code!

pplonski86 8y ago
Yes, that's the approach that I'm taking right now. I'm a little afraid that with this method I'm not improving my programming skills.
SharmaKushagra 8y ago
Unrelated to the original topic but whenever I can, I'd try to work on 3-4 distinct work items in parallel in a sprint... typically doing a context switch once in a day. I've found that it really helps in letting ideas and solutions brew up and mature over time against trying to 'close' a single item quickly. the context switch can be quite useful if you have hit a roadblock or even just to break monotony.

dolftax 8y ago

You could try posting the snippets you need peer reviewed here on code review stack exchange - https://codereview.stackexchange.com https://codereview.stackexchange.com I recently came across https://www.pullrequest.com https://www.pullrequest.com and have heard good things about them.

js2 8y ago

Go through the motions of reviewing your own code separately from writing it. IOW, have a code review tool such as Github or Gerrit and create a PR or change request. Then review your code similar to how you might proof read a paper. I find just the change of mindset and looking at the code in a different context (the diffs in a browser window instead of the code in your editor) helps me to catch mistakes. I usually do this for changes before I have someone else review them anyway. Of course ideally someone else could review the change but if you don’t have someone you don’t have someone. The main limitation here is that while this should help you with bugs, it’s not good for catching things which aren’t idiomatic or having someone point out a better way to do something. But it’s better than nothing.

nradov 8y ago

Add a good static analysis tool such as SonarQube to your continuous integration pipeline. It isn't really a substitute for human code reviews but it can quickly catch a lot of common problems.