code review 应该关注代码风格统一和知识分享，在这个场合少提议重新设计。应该关注代码做了什么，而不是谁写了这段代码。否则这种建议很容易被写代码的人视作对他的批评，最终演变成互撕，或者消极参与。
对于优化的建议，不妨换个思路。不是建议“他的”代码应该怎样，而是分享“我觉得”更好的设计知识。下次 reviewer 或者结对的时候给他 show 你的方法。如果真的有先进性，他自然会借鉴。

从需求开始，需求里的名词就是一个候选的类。然后把动作围绕名词放好，这些是候选的类的方法。
以你举的例子，名词计算器可能就是一个类，加减之类的动作是它的方法。
进一步引申的话，假设要实现的是一个实体的计算器，那种摆在桌上按按钮，有个液晶屏的那种。
你会发现因为有状态，比如按了按钮 2 以后，如果前面按的是 1 ，显示 12 。如果前面按的是 1 +，显示 2 。结果和前面按的按钮有关，这种情况下用 C 风格的代码写就会相当不自然。
如果用面向对象方式，“计算器”是一个类，“按按钮”是它的一个方法。“按钮”也是一个类，它会作为按按钮的参数传给计算器。每次方法操作后，计算器的状态变化，记录在它的内部。通过“显示”方法把当前状态输出出来。
进一步复杂化的话，比如要代码控制液晶屏上的灯，每个数字由 8 个灯组成。那么“液晶屏”是一个类，有“显示数字”方法。计算器调用这个方法把要显示的结果传入即可。
这样虽然整体的复杂度提高了。但是显示的逻辑并不会影响到计算器的逻辑，因为两个类担负了不同的职责。只要它们之间的接口没有改变，一方内部的复杂度不会传染到另一部分。

读第一句话就发现三观差异太大的话，果断 block 有益身心健康
改变从 block 做起

有坑，
var arr = [0];
arr[100] = 100;
两种循环的结果会有不同
for (var i =0;i<arr.length;i++) {
console.log(i);
}
//0, 99 次 undefine ， 100

for (var i in arr) {
console.log(arr[i]);
}
//0, 100

Vi 的最核心特点不在于更高效，而是更抽象。与其说是一个文本编辑器，不如说是一门操作文本的语言。
所以我认为程序员确实应该学学 Vi ，不在于这样写高效，而是多了一个视角把敲代码这件事本身代码化。

@sfree2005 选择困难的过程中也在花时间呀，想开点。

很明显是 id ，应该在内部系统可以直接链接到个人信息，包括提醒提到的人。就像 V2 上 @某人一样。

学呗，多学一样又不会掉块肉。

掌握 vim 不是靠学习，而是靠练习

上学的时候英语一直在及格线挣扎，感觉完全记不住单词。说和写更无从谈起。
30 多岁以后由于工作原因必须使用英语， 5 年下来可以基本可以与老外进行书面和口头的交流。当然老外是不是一直在忍耐我稀烂的水平就不得而知了。
我的个人体验。
首先要练听，而不是背单词。我第一次有感觉是有次书面看到一个词的时候，突然醒悟这不就是平时老外巴拉巴拉老说的词嘛。也就是说首先耳朵能分辨出这个词，然后才是脑子明白它的意思，再下面才是能说出来以及拼写。
这种感觉很像认识某个人，有些人可能我并不知道他的名字，对他的各种情况也一无所知。但是因为住在附近天天见，所以打个照面就能认出来。相反，如果给我 100 份简历，列名每个人的姓名身高体重三围外加 10 张照片。然后让我去大街上找出这些人。我是很难做到的。

有了一定基础后我现在开始背单词，感觉就没有那么痛苦了。相反倒是感受到了以前上学时从来没有的乐趣。不过我所谓背单词也仅仅是看到听到能想到意思，没要求自己拼写出来。

不过，首先的首先，是要能在听到乌拉乌拉一片不懂的话的时候，不紧张。随它去吧，迟早有天能听懂的。这样才不会影响听后续的内容，也有利于保持信心不会早早的就挫败放弃了。

TDD 的难点在于： 1 ，小步前进； 2 ，重构
小步前进做得好的话，你会发现连 print 调试都不需要。 unit test 的结果已经足够判断错误的位置了。
如果小步前进做不好，很快会陷入长时间无法通过测试。开发进程停滞
如果对重构，代码味道等掌握的不不够，会发现长时间的反复增加同质行为，却无法改进代码设计
TDD 并不是简单的流程，只要听听步骤，它需要进行一定的练习才能真正掌握。严格来说这种练习是无止境的，因为重构涉及的就是最细节的设计，而设计能力永远都有提高的空间。

如果真的感兴趣的话可以平时做些题目。
推荐 http://cyber-dojo.org, 在上面可以选各种语言和各种练习题目，进行 TDD 开发。每次测试系统都会保留代码历史。
这里有篇文章介绍 http://coding-is-like-cooking.info/2013/01/setting-up-a-new-code-kata-in-cyber-dojo/

