ASP.NET Web Developer Checklist

最新推荐文章于 2024-09-11 15:33:18 发布

cattei

最新推荐文章于 2024-09-11 15:33:18 发布

阅读量370

点赞数

分类专栏： Asp.Net 文章标签： asp.net web optimization search database javascript

Asp.Net 专栏收录该内容

24 篇文章 0 订阅

订阅专栏

The following is a simple checklist you can use when building web applications. Much of this still applies to other technologies and can easily be extended. I try not to get too specific on technology or methodology, but it is definitely leaning toward ASP.NET.

If you can think of something I am missing or disagree, please leave a comment. Detailed information follows the checklist.

How much of the checklist you follow will depend on the project. If its just a hobby site, you may skip items like load testing, but as the site grows you will likely need to check off more and more items. Some items, like separation of logic should just be done from the start. In any case, you should make an actual decision to ignore the item. This is much better than just forgetting to do it.

The Check List

Everywhere

Use source control.
Be consistent with naming conventions.
Create documentation.
Backup everything.
Use code analysis tools.

Database

Use non-clustered indexes on unique identifier columns.
Setup foreign key relationships.
Use a last updated timestamp column.
Add simple audit columns or a history table.
Analyze and tune your database.

Business Logic

Clearly separate business and data logic.
Use some standard patterns and stick with them.
Do not duplicate rules. Data is okay.
Create unit tests.

Web Interface

Make the site accessible.
Use resource files.
Minimize use of server controls.
Separate your HTML, JavaScript and CSS.
Minimize ViewState.
Pay attention to search engine optimization.
Clearly separate presentation and business logic.
Don’t forget a site map, favicon and search provider.
Create user interface unit tests.
Check your site with YSlow.
Load test the site.
Security test the site.
Use a hosting provider.
Minify and combine resources.
Turn on IIS compression.

Process

Stay agile.
Vision before you design.
Design before you develop.
Test after you develop.

The Details

Use source control.

Even for small, one person projects, rollback can save your life. There are plenty of good ones to choose from including VisualSVN , Team Foundation Server , SourceGear Vault or SourceAnywhere . If your going open source, look into CodePlex . A lot of people really hate SourceSafe , but it’s better than nothing.

Be consistent with naming conventions.

There are lots of opinions on naming conventions. Microsoft publishes guidelines for class libraries . Whatever you use, be consistent. Having many developers on the same team with a different set of standards can make the code a mess. Comprise is likely needed. Don’t forget to apply this rule to database also.

Create documentation.

Document the code well with code comments and create high level documentation to explain major sections of the code. You’ll need it in 6 months. You should also document all your requirements and have a solid project management plan. TargetProcess is a great tool to help with this.

Backup everything.

These easiest way to do this is to make sure everything, including database schema is in source control. Then back that up. Mozy is a good choice of this. It will get your data offsite without any manual process. Be sure to backup your documentation, data and anything you choose not to put in source control. Just imagine your building burning down. What would you need to recover and how. It’s also good to test the backups and see if you can recover everything.

Use code analysis tools.

It’s like having an extra code reviewer on staff. And one that actually does review everything. FxCop , StyleCop and Resharper are great for this.

Use non-clustered indexes on unique identifier columns.

Lately I tend to use unique identifiers as primary keys because they are easy to move between environments and don’t require an extra column be added for replication. One gotcha here is the SQL Server Management Studio will default your primary key index to clustered. This is going to make inserts very slow as your database grows.

Setup foreign key relationships.

A lot of developers seem to miss this for some reason. Open up the diagram tool in SQL Server Management Studio and connect those tables.

Use a last updated timestamp column.

Adding a timestamp column is an easy way to determine if your data is stale and someone or something else has changed it while you had it.

Add simple audit columns or a history table.

Putting in a last edited by and on columns can help a lot. An audit trail in a separate table / tables is even more helpful but these tables can get very large.

Analyze and tune your database.

Indexes are your friend, but too many friends can also be a bad thing. Tune that database. Everything will work well when the database is small, so toss some serious amount test data in there. Red Gate’s SQL Data Compare is great for this. While your checking it out look at some of their other tools. They make data almost fun.

Clearly separate business and data logic.

They don’t necessarily need to be in separate class files, but there needs to be a clear separation in logic. Tools like Linq to SQL can start to blur this line, but you at least want some verification and authentication logic on data updates.

Use some standard patterns and stick with them.

