Search Results

Search found 11 results on 1 pages for 'andrewstopford'.

Page 1/1 | 1 

• TDD and your emerging design

  - by andrewstopford

  I was at DevWeek last week, it was a great week and I got a chance to speak with some of my geek heroes (Jeff Richter is a walking, talking CLR). One of the folks I most enjoyed listening to was ThoughtWorker Neal Ford who gave a session on emergeant design in TDD. Something struck me about the RGR cycle in TDD in that design could either be missed or misplaced if the refactor phase is never carried out and after the inital green phase the design is considered done. In TDD the emergant design that evolves as part of the cycle is key to the approach.  Neal talked about using cyclometric complexity as a measure of your emerging design but other considerations would surely include SOLID and DRY during the cycles. As you refactor to these kinds of design principles your design evolves.

  Read the article

• Working with Legacy code

  - by andrewstopford

  I'm going to start a series on working with legacy code based on some of things I have learnt over the years. First I define my terms for 'legacy', I define legacy as (as someone on twitter called it) not brownfield but blackfield. Brownfield can be code you did yesterday, last week or last month etc. Blackfield tends to be a great older (think years old) and worked on by a great deal many people. Sure brownfield can also be legacy code but often has far less smells and technical debt, due to it's age the problems are often far worse and far harder to treat.  I'm not sure how many posts I'll write for the series or how long it will run for but I'll add them as and when they occur to me. Finally if you are working with the kind of codebase I describe then Michael Feathers 'Working with Legacy code' is a great resource.

  Read the article

• Working with Legacy code #1 : Draw up a plan.

  - by andrewstopford

  Blackfield applications are a minefield, reaking of smells and awash with technical debt. The codebase is a living hell. Your first plan of attack is a plan. Your boss (be that you, your manager, your client or whoever) needs to understand what you are trying to achieve and in what time. Your team needs to know what the plan of attack will be and where. Start with the greatest pain points, what are the biggest areas of technical debt, what takes the most time to work with\change and where are the areas with the higest number of defects. Work out what classes\functions are mud balls and where all the hard dependencies are. In working out the pain points you will begin to understand structure (or lack of) and where the fundmentals are. If know one in the team knows an area then profile it, understand what lengths the code is going to.  When your done drawing up the list then work out what the common problems are, is the code hard tied to the database, file system or some other hard dependency. Is the code repeating it's self in structure\form over and over etc. From the list work out what are the areas with the biggest number of problems and make those your starting point. Now you have a plan of what needs to change and where then you can work out how it fits into your development plan. Manage your plan, put it into a defect tracker, work item tracker or use notepad or excel etc. Mark off the items on your plan as and when you have attacked them, if you find more items then get them on your plan, keep the movement going and slowly the codebase will become better and better.

  Read the article

• The dislikes of TDD

  - by andrewstopford

  I enjoy debates about TDD and Brian Harrys blog post is no exception. Brian sounds out what he likes and dislikes about TDD and it's the dislikes I'll focus on. The idea of having unit tests that cover virtually every line of code that I’ve written that I have to refactor every time I refactor my code makes me shudder.  Doing this way makes me take nearly twice as long as it would otherwise take and I don’t feel like I get sufficient benefits from it. Refactoring your tests to match your refactored code sounds like the tests are suffering. Too many hard dependencies with no SOLID concerns are a sure fire reason you would do this. Maybe at the start of a TDD cycle you would need to do this as your design evolves and you remove these dependencies but this should quickly be resolved as you refactor. If you find your self still doing it then stop and look back at your design. Don’t get me wrong, I’m a big fan of unit tests.  I just prefer to write them after the code has stopped shaking a bit.  In fact most of my early testing is “manual”.  Either I write a small UI on top of my service that allows me to plug in values and try it or write some quick API tests that I throw away as soon as I have validated them. The problem with this is that a UI can make assumptions on your code that then just unit test around and very quickly the design becomes bad and you technical debt sweeps in. If you want to blackbox test your code with a UI then do so after your TDD cycles not before. This is probably by biggest issue with a literal TDD interpretation.  TDD says you never write a line of code without a failing test to show you need it.  I find it leads developers down a dangerous path.  Without any help from a methodology, I have met way too many developers in my life that “back into a solution”.  By this, I mean they write something, it mostly works and they discover a new requirement so they tack it on, and another and another and when they are done, they’ve got a monstrosity of special cases each designed to handle one specific scenario.  There’s way more code than there should be and it’s way too complicated to understand. I believe in finding general solutions to problems from which all the special cases naturally derive rather than building a solution of special cases.  In my mind, to do this, you have to start by conceptualizing and coding the framework of the general algorithm.  For me, that’s a relatively monolithic exercise. TDD is an development pratice not a methodology, the danger is that the solution becomes a mass of different things that violate DRY. TDD won't solve these problems, only good communication and practices like pairing will help. Above all else an assumption that TDD replaces a methodology is a mistake, combine it with what ever works for your team\business but only good communication will help. A good naming scheme\structure for folders, files and tests can help you and your team isolate what tests are for what.

  Read the article

