[征集].NET开发经验整理第一期---期待你的参与

　　上周末我发起<[征集].NET软件设计经验－－－－期待你的参与  >的活动.经过一周,得到了大家的积极响应.今天 我花时间把大家给出的建议收集整理了一下,并加了一点自己的看法.现在放出来,给跟多的人看看,欢迎大家点评.

　　如果你有更好更多地经验,请你不吝赐教,留下宝贵的一句.

　　此次活动的口号是:也许你的一句话,就能让困惑中的人茅塞顿开.　　

编号	ID	经验	支持	个人见解
1	麦舒	改进现在有的轮子，而不是重新发明轮子。	√√√	这是一种学习工作态度. 只有继承别人的经验,我们才能走得更远.
2	个人知识管理	永远不要在简历中写到：精通.net。 太多东西要学了，达到一定层次后，你会发现有更上一层的东西需要学习。	√√√	气球理论: 知道的越少,不知道的更少; 知道的越多,不知道的更多;
3	Todd Wei	理解struct和class 的区别，不能仅停留在语法和底层实现，还应该从语义和设计层面来理解。	√√√	.NET中struct与class看起来没什么区别.也许有的人几乎没用过struct.不过当你做一个内部逻辑很复杂的项目时,最好还是了解它们的区别,因为你的项目可能会仅仅因为少一个引用或多一个引用埋下重大隐患(个人亲身经历).
4	木+头	看看这个Helper 那个Helper 其实每个人都能写出自己的Helper.做事情不能只顾眼前. 多考虑下怎么用更少的代码做更多的事情 当然这是建立在可读性的前提下	√√√	努力用更少的代码做更多地事是提升个人能力的最实用途径.因为这时候你不得不考虑解耦,依赖,抽象,封装…
5	金色海洋（jyk）	在 b/s里，观察者模式没什么勇武之地，因为b/s是断开连接的，找不到订阅者。 至于asp.net里的事件？这个已经实现好了，我们用就可以了。 在b/s里，除了事件，还有观察者的应用场景吗？我说的是用面向对象的方式实现的观察者。 单件模式，单件的目的是什么？不是state，而是继承。 不继承的话，直接state就可以了，用单件费那个是做什么？ 迭代模式、原形模式，这两个模式还一点都不会。 我觉得应该用 策略、状态、模板、工厂等这样的模式来说。 .net内部有些地方用的就是这几个模式，而且我们在实际编程的时候也是很常用到这几个模式。	√√	每个模式都有适用的地方,也有不适用的地方.也许你仅做B/S,在适当的时候也需要关注一下desktop,c/s.没有一种模式是万能的.软件工程师进阶到软件架构师的一个必要条件就是需要更广阔的眼光.
6	Teddy's Knowledge Base	出发点是好的.不过,实际的经验往往都不是对某一个单一技术的孤立使用.你所举例的"一句话",只能算是一个个孤立的tips,而且缺乏亲自的实践和深入的理解,本质上你的tips对别人还是理论性的东西. 而且,tips容易收集,但是,真正的好的设计经验,则往往要针对具体的场景才能说得明白的. 你的题目范围也太大了,即使把scope限制为gof,我觉得题目也太大了.过于零散的tips,就是知道得再多,在我看来,对于整体设计能力的提高来说作用也是相当有限的.	√√	个人认为,大家IQ没有绝对的差距,但都可能遇到"需要一点点提示就思如泉涌"的情况.也许正是对一个人无用的tips,对另外一个人却有"点睛"的作用.
7	圣殿骑士	说实在的，这个话题确实很大，你这种感受我们都会有，回顾过去，由于项目和公司原因，自己零零碎碎的什么都在做，什么都不精，也不敢在这里谈经验，只是自己的体会，望各位高手见谅，其他平台很菜，就不说了，对.Net平台感觉刚入门，从WinForm、ASP.NET（ASP.NET MVC一个项目没做完就被终止）到WPF和Silverlight，以至于到现在做的Windows Azure，不论是采用什么技术，最基本的东西都不会变，比如对数据库、文件和其他设备的访问、对日志和异常的处理、对数据结构的处理、对报表的展现、对打印的实现、对性能的提升、对数据的处理、对用户友好等等。 那么这些项目也为我们积累了不少经验，有技术上的也有其他方面的： * 为了应付项目需求的不断变化和项目的可扩展性，我们也会引入OO和设计模式； * 为了解除各模块和组件的耦合，我们也会利用IOC的思想解耦； * 为了让逻辑代码清晰且没有其他代码的干扰，我们也会采用AOP的方式进行代码重组； * 为了解决诸如莫名奇妙的内存错误、invoke异常，我们也会去研究晦涩难懂的CLR&IL,问题出了，你负责这个项目，必须得解决。 * 为了使项目的开发速度更快且更方便，我们也会引入ORM思想来加快项目的开发速度和可维护性； * 为了更好组织各层开发，隔开耦合，我们也会采用MVC、MVP、MVVM模式； * 为了提升用户的响应速度，我们会采用AJAX的方式来实现；采用异步编程去解决用户漫长的等待问题； * 为了降低系统的负载同时提高用户的响应能力，我们也会采用MSMQ或者SSB来组织消息队列； *各种应用程序、各种服务的交错会让我们感到手足无措，为了规范各系统的接口，提供一个统一的交互平台，我们也会采用SOA； *针对大量数据量实时处理、较高计算，解除用户等待的漫长等待，为了降低服务器的负担和提高速度，我们也会自己写一套缓存，并保证缓存的正确的更新与去除； * 为了把产品做好，我们也会不断优化技术直至达到期望的效果； * 为了能做好外包项目，我们会不需要任何高深技术，首先给客户期望的效果； * 为了能得到客户满意老板好评，我们也会学会如何交流，要明白最终是要得到客户的满意度，要得到money； 其实归根到底就是要分清关系，理清思绪，既要处理好与机器的关系，也要处理好与人的关系，只有这样才能把产品或者项目做成功，项目做成功了，才有后面的发展和晋升，我也在不断学习当中，始终感觉自己是菜鸟，回头望去猛然发现自己又回到了原点，只有不断学习，不断进步了！ 另外我们就事论事，你在文中提到： 1. 单件模式可以用Readonly,Static关键字实现； 2. 观察者模式用一个事件就可以实现； 3. 迭代模式仅仅继承IEnumerable接口即可实现； 4. 原形模式仅仅继承ICloneable接口即可实现； 那么针对第一条，单例模式在哪些场景需要使用，哪些场景不需要使用，如何控制并发访问和死锁，这些都不是一句话两句话能说清楚的。 针对第二条，观察者模式事件虽然是一个好的说明，尤其是在CS项目中用得较多，但对于BS项目有很多局限。更多的是用在业务之间的依赖和交互，UI之间的关联，如主窗体和子窗体在很多场景用观察者、ViewModel之间也可以用观察者，只要能给我们带来好处就行。 针对第三条，迭代模式是在.net可以继承 IEnumerable接口实现，但是更多的时候，我们可以用在自定义业务组件和数据的迭代。 针对第四条，原型模式浅拷贝和深拷贝究竟有什么区别，为什么要这样做，也就是堆和栈的关系了。 总之，一两句话是很难说清楚的，至少我个人认为，呵呵！	√√√	圣殿骑士句句箴言啊
8	缪军	从属性到方法,再到对象,如果开发者养成了先声明,后实现的开发习惯和思维方式, 那么,自然而然程序骨架都是依赖抽象(或者说依赖设计概念)的, 其实这就是建模, 利用现成的或者自己开发的建模工具, 真正的软件设计人员可以不用关心编程语言, 就把所有者视图转换成设计者视图(也就是从概念模型到物理模型), 而建模工具可以自动生成所有的声明代码, 项目经理用建模工具就可以轻松地分割项目和派工, 而接下来的实现部分,才轮到代码开发工具上场	√√√	TDD是缪军意见最好的体现.先声明可以对部分耦合提前解耦.
9	IT鸟	实用方便就用，否则弃之。	√√√	简单明了,无需多说
10	Tony Zhou	楼主不要走入“按设计模式开发”的误区	√√√	设计模式不是万能的
11	草珊瑚	需求分析，结构设计，逻辑编写，性能保证，安全保证	√√√	这个模式很经典,实际中要做到有点难.不过只要愿意努力尝试,定有事半功倍的效果.
12	K#	按接口编程 组合优于继承	√√	本人也同意,但不绝对.还是强调一个词"场景"
13	Alex He	不要随便动别人的代码，程序员是有信仰的	√	一个√不针对Alex He.针对有该情结的人.我们只有勇于接受别人的批评才能进步.
14	xiaotie	(1) 不要复制粘贴（实在没办法时再复制粘贴）； (2) 放弃单件模式，实在需要的话，用《企业应用架构模式》中的注册表模式； (3) 曳光弹 (4) 正交设计	√√√	对1:相信有复制粘贴经验的人现在肯定不会这么做了; 对2:还是"场景",如果单件特别大或高性能时就不能用注册表模式了; 对3:有个耐克官方与中国山寨厂商解决空鞋盒子问题的故事跟这个有点类似,都说明了也许科学(依靠理论假设设计)有时候真的不适用; 对4:直升机不解耦可能坠机,软件不解耦可能失败;
15	小洋（燕洋天)	带着脑袋做事，不要只是机械的做，要不断的思考，不断分析问题和提出可行的改进方案	√√√	举手同意.大名鼎鼎的设计模式也是人思考出来的.
16	沉默的代码	封装很重要，我一直想c#里面要是有一个internal-friend关键字多好， 因为friend关键字会破坏封装，所以被微软去掉，但是它又加了一个internal关键字，这样有时候我想要控制粒度比较细致的封装就不得不多划分几个工程，那么如果有一个internal-friend的话就能够在一个工程里面做到细致的封装。	√√√	internal-friend,不太懂.个人觉得internal就可以做到细粒度的控制.谁有更好的建议,分享一下噢
17	Bēniaǒ	1、满足项目自身业务需求 2、为系统提供稳定、安全、可扩展等多方面支持的开发框架 3、降低系统部署难度 4、减低系统版本更新难度 5、提供标准、统一的UI风格	√√	对1:考虑不该考虑的,除了是画蛇添足,还是自找麻烦; 对5:统一的风格不仅能提高能做效率,而其在推广上还有积极的意义. 2,3,4:个人认为是需求.
18	晓染霜林醉	不要以为自己很有创新精神，很多时候你只需要组合组合。	√√√	航天飞机也是组合出来的.遇到问题的时候先看别人是怎么做的.
19	Arthas-Cui	混乱开发模式” 大概方法， 有点类似于我（们）自己的房间， 看起来一团乱糟， 但是关键的地方有一定的条理， 没有用太多无用的力气去收拾表面工作， 但是可以迅速的找到自己想要的东西， 改变成需要的样子。可以迅速的改变自己， 或者说拥抱变化。 看似混乱， 其实在内部来说， 并不是混乱的。 看似好像必须大整特整， 实际上却是节约无用的力气。 如果有人打魔兽，我可以笼统的说， 类似orc的万金油一样。 看起来兵力杂乱无章， 实际上是让兵力更加通用， 互相配合的更紧密。 做到1+1>>>>>>>>2~~~	√√√	也同意,也不同意."混乱模式"可用于非常时期,对技术要求也比较高.比较难以普及和协作.个人认为,如果有"混乱模式"的产品,最好花精力整理装饰一番.现在的客户都挑剔的很啊.酒香不怕巷子深的年代已不复存在了.
20	泪奔的老刘	任何架构都不是通用的,实际到项目中也许松散耦合并不适用.经验的积累需要大量的时间和实践,有人说过每个人如果专注在一件事情上10000小时,就能成为这方面的专家.我觉得有道理,当你通过大量的实践去累积经验,自然会有自己的一套或几套架构,形成自己的代码库.	√√√	做好事情的前提之一就是"专注".这是个古老的训诫:"只要有恒心,铁杵磨成针".对新人而言,有其重要.