Comments for Eric Gunnerson's Compendiumhttps://blogs.msdn.microsoft.com/ericgu
Wed, 17 Feb 2016 05:52:25 +0000hourly1Comment on You suck at TDD #3 – On Design sensitivity and improvement by Ultimatehttps://blogs.msdn.microsoft.com/ericgu/2016/02/11/you-suck-at-tdd-3-on-design-sensitivity-and-improvement/#comment-88211
Wed, 17 Feb 2016 05:52:25 +0000https://blogs.msdn.microsoft.com/ericgu/2016/02/11/you-suck-at-tdd-3-on-design-sensitivity-and-improvement/#comment-88211How do I know whether there is someone with 1OI or 0OI. I've 3OI about that information.
]]>Comment on You suck at TDD #3 – On Design sensitivity and improvement by Pavelhttps://blogs.msdn.microsoft.com/ericgu/2016/02/11/you-suck-at-tdd-3-on-design-sensitivity-and-improvement/#comment-88221
Mon, 15 Feb 2016 11:33:14 +0000https://blogs.msdn.microsoft.com/ericgu/2016/02/11/you-suck-at-tdd-3-on-design-sensitivity-and-improvement/#comment-88221"Ignorance sucks!"

Nice post Eric. In the practice refactoring skills/pair with someone section – I would suggest looking into code retreat format. I found it to be very efficient way to introduce people to new concepts (moving them to 1OI I guess) with hands on practice.

]]>Comment on You suck at TDD #3 – On Design sensitivity and improvement by Mihaihttps://blogs.msdn.microsoft.com/ericgu/2016/02/11/you-suck-at-tdd-3-on-design-sensitivity-and-improvement/#comment-88231
Mon, 15 Feb 2016 02:18:13 +0000https://blogs.msdn.microsoft.com/ericgu/2016/02/11/you-suck-at-tdd-3-on-design-sensitivity-and-improvement/#comment-88231You could consider linking to sourcemaking.com for Code Smells and Refactoring.

I've used it on a number of teams, and it helps with awareness.

]]>Comment on You suck at TDD #3 – On Design sensitivity and improvement by Ianhttps://blogs.msdn.microsoft.com/ericgu/2016/02/11/you-suck-at-tdd-3-on-design-sensitivity-and-improvement/#comment-88241
Sun, 14 Feb 2016 03:39:39 +0000https://blogs.msdn.microsoft.com/ericgu/2016/02/11/you-suck-at-tdd-3-on-design-sensitivity-and-improvement/#comment-88241I tried to encapsulate something along these lines in a blog ages ago, but with more rant. It was in response to a round of interviews I'd been conducting which initially made be despair at the quality of candidates available and then reflect to on my development over the years.

There have been numerous points in my career where I've felt almost omnipotent, only to realise as my skill increased that really I just didn't know what I didn't yet know.

I still have the same problem with candidates today. What I consider a senior developer vs what the candidates senior developers consider to be a senior developer varies significantly.

Of course, I still don't know what I don't know, so I imagine my idea of what's important will be refined further, but I can't be paralysed into inaction and have to make a judgement call based on what I do know too.

What I can do is acknowledge that this is a process developers go through and perhaps, if they manage not to really piss me off during the interview, I can open their eyes a little.

If you want a visual analogy. You could imagine the path to developer perfection as being a ladder, with developers scattered along the length from top to bottom depending on their current ability. The problem is developers can only look down, so as they progress, their perspective is of being at the top of an ever lengthening ladder rather than advancing along the length of an already long one.

This is why I didn't write the blog post in the first place, I can just about articulate the problem but couldn't find a solution to end on. Acknowledge what you don't know you don't know is an obvious but nebulous one but I wanted more.

