首页 > 其他 > 详细

一些系统设计和系统开发的感悟

时间:2018-10-12 23:34:05      阅读:41      评论:0      收藏:0      [点我收藏+]

标签:比较   开发人员   tex   是什么   三种   ima   很多   归纳   acf   

最近没啥产出,心态不太好,想写的很多,但博客更新的比较少。
今天谈谈系统设计的感悟吧(虽然也没设计过NB的系统)。
做出一个系统和做功能是不同的,考虑的因素也不相同。相对来说,功能开发比较简单,系统设计考虑的内容比较多。

商业论证

这个是在项目启动阶段考虑的问题,所有的项目开发的目标都为了实现一定的有价值的目标而存在的。再美好的过程,再高深的技术,再精英的团队,开发出来的东西没人用,没产生价值,全部成了沉没成本,最后只能成为谈资而已。
技术分享图片

时间、成本、质量

无论是系统还是功能开发,亦或者是二次开发,都要满足一个基本原则,即在有限的时间,投入适当的成本,去完成既定的功能,即达到目标要求的质量。无论代码写的多么漂亮,用的技术多么高大上,最终都是在制约因素的限制下,实现既定的功能。质量是唯一不能妥协的因素。
技术分享图片

权责统一

这个是在项目启动阶段要明确的事,一个团队,一个项目组一定要明确谁是负责的人,谁应该对这个全局负责,明确权利和责任,是保障成功的关键。人人头上有指标 人人肩上有责任。模糊的角色设定,往往在开发的过程中让人捉襟见肘。
技术分享图片

可持续性

日常开发和开源软件的写法还是有很大区别的。开源软件只需要暴露接口,即实现什么功能,调用什么方法就可以了。使用者很少去关心里面的实现逻辑,打开软件的源码,你会发现有些地方也是一大坨一大坨的,如果业务代码也写成这样,基本上后面很难保证不出问题。

日常开发则不是,你自己写的项目,是需要随着项目的使用周期,功能迭代需要无数次的修改。所以,注释,清晰的逻辑是十分重要。如果你的代码只是自己比较清楚,逻辑高度压缩,那么估计只能自己维护了,因为别人看不懂。这也是为啥背锅的总是离职人员的原因了。

在一个生命周期比较长的开发中,你是否考虑过产品的扩容,DB的缩容。是否能在现在的基础上,逐步升级你的系统。还是等到山前的时候,才去考虑方案?
技术分享图片

文档

文档是对业务的说明,产品文档,技术文档一定要写。开发人员大多数不愿意写文档,其实这是不对的。
代码源于产品逻辑,而清晰的代码又可以总结出业务流,数据流。文档书写需要遵循几个宗旨。

  1. 清晰,文档一定要清晰,主要目标是告诉他人这是什么,怎么用等内容,所以一定要清晰的表达出自己的意思。
  2. 安全,文档一定要安全,安全的意思是,文档的服务器一定不要是临时的,自己搭建的。是有人在维护的,这样可以避免人员流失引起文档断更的尴尬。

每个角色都应该不断的总结,整理归纳。

人生不只有true或false

世界是丰富多彩的,我在定义变量时很少定义成true/false, 这个习惯不太好。不过我有我自己的想法,总在一些场景的时候考虑,如果来了第三种情况怎么办。结果就定义成了0和1,如果来了扩展第三种情况,就加个2即可。

代码也是如此,要考虑到有第三种情况。是加case。

先写到这里吧。

一些系统设计和系统开发的感悟

标签:比较   开发人员   tex   是什么   三种   ima   很多   归纳   acf   

原文:http://blog.51cto.com/9681602/2299477

(0)
(0)
   
举报
评论 一句话评论(0
0条  
登录后才能评论!
© 2014 bubuko.com 版权所有 鲁ICP备09046678号-4
打开技术之扣,分享程序人生!
             

鲁公网安备 37021202000002号