Shane Duffy

Archive for the ‘c#’ Category

Introduction

The purpose of this article is to define a set of ideal practices for an agile software development project. I encourage you to leave comments about this article using the comments box at the bottom of this page. Please note that the practices listed are the practices that I believe are essential to a good agile development project; they do not necessarily have anything to do with being agile. I have tried to list the practices in descending order of importance.

Practice 1: Aggressive refactoring

In my opinion, refactoring is the most overlooked skill for a software developer. A well refactored application has a much higher value to the project sponsor than a poorly refactored application. The most common sign of code in need of refactoring is excessively long methods. I try to keep methods to less than 100 lines. Other common code smells are misleading or meaningless variable names, and code duplication. Static code analysis tools, such as FxCop, can provide a useful measure of code quality.

Practice 2: Testing

Firstly, there should be some developer testing. All the code that is written should be testable and should have tests written for it. It is acceptable to modify your program to facilitate good testing. I believe that the traditional testing terms; unit tests, integration tests and system tests have become outdated. Instead, I prefer the terms developer tests, functional tests and non-functional tests. Non-functional tests are things like performance testing, functional tests are tests that the customer cares about like use case tests or business transaction tests, and developer tests are everything else that the developer needs to test to prove to herself that the code is correct.

We should automate as much testing as possible and run it as part of continuous integration. If code coverage analysis is included in the automated testing it provides a nice indication of the health of the system at any point of time.

Practice 3: Automated build and deployment

The project should have an automated build, an automated deployment and ideally automated testing. In the optimal situation, a developer can click a button and the build process will build the latest source, deploy, test and report on the result. Automating these processes not only saves time but also eliminates a huge number of bugs and time wasters.

Practice 4: Continuous integration

If a project has automated build, deployment and testing then continuous integration is really just a matter of automating the kick-off of that build, deploy test cycle. Every checkin should result in a new build and test, on a separate build server. The results of this should be reported to every team member and it should be an established team practice to immediately fix the build. A working build should be everyone’s top priority. People should not be made to feel bad if they break the build, as this decreases their courage.

Practice 5: Source control

A source control system should be used to store all project artifacts including: code, non-code documentation, build scripts, database schema and data scripts, and tests. The code should not be checked into the build until it compiles and passes its tests.

Practice 6: Communication plan

There should be a defined, direct communication channel between the developers and the customers. This can be (best to worst): on demand face-to-face communication, daily or weekly face-face communication, contact phone numbers, instant messaging, email mailing list, intermediary (BA or PM). These communication channels can and should be combined.

Practice 7: Task tracking

There should be a defined technique for recording and prioritizing development tasks and bugs. The system should make it possible to assign responsibility for tasks to individuals. If tasks are tracked against estimates then the estimate should be performed by the person who will do the task.

Practice 8: Self documenting code

Code comments should be subjected to the same quality requirements as the code itself. Everything possible should be done to ensure that no other technical documentation is required. When non-code technical documentation is required it should be subject to the following restrictions: referenced from the code, always up-to-date (change when the code changes), only one version per baseline, stored in source control.

Practice 9: Peer review

There must be some form of peer review, such as code review of fellow programmers. If the developers are subjected to performance reviews then the peer reviews they do should be an input to that process. This helps to avoid the temptation to approve everything to avoid confrontation. Make sure that the reviews are for quality, not just for correctness.

Practice 10: Work-in-progress

A working version of the latest iteration should always be available for customer feedback. The advantage of this is that customers see very quickly when something has been developed contrary to what they had in mind. Shortening this feedback loop decreases the cost of change.

Practice 11: Feedback mechanism

There should be a defined mechanism for project team members, including the customer, to provide feedback on the project’s processes. My suggestion is to hold a short meeting at the end of each iteration.

 

Article by

Liam McLennan

Advertisements

Creating Task List Comments in your projects can ensure you to complete the important and esential tasks. This feature can be used to indicate a variety of work to be done at the location marked

The Task List displays comments embedded in your project code that begin with the comment marker for your development language, followed by a default task token such as TODO, HACK, or UNDONE, or a custom comment token.

The number of comments that appear in the Task List changes, depending on the type of project you are working on.
With Visual Basic projects, the Task List displays all of the comments in the project.
With Visual C# and Visual J# projects, the Task List displays only the comments that are found in the files currently opened for edit.
With Visual C++ projects, the Task List displays only the comments that are found in the file currently active in the editor.

To add a comment to the Task List
1. Open a source code file for editing in the Code Editor.

2. Begin a comment on a line of code you want to mark with <marker><token>, where <marker> is the comment marker for your development language, and <token> is the name of a recognized Task List comment token, such as TODO, HACK, or UNDONE, or a custom comment token.

By default, the task window is not visible, so the first thing you must do is make the task list visible. As with most things in Visual Studio, you can achieve this with either a keyboard shortcutt (Ctrl+Alt+K) or by going to View | Other Windows | Task List.
Vs 2005 Comments

As with other Task List entries, you can double-click any comment entry to display the file indicated in the Code Editor and jump to the line of code marked.

Example of TODO Comment:
// TODO: Add references to specific resources here

It is recommended that store your database connection strings in the Web.config file and encrypt the connection strings. In the .NET Framework 2.0, you have the option to enable the configuration encryption in the <protectedData> section in the web.config file.
For example:
<protectedData>
<protectedDataSections>
<add name=”connectionStrings” provider=”RSAProtectedConfigurationProvider”/>
</protectedDataSections>
</protectedData>
There are two predefined providers that you can find in the .NET Framework 2.0:
1. DPAPIProtectedConfigurationProvider: It uses the Windows data protection API (DPAPI) to encrypt and decrypt configuration data.
2. RSAProtectedConfigurationProvider: It uses RSA encryption to encrypt and decrypt configuration data

Both the RSA and DPAPI providers are good options for you to encrypt the sensitive data.
However, DPAPI is not recommended to proctect sections in a web farm scenario. This is because the same encrypted web.config file will be deployed to all the machines. What you can do here is to manually encrypt the web.config files on each machine or copy the same container key to the machines.

To create a key container: aspnet_regiis.exe -pc YourContainerName -exp
Export to an XML file: aspnet_regiis.exe -px YourContainerName YourXmlFile.xml
Move the XML file to other machin: aspnet_regiis.exe -pi YourContainerName YourXmFile.xml

Here is an article discussed on the  Encrypting Connection Strings in Web.config. http://www.ondotnet.com/pub/a/dotnet/2005/02/15/encryptingconnstring.html


Subscribe to this blog now!

Top Clicks

  • None
November 2018
M T W T F S S
« Feb    
 1234
567891011
12131415161718
19202122232425
2627282930  
Advertisements