1. 关心你的技艺. 没错, 开发软件是一个工程, 但是个人的技艺并不会就此埋没在其中
2. 思考你的工作. 设法理解你面临的每个问题的内在本质; 首先抓住事实, 而不是照搬别人的说法.
3. 提供各种选择. 不找蹩脚的借口. 要为自己的过错负责, 而不是找一个蹩脚的借口, 那无法改变事实, 不要说做不到, 而要说能够做什么来挽回.
4. 不要容忍破窗户. 低劣的设计, 错误的决策, 或是糟糕的代码, 如果没有足够的时间修理, 就用木板把它们钉起来--把出问题的代码放进注释, 或是显示 "未实现" 的消息, 或是用虚设的数据加以替代, 把情势保持在控制之下.
5. 做变化的催化剂. 有时你很清楚应该做什么, 甚至清楚应该怎样去做, 可是一旦是一群人来做这个事, 情况就麻烦了, 人人都有自己的小算盘, 而这就是你发挥作用的时候了, 自己先开始做, 然后表示如果增加...会更好, 带动整个群体.
6. 记住大图景. 又是因为想要追求一些细节而导致陷入了无尽的拖延, 在钻牛角尖中忘记自己的本意, 因此要时刻提醒自己, 这个项目的本源是什么.
7. 使质量成为需求问题. 开发软件时, 不仅要清楚用户要什么, 还要关注用户要的东西需要有多好. 无视质量而一味的增加新特性, 到后来不得不削减预算或是延迟工期可不是有素养的做法.
8. 定期为你的知识投资. 这是一个动荡的行业, 多样化的技能是你保持先进的秘诀, 你要做的是:
8.1. 每年至少学习一种新语言
8.2. 每季度阅读一本技术书籍
8.3. 也要阅读非技术书籍
8.4 实验不同的环境, 只在 windows 下工作, 就试试 Linux, 只用 IDE, 就试试使用 makefile 和 编辑器.
8.5 多参加论坛, 尤其是那些技术问答的论坛
9. 批判的思考你读到的和听到的. 小心一个陷阱, 就是 web 排名靠前的答案不一定就是好答案, 摆在显著位置的书不一定就是好书.
10. 怎么说和说什么同样重要.
说话前要了解你的听众:
10.1.1 你想让他们学到什么?
10.1.2 他们对你讲的什么感兴趣?
10.1.3 他们多富有经验?
10.1.4 他们想要多少细节?
10.1.5 你想要谁拥有这些信息?
发电子邮件的注意事项:
10.2.1 发送之前校对
10.2.2 让格式保持简单, 考虑收邮件的人查看时的情况
10.2.3 尽量使用纯文本, 而不是富文本
10.2.4 如果是引用别人的文件, 一定要注明出处, 并在征文中引用, 而不是当做附件.
10.2.5 不要冷嘲热讽, 除非你想让别人也攻击你.
10.2.6 发送之前要检查收件人名单
10.2.7 将电子邮件加以组织并存档
11. 代码的 DRY--Donnot Repeat Yourself
代码中的重复有四类:
11.1 强加的重复. 似乎无法选择--环境似乎要求重复
11.2 无意的重复 开发者就没意识到自己在重复
11.3 无耐性的重复, 开发者的偷懒, 他们重复只是因为复制粘贴更简单.
11.4 开发者之间重复. 团队之内的几个人重复了同样的信息
对于强加的重复:
人们常说, 好代码有许多注释, 人们也说, 糟糕的代码才需要许多注释, 没错, 人们就是如此多变, 那到底要不要注释? DRY 法则说, 高级说明才需要注释, 低级的知识可以直接的体现在代码中. 否则, 每一次的改变都意味着注释的改变 ,而不可信任的注释比没有注释的代码还要糟糕.
无意的重复
考察以下代码:
class Line
{
public:
Point start;
Point end;
double length;
};
乍一看上去还是挺合理的, 线段都有长度和端点, 但是你真的觉得知道两点的坐标会计算不出线段长度吗? 所以应该是:
class Line
{
public:
Point start;
Point end;
double length() {return start.DistanceTo(end);}
};
在开发过程中, 你可能因为性能的原因而违反 DRY 原则, 其解决方法是使影响局部化, 对 DRY 的违反保持在越小的范围越好. 如:
class Line
{
private:
bool _changed;
double _length;
Point _start;
Point _end;
public:
void Start(Point p){_start = p; changed = true;}
void End (Point p){_end = p; changed = true;}
void Start() const {return _start;}
void End() const {return _end;}
double Length()
{
if(_changed)
{
length = _start.DistanceTo(_end);
changed = false;
}
return _length;
}
};
无耐性的重复
每个项目都有时间压力, 这可能就使你想要拷贝之前的代码并做出一些改动. 这并是不是一个坏习惯取决于你代码的重用性. 如果你的对自己的代码不够有信心, 那么就要慎重考虑了.
开发者之间的重复
解决这个问题的方法似乎应该是鼓励开发者之间进行主动的交流, 设置论坛让讨(si)论(bi)更加容易.
12. 让复用变得容易. 些易于使且易于复用的代码, 这样的代码在以后做项目时就比临时写出的代码更容易.
13. 正交: 消除无关事物之间的影响. 如果你设计的组件是高内聚的, 那么你将得到两个好处:
13.1 提高生产率
13.1.1 改动得以局部化, 所以开发时间和测试时间都会得以降低. 比编写单个的大模块代码相比, 编写多个相对较小 的, 自足的组件会更加容易
12.1.2 促进复用: 如果你的组件具有明确而具体的, 良好定义的责任, 就可以用其最初实现者未曾想过的方式把他们与新的组件 组合起来
12.1.3 如果是对正交的组件进行组合, 那么假定某个组件做 M 件事情, 另一个组件做 N 件事情, 那么结果就能做 M * N 件事情.
12.2 降低风险
12.2.1 有问题的代码区被隔离开来, 如果每个模块有毛病, 它不太可能把问题扩散到系统的其余部分, 替换也较为容 易.
12.2.2 系统更加健壮: 对特定区域的每一个小改动其影响都将局限在该区域中.
12.2.3 不会被特定的供应商, 产品或是平台绑在一起, 因为与这些第三方组件的接口都将被隔离在全部开发的较小部分中.
如下技术有助于维持正交性:
1. 让你的代码解耦. 高内聚, 低耦合, 如果你想要改变对象的状态, 就让这个对象替你去做, 这样代码就会保持与其他代码间的隔离.
2. 避免使用全局数据. 当你代码引用全局数据时, 就意味着与其他引用全局数据的代码绑在了一起所以要将代码尽量模块化.
3. 避免些相似的函数. 你可能会遇到重复的结构, 这就需要设计模式来帮助你了.