51–60 of 85 posts
http://michaelfeathers.typepad.com/michael_feathers_blog/201...
I think that this sort of repository analysis is going to be standard practice within the next couple of years.
I think it is a mistake to think of coupling caused by TDD to be a false positive. What this outlines really is that TDD will force you to edit two files instead of one for many changes. This is a clear indication of how TDD will slow you down.
The solution there was for future languages to combine the two. Maybe we'll see a future language combine unit tests and source into the same file.
Heh, maybe such a language would refuse to compile if public functions did not have an associated test.
Earlier quoted context omitted.
Basically bugfixes would be localized to relevant files, but features would spread across files. The grandparent's making an important point in that you can't design a system such that all possible changes you might want to make are localized to one area of the code . Engineering is about trade-offs: if you rigorously separate view from logic from database, you make it harder to add features that must touch all three…
> if you rigorously separate view from logic from database, you make it harder to add features that must touch all three I've found the exact opposite of this to be true.
Earlier quoted context omitted.
> if you rigorously separate view from logic from database, you make it harder to add features that must touch all three I've found the exact opposite of this to be true.
I agree! Perhaps the (parent) meant something different, I wonder?
Systems like PHP + "SELECT * FROM database_table" or the MEAN stack, where you use the same data format for both backend storage and UI and intermingle logic with templates, are significantly faster for getting something workable on the screen that users can try out. I've done a complete MVP in 4 days with PHP; a roughly equivalent app in Django (which has some minimal model/view/database separation) took about 2-3 weeks. The fastest I could launch a feature in Google Search that touched both UI and indexing was roughly 6 months; as you'd expect, that has a very rigorous separation of front and back-ends.
Now, the PHP solution will quickly become unmaintainable - with the aforementioned 4 day project, I no longer wanted to touch the code after about 3 weeks. But this doesn't matter - it's 10 years later and the software is still serving users, and I long since moved on to bigger and better things. And that's my general point: what's "good" code is context-sensitive. Everybody wants to work on nicely-factored code where you can understand everything, but there is no business to pay you unless you first make something that people want, and oftentimes that takes hundreds of iterations (including many fresh starts where you throw everything away and rebuild from scratch) that are invisible to anyone collecting a paycheck.
I think it is a mistake to think of coupling caused by TDD to be a false positive. What this outlines really is that TDD will force you to edit two files instead of one for many changes. This is a clear indication of how TDD will slow you down.
Earlier quoted context omitted.
Instead of writing tests in a separate file, why not express the same logic in the form of types in the lines directly above the code which implements that logic? This has the added benefit of making your code self-documenting and giving rise to powerful tools such as type-guided implementation inference and search.
What type system do you have in mind? Haskell?
For reference, given some variables, a Markov network is a parsimonious way to express arbitrary covariance matrices in terms of individual interactions between groups of variables (in this case, pairs of variables). Their approach looks very similar to estimating the Maximum Likelihood or MAP graph.