如何做个专业的.net程序员相关诠释。

 先读文章.NET程序员，我们应该更专业点，挺让人不舒服的，上面提到好多东东，俺是菜鸟，确实不懂，细细理了一下。学着专业点吧。

1.我们要熟悉常用的设计模式，懂得DRY、SHY等编程原则，专业的运用Framework，写专业的代码。工作几年了，不要让人一看就是菜鸟
DRY:Don't Repeat Yourself，"每一部分知识必须唯一,明确,可靠的表现在一个系统里"。SHY编程原则是什么啊？

保障可维护性的主要诀窍是遵循DRY原则和Shy原则。 
在一个系统的整个生命周期里，理解和改动这类维护工作的比例一般非常之高。为了维护的方便，要尽量将系统划分为可以独立理解与改动的模块。这就要在设计的时候注重DRY原则与Shy原则。不过，这两条原则有一定的冲突，并不总能兼得，于是在追求的时候要重视分寸。

维护者的两大困扰
有两种情况会给维护者增添很大的麻烦：一种是为了调整一个效果，要改动无数个地方；一种是只改动了一个地方，却影响了很多效果。

在前一种情况下，非常容易出现漏改的问题——因为需要改动的地方太多，有些应该改动的地方没有改动；在后一种情况下，非常容易出现误改的情况——因为被影响的效果太多，有些不该改动的地方跟着变了。

无论出现那种情形，都会使得理解和改动设计变得困难。不过，只要在设计的时候秉持一些原则，这两种事情都可以得到有效的遏制。

DRY原则
DRY是“Don't Repeat Yourself”的缩写。意思是说，在一个设计里，对于任何东西，都应该有且只有一个表示，其它的地方都应该引用这一处。这样需要改动的时候，只需调整这一处，所有的地方就都变更过来了。

运用DRY原则的时候，有一个很微妙的事情是要认真判别两样东西是否是一回事。有时候也有“两样东西现在碰巧看起来是一样的，但是并不能保证将来始终都一样”的情况。这种时候，很可能就有制造一点表面上的重复的必要了。

Shy原则
Shy不是任何东西的缩写。这里是取其字面意思，说系统的每个部分都应该害羞一点，不要把只和自己有关的信息暴露给其它部分，同时也不要毫不客气的依赖太多的其它部分。这样一来，日后便可以放心的修改这些没变暴露的东西，也不用太过担心自己依赖的东西发生了变化。

运用Shy原则的时候的主要挑战在于厘清哪些东西适合被做成系统里的独立单元。特别是确定独立单元的大小。

两条原则的平衡
DRY原则和Shy原则的目标是相同的，都是为了增强系统的可维护性。一个很好的遵循了DRY原则和Shy原则的系统，被称为具有“正交性”的系统。

DRY 原则和Shy原则在某种程度上是不能兼得的：想要一个系统够DRY，就得尽量把各部分里相同的东西分离出去放在一起，这难免就会导致很多部分都和分离出来 的这些东西存在一些关系，从而不够Shy；想要一个系统够Shy，就得努力让各部分都做得和其它部分没有什么暧昧，这难免就会致使每个部分里面都有一些本 来可以共同使用的内容，从而不够DRY。

但是，实际需要的是能兼顾两条原则的设计。这就需要追求每条原则的时候都注意保持一定的分寸

2. 要有专业的代码风格，使用专业的命名。不要写几百行的方法，几千几万行的类，里面动辄十几层的花括号。我所见过的这种代码，一半以上都是水分。太夸张了吧？！

3. 要知道要尽可能少地创建新对象，尽可能地减少IO和反射操作，尤其避免在循环中使用。

4.要知道对客户输入作验证，要会正则表达式，要懂得如何尽可能避免类型转换，要会高效的类型转换方式。

 什么是高效的类型转换方式？菜鸟不懂

5.要明白一些基本Framework常识，比如List、Dictionary等集合类不是线程安全的，知道如何保证线程安全

 

如何保证线程安全？菜鸟不懂

 

6.不要再写Request.QueryString[id].ToString()和ConfigurationManager.AppSettings[key].ToString()这样的可笑代码了（我实在纳闷为什么一多半人都这么写），不要到处画蛇添足的Trim和Try…Catch了。

菜留下看懂了，是字符类型不要再转了。

本文摘自：http://sd.csdn.net/a/20110728/302317.html