.net架构的后思考(箴言)
作者:网络转载 发布时间:[ 2013/12/11 11:32:29 ] 推荐标签:
箴言1——凡事无
凡事无。作为架构师,你永远不会对任何事有百分之百的把握,你永远无法面面俱到。不过在这个位置上,你必须评估所有的可选方案,并做出有足够预见性的正确决策。你需为自己争取一些时间,以便慢慢思考,因此首先说“凡事无“,然后解释为什么是这样,变数有哪些。若你还不确定有哪些变数,那么可以选用这个通用的回答----“这取决于上下文”。
箴言2——需求是超越一切存在的
架构仅仅是软件 项目中一个自的链接部分。客户将说出他们需要什么,若是客户不清楚自的需,那么会有人引导直至得明确的答案,这是分析师的职责。项目经理将为这个已经正式确定的项目安排基础设施。架构师会得到所有的需求,并为开发者提供设计。开发者将按照架构的意图开发。数据库管理员也会尽力让数据库能良好支持应用程序。你会认识到,客户位于这个链条的顶端,且客户的需求才是重要的部分,客户所需要的东西叫做需求。当然,没有几个客户知道他自己真正需要的是什么,因此需求会不停地变化。
箴言3——根据接口编程
虽然我们是依靠终实现代码来完成需求的,不过仍应该尽可能地使用接口。请牢记“没有接口的话不要开始实现”这句话。仔细分析,你总会找到可以提取的接口。
箴言4——保持简单,但不过于简单
你应该听说过Kiss(Keep It Simple Stupid)原则,但这只是我们修改后的观点。简洁明了通常意味着。以简单为目标,不过要留有自己的底线。若是低于这个底线,那你的解决方案将变得过于简单,这并不是一件好事。
箴言5——继承是为了多态,不是重用
面向对象编程让我们仅编写一个类,然后不停地重用并根据需要扩展,这是依靠继承实现的。不过这是类重用的全部吗?“重用”这个概念要比你延续一眼看上去更加微妙。多态是面向对象编程的核惦功能,意味着你可以互换地使用两个继承类。同时,有些人给出了总结:“重用是继承的一个附带功能。”不过重用不应该成为你的根目标,换句话说,不要仅为了重用而使用继承。好是编写一个新的类来满足需求,而不是继承某个原本不是完此工作的现有类。
箴言6——不要在非数据访问层中使用SQL
牢记这一条:分离关注点。将数据访问代码和细节(例如,连接字符吕、命令和数据表名)先放在一边。或早或晚你总会开始处理,不过不是在设计业务逻辑层和表现层时。如果可能,请将持久化工作交给对象/关系映射(object/Relation Mapper)等专门的工具处理。
箴言7——首先考虑可维护性
若你仅能为软件选择一个特性,那么应该如何选择呢?选择可伸缩性、安全性、性能、可测试性还是可用性呢?在我们看来,上述这些都不是重要的,重要的是可维护性。有了可维护性,上述所有的特性都可以在日后实现。
箴言8——所有的用户输入都是罪恶的
你应该早已听说过这种说法。“纸包不住火”,若是有某种途径让用户可以入侵,那么迟早会被用户发现。这似乎是墨菲法则,确实如此。
箴言9——事后优化
Donald Knuth曾说过,过早地优化是所有软件 罪恶的根源。我们将该说法更进一步说-----不要优化系统,而是让其设计尽可能地灵活面对改进和扩展,仅在系统完成之后,再关注纯粹的优化。
箴言10——在设计时考虑安全性和可测试性
若你很在乎某个系统特性,那么在设计开始前应考虑到它。安全性和可测性也是如此,甚至一个国际标准化组织(ISO)的规范也明确地阐述了这一点。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11