序言
能不能让正确的原则指导真确的行动本身,其实就是区分是否是高手的一个显著标志
加强知识的内化速度的方法:
- 频繁的高强度的外部刺激
- 自主的有意识的反复提醒(主要)
阅读方法:
先大致记得和理解里面的Tip,然后每周争取实践2-3个tip。强化内在记忆,不要浮于阅读
注重实效的哲学
我的源码让猫给吃了
所有弱点中,最大的弱点就是害怕暴露弱点。
负责
负责的意义: 不仅是要努力完成职责所在的项目,同时也包括,对各个以外情况的兼容处理,还包括对自身错误的理性分析,不东拼西凑借口。
也许你的对接方在错误中扮演了某种角色。但你可以选择提供结局方案,而不是直接尽快推脱责任。(顾客管理1.2)
谈话预演:在描述一个事实,现象的时候,先预演对方可能会说什么。
软件的熵
熵: 系统中无序的总量
软件系统熵最主要的原因:破窗户
破窗户: 一扇破窗户,只要有那么一段时间不修理。就会渐渐给建筑的居民带来一种废弃感–一种职权部门不关心这座建筑的感觉。于是有一扇窗户破了,人们开始乱扔垃圾,出现乱涂乱画。严重的结构损坏开始了。
Don’t Live with Broken Windows!
解决方法:
- 发现一个解决一个
- 没时间修理,把问题代码永注释做出标记,给后来人做出标示 表明当前的这个问题在控制之中
石头汤与青蛙
看了,不是很能理解
这个讲的道理,貌似是一个作为项目管理者的行事方式:
启动杂役:与其一开始就分配好规规整整的分工,可以先完成自身上的主线部分,然后给出Demo,告诉各自分工的人,他们的职责,以及他们对主线的贡献,能加快项目的推动。
足够好的软件
欲求更好,常把好事变糟
市场人员有需要信守的承诺,最终用户有基于交付时间表制定了的各种计划,公司有现金流方面的约束,无视这些用户的需求,一味给程序增加新特性,一次一次润饰代码,是毫无职业素养的。
我们要的是:在规定的时间内,在规定的功能需求内,保证代码的质量。
>质量应该成为需求问题
## 你的知识资产
>知识上的投资总能得到最好的回报
### 经营你的资产
定期投资 多元化:你知道的不同的事情越多,你就越有价值。底线:目前你所使用的几项技术的各种特性。
管理风险:不要把所有的技术鸡蛋放在一个篮子里 低买高卖: 新兴流行之前就掌握他,就像原始股上市一样刺激
重新评估和平衡: 定期评估
### 目标 每年至少一门新语言:不同语言 以不同方式解决相同的问题,学习不同语言可以拓宽你的思维(shell)
每季度阅读一本技术书籍=>每个月一本 也要阅读非技术书籍
上课 参加本地用户组织
折腾折腾环境(操作系统/IDE) 跟上潮流
上网
>学习的关键是什么:拓展你的思维,就是让你不要思维僵化,让你能想到,卧操,这特么也可以,使你向新的可能新和新的做事方式拓展。进行思想的”异花授粉”
### 学习的机会
不要就此止步
当在你的领域发现一个问题,不找出正确答案不要罢休!!! 因为他会重复出现的!!! 先去查资料
资料查不到去问人,还可以建立不同的人际资产，不同的解决方案 规划好自己的阅读和研究的时间!
## 交流
知道你想说什么 了解你的听众
选择时间,弄清目标听众当前的轻重缓急 选择目标听众的交流风格
美化文档find(选项)(参数) 与文档的使用者共同参与文档的撰写
做好倾听 立马回复
注重实效的途径
重复的危害
什么是维护: 重新组织和表达我们在系统中的知识!
这个过程不止在软件发布之后,确保软件的正常运行,同时也在开发中,由于qa,pm的活动而进行着。
为了使我们的开发过程更加可靠,并让我们的开发更加易于理解和维护,重点：
DRY-Don’t repeat yourself
系统中的每一项知识都必须有单一,无歧义,权威的表示。
强加的重复
Case:建立包含重复信息的文档,写一份包含有重复代码的文档,多目标平台开发常常带有重复代码。
信息的多种表示
问题: 再多平台需要表示同一信息。
case: 需要同时在客户端-服务器表示同一数据结构,类。
Ans: 过滤器/代码生成器
将共有特性存入数据库,在预处理时，根据数据库内容,生成当前代码库所需要的代码
问题: 代码中的文档
把低级的知识放在代码中,把注释留给高级的说明
在代码细节处的注释是不靠谱的,维护人员常常不会随着迭代同步更新代码
问题： 文档与代码
case: 由于实践紧迫,文档无法随着代码同步更新
问题：语言问题
Ans: 没什么简单的技术可以克服语言的这些需求
无意的重复
在设计类的时候,我们可能无意中出现了一些信息点上的重复。1
2
3
4
5
6
7class Line {
public:
Point start;
Point end;
double length;
}
例如在这个Case中,length显然可以通过start,end来求出,这个变量名出现了重复,每次start,end值出现了修改,length都会随之修改。
所以最好将其变为函数1
2
3
4
5
6class Line{
public:
Point start;
Point end;
double length(){return start.distanceTo(end)};
}
但是这个每次获取length,都会需要走length函数,如果后续要减少运算,采用缓存呢。
这就不得不违反DRY原则,但是使影响局部化 。保证对外依然不存在重复信息1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22class Line{
private:
bool changed;
double length;
Point start;
Point end;
public:
Point getStart(){return start};
Point getEnd(){return end};
void setStart(Point p){start=p;changed=true};
void setEnd(Point p){end=p;changed=true};
double getLength(){
if(changed){
lenth = start.distanceTo(end);
changed = false;
}
return length;
}
}
这么写,既保证了对外依然只暴露长度获取依然是通过函数的形式来保证,同时也使得能用缓存来进行优化。
总结:你的类中应该尽量保证初始元素的单一,可靠,嗯,怎么说呢,有点像,一个R维向量空间的线性无关向量组
无耐性的重复
欲速则不达
也许你现在可以节省几秒钟,但是后续却要损失好几个小时。
不要屈从于时间的压力,而做一些简单的复制粘贴的事情。
(营业状态!!获取)
开发者之间的重复
最简单的例子:掌柜商户Common类,各种奇奇怪怪的获取商户信息的Common方法
解决方法:
- 鼓励开发者互相主动交流
- review他人源代码,也鼓励他人review你的代码
正交性
什么是正交性
几何：两条直线相交成直角,他们就是正交的
计算机: 解耦,表示两个系统互相不依赖
正交的好处
Eliminate Effects Between Unrelated Things.
提高生产率
- 大模块被划分为n个小模块,小模块的开发时间,测试时间都比较少,且难度低
- 促进复用,组件之间可以随意组合,不再仅仅是定制化。
- 通过正交可以使生产率得以提高
降低风险
- 问题可以定位到单一模块
- 修改可以定位到单一模块
- 测试可以更加简单易行
正交原则
项目团队
如何划分良好的团队分工，取决于项目本身。通用意义上的：
- 基础设施
- 应用
判断团队正交性的方法:每次需求的改动造成的人员波及,波及越多，正交性越差
设计
工具箱与库
引入第三方库时:反思一下会对当前库类造成什么影响。
- 第三方库类是对象持久模型,正交
- 需要你在代码库中创建访问对象,不够正交,应将他们与具体代码隔离
编码
- 让你的代码保持解耦， 如果你需要改变一个对象的状态,让这个对象去做
- （无法理解 todo）避免使用全局数据,
- 避免编写相似的函数
基本工具
纯文本的威力
持久得知识存储方式是纯文本
不要使用二进制数据格式,我才word和pdf就算其中的一种,可以采用一些其他的格式,比如xml,markdown等等
缺点:
- 纯文本所需要的空间更大
- 纯文本的处理更加耗时
优点：
- 保证不过时
- 杠杆作用(万物皆文本)
- 易于测试,增删该查可以通过文本解析工具轻松分析出来
shell游戏
GUI的好处:所见即所得 GUI的坏处：所见即全部
强力编辑
精通一种编辑器
Use a Single Editor Well
然后做什么
感觉很有意思,就抄下来了
调试
调试心理学
要修正问题,而不是发出指责
bug是你的过错还是别人的过错,并不是真的很有关系.他仍然是你的问题。
