标签：改动 代码 编程 Class 工作效率 开发 文档 解析 class
第二种：错了哪里，就把整个模块 这份代码可能出错的地方 检察一遍有没别的错误。 这个开发效率稍微好一点。
第三种：错了哪里，基于第二种找出原因后，思考一开始为什么这么设计并记录下来，保证之后不再这个地方犯错。这样的思考对自己提高开发效率是最有帮助的。
- 要做到阶段性的review代码，然后优化
改bug的唯一目的是增强程序的健壮性。所以优化也是改Bug的一种。
项目的收工并不代表之后不做这份代码了。做完后要找时间review一下代码，对 代码结构/用户反馈/或者自己的单元测试结果进行分析。自己主动的去优化。
============================================================================
- 开发的任何细节都要有文档依据：
大部分情况下，开发初期的需求文档并不是最终版本，而是会随着开发做一些小更新（小更新是Ok允许的，如果说开发还在大更新需求的话就是双方的严重失误（比如说更改逻辑））
这导致开发时的一些细节，会觉得：这个地方需求会没有考虑到，但是又不影响主流程，所以会自己发挥。
但这其实很不严谨，任何的逻辑以及细节都要在 流程图里面过。所以一定要提出来。商讨出解决方案后第一时间更新到需求文档或者开发文档，这样可以保证出现问题时，锅绝对不在你身上。
（突然想到一个表情包，程序员最讨厌的四个事情：1.写文档 2.别人不写文档 3.写注释 4.别人不写注释， 人间真实）
- 如果在需求评审时，只是重点考虑到这个功能能不能实现，那其实这个评审会其实还是会给以后自己留坑。应该在之上，考虑到研发的新功能是否会影响已有的功能，如果影响到，影响的部分该怎么处理。这才是需求评审会时更该注意的一点。功能能不能做这个问题，只要你别来个根据手机环境来改变App主题颜色，那tmd肯定能做啊。
=======================================================================
-
总是写自己会的代码，错误肯定会少，但是同时学到的东西也不会很多。
-
如果自己不去努力的解决问题，那么自己也会成为团队里的问题。
====================================================================
-
《影响力》
-
《原则》
==================================================================================
-
Duplicated Code(重复的代码)
-
Long Method(过长方法)
-
Large Class(过大的类)
-
Long Parameter List(过长參数列)
-
Divergent Change(发散式修改)
一旦须要改动，我们希望可以找到系统的某一点，仅仅在该处做改动。
- Shotgun Surgery(霰弹式改动)
假设须要改动的代码散布四处。你不但非常难找到它们。也非常easy忘记某个重要的改动。
- Feature Envy(依恋情结)
最根本的原则是：将总是一起变化的东西放在一块儿。［数据］和[引用这些数据]的行为总是一起变化的。
- Data Cl
《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
【docs.qq.com/doc/DSkNLaERkbnFoS0ZF】 完整内容开源分享
umps(数据泥团)
这些[总是绑在一起出现的数据]真应该放进属于它们自己的对象中。
- Primitive Obsession(基本类型偏执)
大多数编程环境都有两种数据：结构类型让你将数据组织成有意义的形式；基本类型则是构成结构型的积木块。
- Switch Statements(switch惊悚现身)
面向对象程序的一个最明显特征就是：少用switch(或case)语句。
- Parallel Inheritance Hierarchies(平等继承体系)
在这样的情况下。每当你为某个class添加一个subclass，必须也为其它已实现的兄弟class对应添加一个subclass。
- Lazy Class(冗赘类)
假设一个class的所得不值其身份。它就应该消失。
- Speculative Generality(夸夸其谈未来性)
当有人说“噢，我想我们总有一天须要做这事”并因而企图以各式各样的挂勾和特殊情况来处理一些非必要的事情，这样的坏味道就出现了。
- Temporary Field(令人迷惑的临时字段)
在变量未被使用的情况下推測当初其设置目的，会让你发疯。
- Message Chains(过度耦合的消息链)
实际代码中你看到的可能是一长串getThis()或一长串暂时变量。採取这样的方式，意味客户将与查找过程中的航行结构紧密耦合。
- Middle Man(中间转手人)
你或许会看到某个class接口有一半的方法都托付给其他class，这样就可能是过度运用。
- Inappropriate Intimacy(狎昵关系)
继承往往造成过度亲热，由于subclass对superclass的了解总是超过superclass的主观愿望。假设你认为该让这个孩子独自生活了，请运用Replace Inheritance with Delegation让它离开继承体系。
- Alternative Classes with Different Interfaces(异曲同工的类)
假设两个方法做同一件事，却有着不同的签名式。
-
Incomplete Library Class(不完美的程序类库)
-
Data Class(纯稚的数据类)
它们拥有一些字段，以及用于訪问这些字段的方法，除此之外一无长物。
21. Refused Bequest(被拒绝的遗赠)
Subclasses应该继承superclass的方法和数据。但假设它们不想或不须要继承，又该怎么办呢？它们得到全部礼物。却仅仅从中挑选几样来玩！按传统说法，这就意味继承体系设计错误。
22. Comments(过多的注释)
标签：改动,代码,编程,Class,工作效率,开发,文档,解析,class 来源： https://blog.csdn.net/m0_65638168/article/details/122158958
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。