个人对系统设计的一些感悟
<div id="cnblogs_post_body">一个系统不管多大，设计的多强，自由性多强，但是最终的对象还是：人；要经过“人”来开发这套系统，由“人”来使用这套系统。
因此，设计的过程要最主要考虑还是“人”的 方面问题，系统设计出来，由谁开发、谁维护，开发人员的技术水平如何，各个模块的接口设计人的水平，
是否有效的及时的反应客户的问题，并把设计成功展现给客户确认，客户的操作习惯，知识程度，对电脑操作的熟练程度，业务水平等等，
都会影响系统的功能是否完全发挥，能否给用户带来方便；
而系统出现“人”的问题，根本上还是“沟通”引起的，是否有效、及时，准确的沟通，决定后期系统的开发周期，维护难度等等。
现在我们系统维护很苦难，主要还是前期沟通问题，设计人员设计出表结构后，没有及时像各模块leader以文档的形式，说明各字段的用处；开发人员
按照设计人员画的模块，和给的表结构开发画面，对表数据进行：“增删改查”但是并不清楚，表中各字段的具体含义，在整体系统中的用处，而对个别
感觉不重要的字段，在不清楚用处的情况下，随机给个值，而不是和设计人员进行沟通，
导致客户端和后台数据流内在联系、流程化上出现问题，开发阶段埋了很多雷，到流程测试的时候，会发现很多问题，而且改动的比较大，特别是一些
隐形的bug，正常情况测试不出来，但是真正上线，在真实的环境下，测试出来的问题，就更难解决和维护，这也是为什么大部分开发人员很郁闷：为什么
老是修改程序。
因为系统比较大，各个模块开发的人员不同，而不同的开发，设计人员：性格、交流程度，技术水平，所处的环境等因素都是设计系统中，重点考虑的问题是
系统的设计可能不一定要多强大，多先进，而是是否能给用户以最大的方便性，是否能给他们带来便利，随便出现一个异常情况（断网，断电，
数据库崩溃，人为的操作失误），整个流程就没办法走通；
有人说：如果当初大家都按照当初的设计规范来执行，都能在各自的模块保证数据的正确性，有效性，那么整个系统开发就很轻松了。
但是 真的是这样的吗？现实情况是很多预想不到的情况，总会冲击我们的当初的完美设计，而我们也只能无语的一次又一次的修改数据，从系统的角度上：
不通过系统正常的流程，而是人为的修改数据库数据是设计不合理的最真实反映，因此系统设计，特别是各个接口中，必要的校验是必须的，不能把
想象中的完美设计，做为开发的原则。
我也只是一个小兵，打酱油的，没参与过设计，只是负责后台的流程，但是从接触流程到现在，感觉问题还是很多，也想过，也正在寻找，
或许通过别的方式，新的设计思路改变我们原先的设计。
页:
[1]