程序人生（一）

目录

笔者连续开了一个月的需求讨论会议，从总监口中获得了很多开会的技巧，其中夹杂了一些职场的行动规则，甚至软件工程的一些比较有新意的想法，特意为文以便时时查看，也希望给后来者以启发。

财务数据一定要详细

1. 首先财务类数据，很多时候不是查看实时的，对于企业来说，更多时候是看的环比或者历年的对比，然而在我们的国家“财务计算规则”或者某件物品的“计算规则”是带有实时性质的，意思就是说很多比如“消费税率”或者“基准税率”是带有明显的 “年代特性的”，随着时间的推移，这种国家规定或者给予参考性质的值是会变化，这时如果公司需要查看10年前的财务数据，我肯定需要一个“可供证明我这个数据合法性的依据”，——-结论：所以即使是再小的，再琐碎的“依据”，我们也需要记录在数据库，
2. 对于复用率很高的代码或者需要生成不同报表类的需求，我们建议是使用一个统一的工具类去维护，避免在使用过程中要一一去做修改，——善于总结代码复写中的规律。

数据库三范式

1.首先在实际项目中，数据库的设计很大程度上是不会很严格的按照提出了“很久很久”的三范式的规则的，我们在沿用或者想使用某一条“理论”和“规范”去做设计时，首要肯定要考虑这个“理论”提出的时代背景，在“远古时代”，那时候 “储存空间”十分昂贵，那时候的U盘只有KB单位的，硬盘只有MB的，所以制定了很多的现在看起来“奇怪的”规则，——结论：我们设计表时，其实不用太遵守，太苛求“三范式”

怎么处理上传的文件

.我们经常能在项目中遇到大批量上传文件的功能，但是往往人类在做文件时，难免会有疏漏，所以校验数据就很重要了，总监说了一种方案，
前端：传过去先
服务器：接受后，全部存入临时表，
数据库：写一个储存过程，校验临时表，将不合法的给一个不合法的标志
服务器：调用储存过程，再将临时表查询出来
前端：显示刚才不合法的数据信息
前端：决定要不要将刚才的信息储存到数据库，

业务决定的需求

1.实际开发中，我们原本规划好的数据流，或者审批流，其实是很容易发生变化的，所以“以一个实体的状态做为分割表的依据”是十分的愚蠢的，不要想当然的觉得 一个实体拆分成不止一张表就会提高查询的效率，一旦更改业务流程，那么涉及到的表的修改，会极大的影响系统的使用，——不要轻易做拆分
2.对于一些数据库表的约定俗成的开发规则，比如：财务数据留痕，流水表的引入，业务状态，激活状态，使用状态，创建人，更新人，版本号，这些十分常见的东西是必须存在的，——通则
3.如果业务要求的是一张详尽的对账单，我们通常是他们全部放在一张表中，不要考虑他妈的三范式，支付宝的有些表 字段有3000个，在以空间换取时间的今天，在储存空间白菜价的今天，你就不要考虑什么冗余和不合规范，——–不要考虑空间

字典表的使用

1.通常字典表是独立的， 储存的id和value，即使是在被其他表引用，我们也是使用value，而不是 引用id，

页面的问题

1.为了提供页面友好性，一些固定按钮的摆放就是要放在一起，tool bar的存在可以极大的提高使用效率，
2.主操作类的web系统，我们是可以将 同类别的按钮和输入框放在一起是没有问题的，对于面向大众的系统，是需要考虑怎么摆放不同的按钮的，
3.所有的表 即使 你加了“备注”这个字段，也不会有什么影响， 现实中，系统使用时，很多 角色 为了秀一下“参与的存在感”，总喜欢写一下备注，所以我们需要给他们设置这样一个入口，来增强用户体验性