软件开发的时候总是面临着各种决策，大到模块的划分，小到函数体的写法，这些都是设计的问题。做设计不难，难的是做一个好的设计。然而什么是好的设计？标准是什么？
军事上常说“战术是为战略服务的”。这句话换到软件上来可以变成很多说法：函数是为对象服务的；对象是为底层设计服务的；底层设计是为构架服务的；构架是为需求服务的；需求是为了客户的生产生活服务的……不同的抽象层次上对应不同的战略与战术。
做好一个设计的根本就在于不仅仅着眼于当前的工作层面，而应该能够很好的理解当前工作服务的那个层面！
比如写函数体吧，就需要理解该函数在当前对象上下文中所处的地位和作用，不理解当然也能完成工作，但却称不上一个“好”字。也许有人会问“什么是好？我把当前函数优化到常数复杂度算是好了吧？”那也未必，“好”与“不好”需要放到大局中去看，如果当前函数只在系统启动的时候调用一次，那就没有优化的意义，尽快完成该函数才叫做“好”！
在需求分析方面这一点更重要、更明显！“需求总在变”这话一点儿不假，但是不变的是用户开发这个软件的目的，这才是用户的真正需求。想办法满足用户这个目的就是做好当前项目的捷径。比如现在大部分的中小企业、特别是事业单位的门户或者部门网站，提需求的时候吹得天花乱坠，什么在线办公、客户管理、内部互动啦，说得很好听，其实做了都不用，老板（领导）在意的就俩字：美工！客户的真正目的是什么？政绩！
因此，只有战术在战略层面的地位和意义，才能恰如其分的完成手头工作。把每件事情都做到精益求精的不是工程师，是艺术家。就好比憋足了吃奶、如厕、行房的劲打赢每一场丈的指挥官不一定合格，且不说伤亡巨大、天怒人怨，如果连本来应该败掉的诱敌之战也赢了，那就地军法处置！
对于.NET企业级应用，涉及的层次理论，可以这么粗略的划分：
电子电路 — 汇编 — 系统内核 — CLR — 函数 — 对象 — 设计模式 — 架构 — 需求 — 客户的生产力（竞争力）
搞.NET的大部分工作在函数、对象、设计模式这个层面上，构架师当然是工作在构架的层面、需求分析师以需求为主。敏捷软件开发提倡的一点就是软件的目的在于提升客户（在它们那个领域）的竞争力，这明确的提出软件工程中一个更高级别的抽象层次。剩下的通常不属于咱们操心的范围了。
写函数的时候看看对象；看对象的时候关注一下模式；搞模式的时候瞅瞅构架；做构架的时候不能忘了需求。这不但是职业规划，更是做好当前工作的必要条件，难怪人家说：不想当将军的士兵不是好士兵！
