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