回答你的问题的时候，我本想在这个站点上找些 Python 的代码，却没有发现合适的。所以就做了个没做过的练习。题目的是把数字转换为英文名字：比如 310 --> three hundred and ten
打开链接后点页面上面的绿色或者红色圆点可以查看每次测试的记录。
http://cyber-dojo.org/kata/edit/F53C57?avatar=antelope

我对 Python 不是很熟，这道题以前也没有自己做过。总共用时约 2 个小时，测试了 90 多次。
从历史记录中可以看到我犯过很多低级错误，也可以看到是怎么样利用 TDD 逐步解决问题的。

我做过几年的银行业软件，就我见到的系统确实很多生产环境中是不用外键的。原因和正式代码中是否使用断言类似。理论上来说，这些约束有助于维护系统的一致性。但是问题在于，不一致了，又怎么样呢？

在理想世界里，不论数据，代码还是输入输出都是有条有理的。而现实中却常常要面对历史遗留代码和数据，低质量的输入，以及变化无常的输出等等不那么有条理的情况。那么，比如一个系统运行到某个点时，发现某项检查与预期不一致的时候。停止整个系统真的是最好的选择么？又或者输入数据的时候某个字段不一致，因而拒绝整条数据真的是最合理的么？

另一个问题是不方便，当需要批量表数据，调整表结构或者更改程序逻辑的时候，这些约束经常会对开发人员造成困扰。虽然一般来说各种数据库都有暂时关闭约束的机制，但是确实把问题复杂化了。
而且，不同于 UI 上对随机的普通用户操作的校验，或者系统对恶意攻击者的安全性检查，数据库外键这类约束阻止掉的操作，来自于系统的开发和维护人员。一般来说他们最了解系统的内部结构，很清楚自己在做什么，对系统的一切有着最高的权限。这时候他们更容易觉得这种约束烦人而不是可靠。

@laoyur
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

You know how Ken Thompson and Dennis Ritchie created Unix on a PDP-7 in 1969?
Well around 1971 they upgraded to a PDP-11 with a pair of RK05 disk packs (1.5
megabytes each) for storage.

When the operating system grew too big to fit on the first RK05 disk pack (their
root filesystem) they let it leak into the second one, which is where all the
user home directories lived (which is why the mount was called /usr). They
replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and
wrote files to those new directories because their original disk was out of
space. When they got a third disk, they mounted it on /home and relocated all
the user directories to there so the OS could consume all the space on both
disks and grow to THREE WHOLE MEGABYTES (ooooh!).

养猪场场长：今天找大家来，主要是想讨论讨论怎么更好的吃猪肉的问题。比如是炒还是煎炸，或者腌制熏制等等。希望大家解放思想，开动脑筋，知无不言，言无不尽。共同为我们这个养猪场献计献策。

沉默许久……

猪 A ：请问领导，那个……，我们实际上不想被吃诶。

场长：你这个同志啊，怎么刚一讨论就跑题了。来来来，咱们还是集中在今天的议题上啊。大家踊跃发言啊。

输出结果是正确的

起始： a1 = Account 1 {id: '001', money:100}

-> EditAccount
Account 1 {id: '001', money:200}
Account 1' {id: '002', money:100} //退出 EditAccount 时被回收
a1 = Account 1 {id: '001', money:200}

-> ChangeAccount
Account 1 {id: '001', money:400} //退出 ChangeAccount 时被回收
Account 2 {id: '002', money:100}
a1 = Account 2 {id: '002', money:100}

要得到你想要的结果，需要把
```
a.Money = a.Money * 2;
a = new Account() { ID = "002" };
```
这两句的顺序互换

要求中有：
能够承受压力
能够适应出差

招聘启事常年挂在网站上

@jinyang656 请问老人翻译做经验丰富的人有何依据？
究竟老人这个词的本意为经验丰富，还是年纪老？
现在的口语中，确实有“老人”指代资历老而非年龄大的情况。这类语境中都在一个具有一定流动性的组织或场合里。比如公司，军队，或者 V2EX 。
然而在这句习语形成的年代，中国社会应该还主要处在传统乡村社会中。大部分人所属的组织就是乡亲邻里。在这种场合下，对普通人而言资历老的人必然也是年龄老的。可能只有很少的群体，比如官员由于考取功名晚，所以有可能面对年龄较小的官场老人。又或者比如帮会成员。但我不相信这么少数的群体会是形成这个习语的来源。
我检索了一下明清小说中老人出现的情况，翻看了前面 100 多个结果，似乎没有看到有老人指代经验丰富的人的情况。
https://www.google.com.hk/search?hl=zh-CN&q=%E6%98%8E%E6%B8%85%E5%B0%8F%E8%AF%B4&oq=&gws_rd=cr&ei=4c4dVvDjHMSOmwWWq7mgDg

@quericy
“知识的诅咒”——一旦我们知道某样东西，就会很难想象不知道他时是什么样子。所以工程师无法跟顾客沟通；差劲的老师不知道怎么教学生。
也许某些经验丰富的“老人”就是因为丧失了与“新人”沟通的能力，唯一能做的就是事后诸葛的说“我早告诉过你了”