This year I found some time to take part in IntelliJ plugin contest. I started writing code only two weeks before the end of the contest, though. So the most reasonable prize I could hope for from the very beginning was “I plugged in to IntelliJ” t-shirt which all the participants get. The reason I chose to write html export is that I didn’t like in the default IDEA export. It lacks annotations and static fields highlighting and have problems with multiline java-docs. Javascript-based highlighters that I tried weren’t very good at highlighting static fields and methods either. Therefore, I rolled up plugin for html export. (There is also Copy as HTML plugin which does mostly the same thing. It might be a good idea to update it to IntelliJ 8 API but after looking at the code I though better off it. Sorry. I’m a bit tired of making sense of and changing code I didn’t write at work.)
All in all I really enjoyed the process of plugin-writing. I don’t think of it as being “finished” and plan to add more features. Here are some things I learned while doing it.
TDD doesn’t replace thinking beforehand
I admit I’ve been and probably still is over-enthusiastic about unit testing and TDD in particular. In my understanding the idea behind doing TDD and not thinking through the whole problem is that you cannot possibly know all the obstacles you’re going to encounter and, therefore, it might be more practical to write some code and learn from this experience. Sometimes this approach works very well, sometimes doesn’t. The only rule that holds true most of the time is that there are no silver bullets and and it’s a judgement call to decide whether some technique can be applied or not (well.. unless you do the same thing all the time). As I found it might be more effective to write some code (I don’t say write “spike code”) and run system in live environment to get broader view of problem, rather than start with unit tests right away.
There is no “right” scope for unit tests
It was after reading xUnit Patterns and Working Effectively with Legacy Code books that I became keen on writing small-scoped tests which wouldn’t interact with other classes or even worse with filesystem of database. These are actually the qualities that make them “unit” tests. It seems to me now unit tests are not the best choice in every case (I mean even when it’s possible to write meaningful unit tests). Sometimes it’s better to write larger-scoped system-level tests. The reason is that unit tests are coupled to interfaces of classes they are written for and, should you want to make big changes in implementation (throwing away or changing a lot of classes along the way, for example), unit tests will be of little help. Here is a pretty good article by Kent Beck on this topic.
“find” and “grep” are faster than IDE search
I’ve been aware for quite a while that I could use something like
find . -name * | xargs grep “some text”
I used it occasionally on remote machines but I’ve never seriously thought of using it on desktop. After all why would I want to with modern IDEs and file managers? The answer is because “find” with “grep” is way faster. I don’t have exact numbers but on projects with large code base textual search in IntelliJ, Eclipse or Krusader may take ten seconds or more. On the same code bases grep does the same thing in just seconds
Checklists are great
They really help to make sure you don’t forget anything. Although the idea of using checklists is not new, I’ve never seen a developer sitting next to me who would use a checklist. I wouldn’t use it either if not for Igor Stepin who mentioned checklists in some discussion.
To make it more concrete here is a snippet from htmlexport “release checklist”.
- fix all todos
- review code (optional)
- run DSM
- run Intellij code review
- make sure all tests pass
- test plugin manually with java, xml
- update plugin xml
- run plugin build from IntelliJ
…
As an afterthought, refactoring descriptions are in fact checklists, but I admit I use built-in IDE refactorings or refactor without any guide.
