Command line was needed a refactor and is on a good track. The problem of taking too long was mostly based on a Joel Spolsky recommendation.
Do you know his famous 12 steps to write better software? The step that was done wrong in this refactor was step 5: Do you fix bugs before writing new code? The best answer should be yes. But instead doing this, I've target to have "the basic infrastructure" done and after this doing bug fixing. By taking this approach I've face bugs in a lot of areas back and forth being low rewarding task. The good part is that the infrastructure is there. I mean by this that command line goes to an ambitious command line that at least have a lot of ideas started.
Why fixing later bugs will go so big delays? My reason is: it breaks your focus and make your experience of programming the features grumpy. I've shown a screenshot in the last command line update that shows buttons corresponding to parameters. This is great but firstly the coloring was wrong, the Point3D type was hardcoded. Clicking on any button lead to crash. Resetting the Command Line action after pressing any letter. Because of this the browser refresh all the times, etc. This makes in short that almost anything you clicked on can lead to a crash. So fixes were here and there but still the code is unstable.
I will try tomorrow to take this piece of code and bug fix it. If I found all bugs and fix them, I build on top of it. If I will not be able to go on command line in detail, I will try to fix as much bugs as possible at the end of iteration. I think that users will care much less of a such powerful command line that can make Naro to crash at any moment than a fewer commands that when you call them, they work.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment