编程思想原则名词概念解释
2021-11-20 19:05:01 0 举报AI智能生成
编程规范培训,常用开发规范术语解释 笔记记录
作者其他创作
大纲/内容
代码复杂原因与标准
编程的难度
复杂性:软件是现实世界的反应,现实世界是复杂的,注定了软件的复杂性
可变性:现实世界是可变的,注定了软件的可变
不可见性:软件是概念的集合,无法直观可见
团队不稳定性:通常情况一个开发人员阅读别人代码和自己编写代码时间比10:1
衡量标准
交流:顺利开发需要顺利交流,代码是交流的场所,当成给人看的文章
简洁 消除复杂性,更容易理解
灵活性 易于修改
纠正误区:代码不应巧妙 应该清晰
指导原则
KISS原则:keep it simple stupid
优先保证代码的简洁性
优先保证代码的简洁性
模块化原则 精简的模块为单位 模块间的关系应简洁 减少模块之间的接口
DRY原则: Don't repeat Yourself
不要重复写相同的代码
不要重复写相同的代码
对立面WET: Write Every Time 造成结果:可读性下降 代码难以修
相近概念:OFOP (One Fact One Place) 一个地方只有一个事实,独一无二的设计
相近概念:OAOD(Once and Only Once) 有且仅有一次.不可以重复出现
YAGNI原则: (You Arent't Going to Need It)
只写所需最低限度的代码,不能以"可能会用到"为动机写代码,坚持只写当前需要的代码
只写所需最低限度的代码,不能以"可能会用到"为动机写代码,坚持只写当前需要的代码
PIE 原则:(Program Intently and Expressively)
编程表达意图,提高代码的可读性作为第一要素
编程表达意图,提高代码的可读性作为第一要素
读代码次数远比写代码次数多,大约花费时间10:1
要写注释
文学编程 代码混合注释,代码文档位置近
SLAP原则:(Simple Level Of Abstraction Principle) 单一抽象层次原理
高级别抽象化概念和低级别的抽象化概念分离
代码具有概括性和可读性 函数结构化
代码就像图书目录,逐层展开 目录和章节表示层次,上层抽象,底层详细,各个业务独立
代码就像图书目录,逐层展开 目录和章节表示层次,上层抽象,底层详细,各个业务独立
OCP(Open-Closed Principle) 开闭原则
对扩展开放,对修改关闭
代码行为可以扩展,扩展代码时候,其他代码不受影响
代码行为可以扩展,扩展代码时候,其他代码不受影响
代码达到即适应变化,又保证稳定
适用范围受限制
代码命名 名字是代码阅读者的界面
避免心理映射(同一个事物起不同的名称,看到名字做心里转换)
避免词不达意,名字能还原其所指内容的说明文本
代码表现角度
模块化原则 精简的模块为单位 模块间的关系应简洁 减少模块之间的接口
清晰原则 代码不应巧妙 应该清晰
组合原则 软件能够自由组合过滤器
软件能够自由组合过滤器
软件经过某种数据流处理后,经过加工输出到另一种软件使用
分离原则 机制和策略分离 机制比较固定,策略比较灵活
服务类应用 将模块分割成前端与后端 负责理解通信协议,接受客户端请求是策略 实际提供服务的是后端
编辑类应用 编辑器功能的模块可以通过设置文件驱动
简单原则
抵制代码膨胀以及复杂化
拒绝用大量功能装饰软件 聚集了大量功能的软件分割成相互协作的零件
简约原则
不写大代码.代码量大,代码内部的复杂指数大
编写规模小,复杂度低的代码.因为添加而变大需要尽快进行分割
透明性原则
软件的运行要让人一眼就能理解软件在做什么
可以监视软件的内部状态
健壮性原则
不仅能在一般条件下运行,还能在预想之外条件下提供服务
能够承受例外输入的考验
表达性原则
数据和逻辑必须有一个复杂化的时候,选择让数据复杂化.代码的复杂性交给数据
接口设计最小意外原则
接口的设计符合使用者的想象.
降低学习成本
参考类似的软件设计接口,考虑目标用户的特征,避免相似但稍有不同
接口必要信息暴露原则
将输出的信息控制到最少.只输出重要信息,内部运行的信息不要掺杂其中
异常处理原则 异常无法处理时候就不处理终止运行
出错时继续运行容易扩大损害
出错信息要提示
宽容接受输入,严格接受输出
经济原则
程序员的时间是宝贵资源
程序员的时间是宝贵资源
硬件性能不足
可用软件限制
环境相关的规则或者限制
生成原则
使用"用于生成代码"的代码,编写代码生成器
优化原则
代码正确性由于运行速度,先保证正确性再提高运行速度
多样性原则
容许有多样的选择,不存在"唯一正确的方法"
不懈追求更好的方案
可扩展性原则
软件必须可扩展
可插拔式的设计
自我描述的数据格式 设计协议或者文件格式时候,让数据格式具有自我描述性和可扩展性
案例参考unix
小而美
软件规模越小越美丽
规模小的软件 易于理解 容易维护 使用较少的计算机资源 便于组合 专注一项工作
功能职责唯一
一个功能只负责一项职责
功能职责变得纯粹
尽早创建原型
任何系统改良过程,经历改良过程分为三个系统
第一系统 性能良好,欠缺必要功能
第二系统 牺牲性能添加了很多功能
第三系统 性能与功能取得了平衡
可移植性优于效率
维持软件的价值,编写不依赖于硬件不依赖于特定环境特定平台的代码
利用软件的杠杆效应
重复使用既有软件,将各个软件组合起来
避免开发交互式用户接口
弊端:软件之间无法对话 等待时间变成 解析代码复杂
策略:控制权交还给命令解释器
过滤器化
把所有软件设计成过滤器 软件本质是处理数据 流入数据以后经过某种加工再把数据输出
软件的意义就是输入输出
开发人员阅读角度
内聚度:表示模块内功能的纯粹程度,
衡量单个模块的强度
衡量单个模块的强度
巧合强度
各个元素并不存在特别的关系 事务巧合在一起
调用模块A的时候,恰巧调用模块B
逻辑强度
选择不同路径时候在一起.有时候用不到
好处:相关逻辑在一起,集中在一个模块内执行
时间强度
特定的时间点连续执行多个功能的整合
流程强度
处理问题时候,所需的全部或者部分功能整合而成
流程图->功能A->功能B 流程强度就是 模块A,包含功能A,B
通信强度
与流程强度不同的是,相互之间存在通信.功能A,B之间存在数据联系
信息强度
模块A同时三个功能处理同一个数据结构
功能强度
所有命令都为了完成一项工作而相互关联
耦合度:衡量模块之间关系紧密程度
两个模块之间的松紧程度
两个模块之间的松紧程度
内容耦合:两个模块存在共享的部分
公共耦合:公共区域内定义的数据由多个模块共同使用
外部耦合:模块间共享外部声明的数据
控制耦合:以参数的形式传递涉及被调用方模块内部控制的数据
特征耦合:传递公共区域中共有的数据结构 模块
数据耦合:模块间传递数据
正交性代码
修改一组代码,不会影响另一方,两方代码具有正交性
好处:提高生产效率 降低风险
可逆性:代码可以回滚
重构触发条件:
代码重复
函数太长
模块太大
模块太多
名称不一样
技术债务
问题代码出现以及扩散原因
经验不足程序员
交付日期压力
可读性低的代码
特殊化的代码
无用的复杂代码
低质量的设计
团队文化
不提倡写简洁代码
接纳不明确的代码
不给重构的时间
发布之前才做回归测试
不敢替换复杂的旧系统
随意的建分支
恶性循环
技术债导致越来越差
过多的临时解决方案
持续改进
程序员的美德
懒惰:不遗余力的减少重复劳动力的消耗
急躁:编写代码不仅要注意眼前的问题,还要预想今后的问题
傲慢:促使自己写出代码不羞于见人
采取的行动
高强度的工作没有意义,赶工期制造混乱代码
代码最初是谁写的不重要,重要的是我们改善了什么
编程要稳中求胜,逐步迭代优化
代码交流:代码不是私有物品,当成公司财产
舍弃自我,双方注意力要放在更好的代码上,而不是对人
舍弃自我,双方注意力要放在更好的代码上,而不是对人
开发团队角度
先编写能运行的基础部分
人数和月数不可交换,1个人*12个月≠12人*1个月
康威定律:先构建架构然后组织从属于架构
破窗效应
不好的代码相互传染
人会模仿人
重复造轮子
不适合重复造轮子情况
不知道有车轮
不能因为想做而做
适合造轮子情况
商业上的核心部分必须由自己制作
学习目的
0 条评论
下一页
