次の方法で共有

Agility: Automation for Better Outcomes and Feedback

  • [アーティクル]

A bad habit of several developers has to do with entering in a long tunnel of coding for an application project, relegating a more or less acceptable executable for the last project stages. That has several risks:

 

  • Feedback from users and customers delayed, what can carry a poor customer satisfaction for who was going to receive the outcome. Business are in constant change so late delivery can bring outdated results
  • Urgent and/or expensive changes for the developing team, and in those environments of changes made under great pressure, conditions for bugs proliferation are optimal :-D
  • When that happens, when bugs are running everywhere, the vicious circle recycles: more urgent and/or more expensive changes with even better conditions for bugs generation
  • Those can lead to a dead end known of project paralysis, manifested in the moral of developers, analysts, architects and project leaders, due to the fact that every initiative to regain control is anyway expensive and requires, although the previously invested effort, a new one greater
  • This project paralysis can affect also the user / customer side, when the confidence on the outcomes is ran out
  • After this happens it comes… Not. Nothing comes after this: when the confidence runs out, the project is over

 

So the key here is achieve a schema of frequent builds for iterative, incremental running results. But trying to adopt that practice manually is stressful and could lead to early lack of motivation

 

So the key of the key has to do with automating the building process. Turning it to a industrial scale. Fortunately several tools can leverage us with building automation (MSBuild, NAnt, NMake), unit testing (NUnit, NUnitForms, Visual Studio 2005 Testing support, etc) and code analysis (FxCop, ...)

 

In his ninth chapter on the webcast series "Architecting Desktop Applications", PhD. Joe Hummel will show us how static code analysis prevents, in compile-time, design rule breaching (for instance for security, low coupling, performance, naming conventions, etc) thanks to a built-in VS2005 extensible mechanism known as FxCop. This feature is fundamental in those cases where source code is being written by several people with different styles, background and knacks

 

Also, learn how repeatable unit testing helps you keeping component health under control for those sudden changes with VS2005' Testing projects and its assertion mechanism. This will surely avoid several debugging hours. Here, the code coverage will give us a reliable estimation about how many code is really being subject of tests (with the possibility of finding out which code lines aren't)

 

Finally, you'll be taught about scaling the process of building, analyzing the code and running the tests through a facility included with the Visual Studio 2005 distribution called MSBuild. MSBuild is the process that VS2005 launches in background every time we select rebuilding our project. Here you'll see how to schedule MSBuild to build our project with a regular frequence. What about nightly builds, for instance? That would be helpful to know, as soon as possible, if a newly integrated source file is making fail some tests

 

So, what else can I do? Just point where the webcast is:

 

Build, Build, Build, Test, Test, Test

Comments