• Gallio and VS2010

  - by andrewstopford

  With the launch of VS2010 this week it seems like a good time to talk about some of the work that has been going on with Gallio to integrate with VS2010. This work will be a feature of the next release, no beta yet but you are welcome to try the nightly builds (all normal risks apply etc). Just like VS08 you can use the VS Test Runner to run Gallio tests (such as MbUnit) in the same way you can MSTest. With Gallio installed the Test View window shows a Gallio (in this case MbUnit) test loaded (note the icon). If I go ahead and run this test I can see it working in the Test Results window. In VS2010 you can collect additonal data that a test can include (system data, intellitrace data etc). If I set VS to collect system data and run the test I can click the 'Test run completed' link and see that it is included. If I also right click in the Test Results window I can select "View Test Results Details" and a Gallio test results window will load up. Note that Gallio treats the collector data as attachments so you can go ahead and view the attachment data right from the report.

  Read the article

• VS20 next, test frameworks and what you want to see?

  - by andrewstopford

  VS2010 is right around the corner and thoughts now turn to the next version of VS. One thing I am seeking dear reader is how in the next version you would like to improve how VS interacts with test frameworks and tools, could that be made better and what would you most want to see (better reporting, better interaction with TFS, better templating support for test frameworks etc)?

  Read the article

• Working with Legacy code #4 : Remove the hard dependencies

  - by andrewstopford

  During your refactoring cycle you should be seeking out the hard dependencies that the code may have, examples of these can include. File System Database Network (HTTP) Application Server (Crystal) Classes that service these kind (or code that can be abstracted to a class) of these kind of dependencies should be wrapped in an interface for easier mocking. If you team starts refering to the interface version of these classes the hard dependency will over time work it's self free.

  Read the article

• Working with Legacy code #5: The blackhole.

  - by andrewstopford

  Someone creates a class or series of classes for something, the classes are big in size with large complicated methods. The effort is a sea of technical debt for the entire team but in the thick of the daily chaos it is lost. With out the coder talking to the team, with no team code policy and no code reviews (and action points) it remains. Pretty soon the team forget about that code. A few weeks\months\years goes by, some of the team may have left, some may remain but business asks for the team to add to that code. The team is now looking at a black hole, no one knows how it works, what it does, what it is for, it is a smelly hell hole and the deadline is fast approaching. The team now tries to change the code, with no approach at unit tests or refactoring in fear of breaking the black hole the team do just that and the business have just lost money. If you are faced with a black hole you need to look back over my series, even a black hole in what might seem like a clean unit tested application. Don't be fooled into thinking that legacy code does not apply to your code base.  The next stage is don't let blackholes in your codebase. Effective code reviews, team communication and good overal team coding policies will really help. Even if you are faced with a deadline do not let them appear, stop, take stock, what can be done and who can help. If you allow them through they will grow and grow and grow and the technical debt will hit you like a tidal wave soon enough,.  

  Read the article

• Gallio and VS2010 code coverage

  - by andrewstopford

  Scott mentioned on twitter a great post on using VS2010 code coverage with ASP.NET unit tests with the following comment. So I figured I would work up a quick post on using Gallio with the code coverage features (and thus MbUnit, NUnit etc).  Using Gallio with the VS2010 code coverage features is exactly the same as you would use MSTest. Just enable the code coverage collector.   Select the assembly you want to profile (double click the collector to do this) Run your test   Right Click and select code coverage.  

  Read the article

• Working with Legacy code #3 : Build a safety net.

  - by andrewstopford

  The first port of call in changing legacy code is a safety net, without one your fingers will get burnt. Make your safety net a high level functional test over the major areas of the application. Automate the test, plug it into your CI builds and run it every night. The test should act as a final fail safe as you work.

  Read the article

• The year ahead, 2011.

  - by andrewstopford

  When I look back at last years look at 2010 my blogging rate has not changed much (I suspect this is largely down to using Twitter a lot) but my interests this year have developed a lot further. My view on 2010 would be that Microsoft would commit more to OSS, while I wanted to see more hires from that audience and more projects on Outercurve foundation instead there has been support for JQuery and Gems (aka NuGet). I would love to see more from Microsoft on the OSS front in 2011, Outercurve could become like the Apache foundation with enough support. Staying on the Microsoft front I predict that 2011 will bring the following. C# 5.0 will go RTM (still no MOP though) The next release of VS will go alpha or early beta MS MVC 4.0 (I think by Mix time) and maybe this release will get a command line. I also suspect that Microsoft will want to target the tablet market with WP7 in 2011 (Mix 2011 maybe...). I also predict the following Java will fork with Apache\Google. Oracle will then take them to court and the whole thing will boil right through 2011 (Java have had enough court cases, come on guys). Java and the JVM will sadly not move forward at all in 2011. Android will cause Apple a serious headache, both the smartphone and tablet market will see figures cut from Apple share. By the end of 2011 the current 70% apple market share will be 40-50%. As the features, performance and price of Android devices gets ever better Apple will be left out in the open. Lastly after 7 years I intend to move this blog away from weblogs. In 2011 I will be exploring Java, Ruby\Rails and Android and such subjects don't make sense to talk about it here. See you in 2011.

  Read the article

1