There is obviously a big correlation between P&A and SOLID, but I don't think it's quite as simple as you suggested. P&A is dependency inversion, but I think it feels more strongly about where the line is drawn between the application code and the dependency. You can write a file system abstraction that is SOLID – I've written those myself – and I think drawing the line at the right point is really the important part of P/A. This is especially true when you are trying to improve the design of existing code, as the putting the abstraction close to the dependency is generally the cheaper choice. There is also the significant difference between a principle and a pattern; I think that "consider P/A/S when you are dealing with dependencies" is more likely to lead to better code than "remember SOLID when you are dealing with dependencies".

While I like dependency inversion the way that P&A does it, I am not a big fan of SOLID; I've found that codebases that follow it closely end up hard to understand. I've found that the world gets simpler if you focus on whole values and no mocks (aka "as few mocks as possible"). Brian Geihsler does a good job talking about it in this post (make sure to read the update and all of the links in it, including Arlo Belshee's post about no mocks) – qualityisspeed.blogspot.com/…/why-i-dont-teach-solid.html. My experience is that the approach that Brian and Arlo talk about leads to code that is simpler to read and simpler to test. My experience is also that very few people see primitive obsession and what it costs, and some will even advocate against whole values because the resulting classes are "too small".

]]>Comment on You suck at TDD #4 – External dependencies by Stevenhttps://blogs.msdn.microsoft.com/ericgu/2016/01/26/you-suck-at-tdd-4-external-dependencies/#comment-88261
Sat, 30 Jan 2016 23:27:51 +0000https://blogs.msdn.microsoft.com/ericgu/2016/01/26/you-suck-at-tdd-4-external-dependencies/#comment-88261This idea is actually much older than Alistair. The SOLID principles describe exactly that, especially the Dependency Inversion principle explains that the 'client owns the abstraction'. So Alistair's ports and adapters are nothing more than a correct application of the SOLID principles.
]]>Comment on Response to comments : You suck at TDD #3–Design sensitivity and improvement by Eric Gunnersonhttps://blogs.msdn.microsoft.com/ericgu/2015/12/18/response-to-comments-you-suck-at-tdd-3design-sensitivity-and-improvement/#comment-88271
Tue, 22 Dec 2015 11:59:01 +0000https://blogs.msdn.microsoft.com/ericgu/2015/12/18/response-to-comments-you-suck-at-tdd-3design-sensitivity-and-improvement/#comment-88271Anders,

Thanks for your comments. I started to write a response but it got away from me, so I did a separate post instead…

]]>Comment on Response to comments : You suck at TDD #3–Design sensitivity and improvement by Ianhttps://blogs.msdn.microsoft.com/ericgu/2015/12/18/response-to-comments-you-suck-at-tdd-3design-sensitivity-and-improvement/#comment-88281
Tue, 22 Dec 2015 01:59:40 +0000https://blogs.msdn.microsoft.com/ericgu/2015/12/18/response-to-comments-you-suck-at-tdd-3design-sensitivity-and-improvement/#comment-88281That makes sense. Looking forward to the next one 🙂
]]>Comment on Response to comments : You suck at TDD #3–Design sensitivity and improvement by Andershttps://blogs.msdn.microsoft.com/ericgu/2015/12/18/response-to-comments-you-suck-at-tdd-3design-sensitivity-and-improvement/#comment-88291
Mon, 21 Dec 2015 22:11:24 +0000https://blogs.msdn.microsoft.com/ericgu/2015/12/18/response-to-comments-you-suck-at-tdd-3design-sensitivity-and-improvement/#comment-88291Wouldn't TDD suggest that you should write a test before you refactor? I understand that it is not possible to unit test the code in the shape that it is however it should be possible to create an integration test (however large that might be) before refactoring.

I think we have very different approaches to how to handle legacy code. Adding interfaces to random classes, and changing the constructor parameters can have far reaching consequnces in the code base which are not easy to forsee. To create an interface for the legacy service I would have written a thin wrapper class that implements the interface that contain the legacy part. Instead of adding a new constructor I would have added a virtual factory method for the new interface. In the test I can then simply create an inherited version of the class with the factory method overriden. By doing this the class becomes testable without changing any of the class or method signatures.