码迷,mamicode.com
首页 > 其他好文 > 详细

团队博客第二周——DIG

时间:2019-12-02 00:33:26      阅读:110      评论:0      收藏:0      [点我收藏+]

标签:元素   损坏   记录   预测   功能   原则   项目   包括   输入   

团队博客第二周——DIG

修改完善上周提交的需求规格说明书

服务人群的改变

考虑到我校特有的保密性质,经小组讨论修改应用人群,从大众转向特定局部网络下的特定人群,例如:军人、秘密基地、山区等

修改应用场景
  • 用户场景A:军人小伟和小邹在一个特殊的训练基地,时间紧急,为尽快了解所有菜品,进行点菜,使用APP。
  • 用户场景B:小泊看了食堂的菜,觉得并不好吃,在APP中选择跳转至美团,即可进入美团界面,进行望梅止渴。
支付接口取消

技术图片

在经过实际调研之后,了解到想要把微信或者支付宝接口连接到我们的APP上,并不实际。微信和支付宝要求申请用户拥有三年的经营许可证方可通过,只好放弃

流程图的细节进行修改

技术图片

技术图片

代码规范及编码原则

程序风格:
  • 严格采用阶梯层次组织程序代码
  • 每层次缩进为4格,括号位于下一行。要求相匹配的大括号在同一列,对继行则要求再缩进4格
  • 提示信息字符串的位置 在程序中需要给出的提示字符串,为了支持多种语言的开发,除了一些给调试用的临时信息外,其他所有的提示信息必须定义在资源中。
  • 对变量的定义,尽量位于函数的开始位置。
命名规则
  • 变量名的命名规则;
  • 分析:变量名的命名规则遵循用户自定义标识符命名规则
    • 只能由字母、数字、下划线组成;
    • 第一个字符必须是英文字母;
    • 有效长度为255个字符;
    • 不可以包含标点符号和类型说明符%,&,!,# ,@,$;
    • 不可以是系统的关键词比如else
注释
  • 注释要简单明了。
  • 边写代码边注释,修改代码同时修改相应的注释,以保证 注释与代码的一致性。
  • 在必要的地方注释,注释量要适中。注释的内容要清楚,明了,含义准确,防止注释二义性。
  • 保持注释与其描述的代码相邻,即注释的就近原则。   
  • 对代码的注释应放在其上方相邻位置,不可放在下面。   
  • 对数据结构的注释应放在其上方相邻位置,不可放在下面;对结构中的每个域 的注释应放在此域的右方;
  • 同一结构中不同域的注释要对齐。
  • 变量、常量的注释应放在其上方相邻位置或右方。
  • 全局变量要有较详细的注释,包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明。   
  • 在每个源文件的头部要有必要的注释信息,包括:文件名;版本号;作者;生成日期;
  • 模块功能描述(如功能、主要算法、内部各部分之间的关系、该文件与其它文件关系等);
  • 主要函数或过程清单及本文件历史修改记录等。
  • 在每个函数或过程的前面要有必要的注释信息,包括:函数或过程名称;功能描述;
  • 输入,输出及返回值说明;调用关系及被调用关系说明等。
可读性
  • 避免使用不易理解的数字,用有意义的标识来替代。   
  • 不要使用难懂的技巧性很高的语句。
  • 源程序中关系较为紧密的代码应尽可能相邻。
函数过程
  • 函数的规模尽量限制在200行以内。   
  • 一个函数最好仅完成一件功能。   
  • 为简单功能编写函数。   
  • 函数的功能应该是可以预测的,也就是只要输入数据相同就应产生同样的输出。   
  • 尽量不要编写依赖于其他函数内部实现的函数。
  • 避免设计多参数函数,不使用的参数从接口中去掉。   
  • 用注释详细说明每个参数的作用、取值范围及参数间的关系。   
  • 检查函数所有参数输入的有效性。
  • 检查函数所有非参数输入的有效性,如数据文件、公共变量等。
  • 函数名应准确描述函数的功能。
  • 避免使用无意义或含义不清的动词为函数命名
  • 函数的返回值要清楚、明了,让使用者不容易忽视错误情况。   
  • 明确函数功能,精确(而不是近似)地实现函数设计。   
  • 减少函数本身或函数间的递归调用。   
  • 编写 可重入函数时,若使用全局变量,则应通过关中断、信号量(即P、V操作)等手段对其加以保护。
变量编辑
  • 去掉没必要的公共变量。
  • 构造仅有一个模块或函数可以修改、创建,而其余有关模块或函数只访问的公共变量,防止多个不同模块或函数都可以修改、创建同一公共变量的现象。
  • 仔细定义并明确公共变量的含义、作用、取值范围及公共变量间的关系。
  • 明确公共变量与操作此公共变量的函数或过程的关系,如访问、修改及创建等。
  • 当向公共变量传递数据时,要十分小心,防止赋与不合理的值或越界等现象发生。
  • 防止局部变量与公共变量同名。
  • 仔细设计结构中元素的布局与排列顺序,使结构容易理解、节省占用空间,并减 少引起误用现象。
  • 结构的设计要尽量考虑 向前兼容和以后的版本升级,并为某些未来可能的应用保留余地(如预留一些空间等)。
  • 留心具体语言及编译器处理不同数据类型的原则及有关细节。   
  • 严禁使用未经初始化的变量。声明变量的同时对变量进行初始化。   
  • 编程时,要注意数据类型的 强制转换。
代码编译
  • 编写代码时要注意随时保存,并定期备份,防止由于断电、硬盘损坏等原因造成代码丢失。
  • 同一项目组内,最好使用相同的编辑器,并使用相同的设置选项。
  • 合理地设计软件系统目录,方便开发人员使用。
  • 打开编译器的所有告警开关对程序进行编译。
  • 在同一项目组或产品组中,要统一编译开关选项.
  • 使用工具软件对代码版本进行维护。

Powerdesigner数据库设计ER图

后端架构设计

团队博客第二周——DIG

标签:元素   损坏   记录   预测   功能   原则   项目   包括   输入   

原文地址:https://www.cnblogs.com/zhaopeining/p/11968411.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!