Mixing in ADO.Entities, frameworks like CSLA , creating your own lightweight custom collections and DataSets can drive you crazy over time. Especially when logic starts to cross from one set of code to another. Pick something and stick to it.

Do not duplicate rules. Data is okay.

Any piece of business logic should be in one and only one spot. It’s okay to have multiple classes accessing the same data. This is a necessity when dealing with a full object and some simple lists. But don’t duplicate the logic. There should be one block of code that verifies a rule.

Create unit tests.

How many? That’s a long discussion. In general I create enough that I know the system works. If you follow test driven development you probably have a good handle on this. If you find a bug, check you test cases and see if it was something you could have caught. But definitely write these tests.

Make the site accessible.

Microsoft has a very good article that discusses this topic: Building ASP.NET 2.0 Web Sites Using Web Standards . Visual Studio has a few accessibility tools built in, use them, don’t ignore them.

Use resource files.

What percentage of the world speaks your language? Even if you never add a second language, the use of global and local resource files will keep this option open.

Minimize use of server controls.

If you don’t care about the state of a control, consider using standard HTML controls. ASP.NET server controls create extra overhead with long IDs and ViewState.

Separate your HTML, JavaScript and CSS.

I like starting with just HTML and making sure the site is usable without any JavaScript or CSS. This may keep you from putting everything in DIV tags and use lists and headers the way they should be. Also try to use CSS to style the site and leave JavaScript to handle behavior.

Minimize ViewState.

Turn this off at every level you can: page, user control, and server control. It’s unnecessary overhead.

Pay attention to search engine optimization.

If your site is public, don’t ignore SEO until the end. Google provides some good tips in their Search Engine Optimization Starter Guide . And this Professional Search Engine Optimization with ASP.NET is a great book.

Clearly separate presentation and business logic.

Your application could easily start taking on more interfaces like backend processes, web services, mobile apps. Keep the business logic and presentation logic separated to get as much code re-use as possible. But be careful not to start pushing presentation logic back into the business layer, or your going to have just as many problems.

Don’t forget a site map, favicon and search provider.

These are common files to forget. Double check to make sure you have them. Although you might not need the search provider.

Create user interface unit tests.

If the interface doesn’t work, it doesn’t matter how solid the middle layers and database are. I like using WatiN , although it has some issues running a lot of tests in a row. I tend to build my user interface tests based on the test cases created for the user stories.

Check your site with YSlow.

YSlow is a great plug-in for Firefox that will help you identify problems in the client side design of your application. It gives you some very useful performance statistics and suggestions for fixing issues.

Load test the site.

Figure out how many users you need to support and make sure you can. We use Web Performance for this. It’s much more reasonably priced than some of its competitors and still very feature rich. JMeter is a popular free alternative. Don’t assume because your test pass that everything is perfect, but you are much closer to knowing the truth.

Security test the site.

You are really going to want to find these bugs first. Even if you store no serious personal information other than a password, that password is probably being used on many sites by your users. Even some simple injections can make your site look very unprofessional. Wikto is free and easy to use to test the servers for vulnerabilities, but your going to need something like Acunetix to do some deeper application security testing. I good hosting provider may also be able to help.

Use a hosting provider.

Your basement server is not going to cut it when you get dugg. A hosting provider will take a lot of worry off your hands. Even if its a simple ASP.NET shared hosting plan from GoDaddy or a more scalable solution from Amazon .

Minify and combine resources.

Bandwidth and multiple HTTP requests are going to slow your site down a lot. You can do some of this manually or use a product like Runtime Page Optimizer (RPO).

Turn on IIS compression.

Make sure dynamic and static compression is turned on in IIS unless you have a very good reason not to. RPO will do a better job at this than IIS.

Stay agile.

Keep moving forward. Don’t stagnate in one phase. Scrum is a great practice to start with. TargetProcess will also help with this.

Vision before you design.

Stop and think before you build. What is it you are building and why?

Design before you develop.

Don’t just start writing code. Get a set of core user stories together to help you flush out the idea before making any critical architectural decisions. Try not to get bogged down in this for a long period of time. This is also a good time to start writing test cases.

Test after you develop.

You should be testing as you develop, but do a round of testing before each release.

Money

Many of the tools listed above are free, but some cost money. You can get most of what you need without spending a dime. At some point you should evaluate spending the extra money against what it actually saves you. Of course you have to have money to spend it. Always be on the lookout for open source alternatives, but don’t pick something just because its free unless you have no choice.