A notebook for software craftsmen and engineers.
There's something very cool going on here. While practicing tool-supported refactorings, I find that it's a good challenge and useful skill to do more complex refactorings as a sequence tool-supported refactorings (and some transformations), while keeping the code green. An idea of transformations could take this a lot further, especially if tools start picking this up. Very exciting.On another note: Speaking of word wrap: Would you care to "wrap" (that is: format) the source code in the blogpost?
Maybe we can dream of a tool that will write and transform the code as we write the tests. And tomorrow, developers will be testers only. This sound a bit like logical programming.
That's very interesting.It might be worth trying to use a structurally simple language (Lisp?) and create a tool for automatically generating the code from the tests: Given the code and a failing test, search the space of all possible transformations (using some heuristics to limit the space) and check which of them make the test pass. If that can be done, then the next step would be to have multiple failing tests and search all permutations of the order in which the tests are made to pass. Maybe also duplication removal could somehow be automated, though the developer is needed to at least provide the names of the new methods.This sounds like an EXPTIME decision problem, but maybe with some heuristics and help from the developer it could produce something interesting, perhaps even something useful. Creating an AI which can pass a code kata would be a breakthrough.P.S. Could you format those code samples properly with line breaks and indenting, so that they could be read easier without first having to paste them in an IDE for reformatting?
As it has been said, you can't automate something you don't understand. I suppose that if you understand something then you have a possibility of automating it.We are still far from fully understanding programming. Let's hope that these transformations are one step towards understanding programming better.
I'm not a TDD user, but I find it remarkable how similar this sounds to evolution - moving in small, independently viable steps from simple to complex behavior, judged fit or unfit in accordance to gradually changing environmental conditions.
I love the article, and I think it provides a great way of thinking about coding. I especially enjoy how it provides a code counterpart to refactoring. I did have one question though:"... whether there is another test we could pose that could be passed with a higher priority transformation."If you have to think about the effect on the code for a given test, doesn't that break the abstraction of your interface (this is based on my limited understanding of TDD)? That is, you are no longer just writing tests based on what you want your code to do, but have to factor in how the code will do it.Thanks for the interesting new ideas!