做了几年的软件开发，将自己的经验总结一下（一家之言，仅供参考）。
软件系统的质量取决于代码编写的质量和架构设计的质量。
代码编写的质量经过几轮测试后，相对来说是可控的(留待开发、测试的高手研究，这里不做讨论)。
软件设计的质量便成为关键因素，可能决定这个软件使用寿命，是推广使用呢？还是不疾而终呢？
软件设计是什么？
这是百度百科给出的答案：
a.软件设计是把许多事物和问题抽象起来，并且抽象它们不同的层次和角度。将问题或事物分解并模块化使得解决问题变得容易，分解的越细模块数量也就越多，它的副作用就是使得设计者考虑更多的模块之间耦合度的情况。
b.软件设计是从软件需求规格说明书出发，根据需求分析阶段确定的功能，设计软件系统的整体结构、划分功能模块、确定每个模块的实现算法以及编写具体的代码，形成软件的具体设计方案。
简单的讲：就是理解用户的需求，将这些需求转化为软件的功能。
软件设计主要包括UI设计(前端用户页面)和DB设计(后端存储结构)。
用户页面设计趋于简单、明了、大方、得体；配色根据用户企业性质和喜好为宜；页面流程尽量模拟用户企业非系统办公流程，尽量契合用户企业内生态。
总之，就是让用户企业内职员感觉到使用系统后自己的重复性工作减少了，更专注于本职工作且效率提升了，新系统的使用没有额外增加学习负担，没有使自己的本职工作发生改变或更换，即没有产生新的不适而拒绝使用新系统。
UI设计就将这么多吧，我不是这方面的专家，只是一点点体会而已，分享给大家。
应用系统的数据都是按ER方式存储在DB上，DB设计的重要性不言而喻。
DB的设计类似于写新闻稿。
新闻稿的六要素是：谁（Who）、何时（When）、何地（Where）、何事（What）、为何（Why）、过程如何（How）。
换一种说法就是：人物、时间、地点、时间、原因、发生过程。
把这六要素串起来，概括成一句话就是：某人在某时某地做了某事出现了某种结果。
DB的设计与之对应的是：人、财、物、时间、空间、活动。
概括成一句话就是：某人在某时某地做了某事花费某财提供某物得到某物。
比如给民政系统做结婚登记系统：申请结婚的双方在某天某个民政局申请办理结婚登记花费8元(工本费)提供双方户口本、申请表、照片得到结婚证。
该系统要提供的功能有：申请人的录入、资格的审核(有无重婚)、申请登记、打印申请表、打印结婚证、费用核算等。
与之对应的需要设计下面Table：申请登记Table、申请人Table、民政局Table、费用Table、受理人Table、证件Table等（时间一般作为属性存在）。
映射关系分为：一对一、一对多、多对多。
一对一 用一张实体表来实现。
一对多 用两张实体表来实现，其中包含一张父表和一张子表，父子表之间存在外键关系。
多对多需要转换为2个一对多，用两张实体表加一张关系表实现，两张实体表都是父表，关系表作为子表，实体表和关系表之间存在外键关系。
实体表的主键(PK)使用序列号生成的，它虽然唯一但不能保证现实中的实体在数据库中唯一，所以需要给实体表建立唯一键(UK)。
唯一键(UK)是用来保证现实中某个实体的应用系统中唯一存在的约束。
比如：人的唯一键使用身份证号(外国人需要用护照号码)，一般物品的唯一键使用二维条码下方的制造号码。
唯一键的确定是比较困难的，比如：房子、土地等。
房子的唯一键是：区县+街办+道路+院门牌号+小区+栋+单元+层+室编号
土地的唯一键是四至，即东、南、西、北各到什么界限。
关系表的主键(PK)一般使用2张父表的PK组合生成的，它可以不需要再建唯一键。
如果关系表的主键也是用序列号生成的，那需要再建唯一键，唯一键是2张父表的PK组合。
建立PK、UK、FK约束后，DB会给PK、UK创建索引，FK索引需要DB开发者创建，如果不给FK创建索引，将导致父子表关联查询时子表出现全表扫描。
Powerdesigner不能创建UK，只能创建唯一索引。
对于属性(表中的列)设计时需要考虑下面的问题：
1.鉴别是否是页面必须输入的属性，如果可以其他表带入或系统中生成，那么减少用户输入。
2.鉴别是否是可空属性，如果是可以考虑在属性列增加默认值(字符型默认为'',数字型默认为0)，那么可以减少SQL中IS NULL和IS NOT NULL判断。
3.考虑维度和度量，不要将多个维度下的度量混淆。
维度是看问题的一个方向，度量是在该方向的刻度、指标、分类等。
哲学概念有点难懂，举个例子说明如下：
比如人，怎么去看待人呢？
从性别的角度分为男人、女人，那么性别就是维度，男人、女人就是度量。
从国籍的角度分为中国人、美国人...，那么国籍就是维度，具体哪个国籍就是度量。
1个属性列一般用来表示一个维度，该列的取值就是该维度下的度量。
如果用一个列来表示2个维度的组合，那么该列的取值就是该2个维度下度量的笛卡尔积(200多个国家*2种性别)。
问：我们为什么要写代码？
答：为了一份工作，养家糊口，生活下去。
OK，这个理由无法辩驳，我也依赖写代码生活。
这里我只想说一下我的另一个观点：
我们写代码首先是为了给我们自己和我们后来的同伴阅读，其次是为了交给机器运行。
甲方人员不会去通读我们的代码，他们只会关注业务功能是否实现；
乙方管理人员也不会通读我们的代码，他们只会关注进度有无滞后；
而我们呢？一个模块或者系统开发完了，甚至已经上线了，几个月后一个错误爆出来，是不是我们自己或者同伴去读原有的代码，并修改可疑的代码。
所以，代码写出来是给成自己读的。
再所以，代码的可读性是第一位，其次是效率。
怎么样提高可读性呢？
第一，加注释。要求注释量占到代码总量的30%-50%。
第二，写通俗易懂的代码。唐朝有个诗人（白居易），诗写好后先读给妇孺，以妇孺能明白作为好坏的评价标准。
我想写代码也是这样吧，最怕的是，自己写的代码，两三年后自己也看不懂了。
基于PMP的理论，质量由时间、资源、成本决定。
软件开发项目同样适用该理论，在满足用户基本质量要求下，用最短时间，开发成本最低的系统。
所以设计很容易被忽略，文档很容易被省略。
所有都朝着多干快跑的方向前进，质量始终于满足当前交付标准为前提。
我们对于市政建设中将路面铺好了挖开，挖了再铺，铺了再挖，反反复复，颇有怨言。
我们的软件系统建设拿到不也是这样吗？
建个新系统，用了3、5年，来个新需求，原有的开发人员流失殆尽，没文档、source也不一定全或者新，
现有人员改不了，那就推到了重建吧。
在国内，我们已经把软件做成服务品了，
难道还要这么一路下去把它做成消费品吗？
“工匠精神”已由国家层面开始号召，让我们从做工匠开始吧。
很多管理者喜欢采用线性思维进行管理，因为它投入和产出是成正比，且比较容易掌控进度。
其实大多数事物都是正态分布的，中间大两头小。
即编码阶段投入少、产出大；前期分析、设计阶段和后期部署上线阶段投入大、产出少。
我想说的是前期设计是系统质量的灵魂，一定不能忽视。
以上是我对软件设计工作的一点感悟，
零零散散的，没有系统性，因为我也是在摸索，
希望多志同道合的朋友们由些许的帮助。
谢谢！
