和斯坦福博士写代码的一个月

近一个月，闭关开发了一个面向海外的项目，合作的对象是斯坦福和麻省理工的博士，很荣幸能够和这些全球顶尖大学毕业的大牛合作，今天，趁着周末总结下自己的一些感受。

1. 英语是硬伤

因为项目是面向海外，整个合作全程是英语，这就一览无遗地暴露出自己的英文短板，特别是口语，在技术评审过程和讨论中，自己捉襟见肘的英文，只能不断的通过技术流程图和文字来弥补口语表达的不足。

最开始合作时比较羞涩，毕竟知道自己的英语有几斤几两，后面慢慢的放开，把自己的英语老本和盘托出，不过这也坚定了自己加强英文的决心，毕竟做程序开发，英语功底直接决定你理解英文资料的速度和程度。

2. 编程语言要多样

我自己最常用的是 java，但这次项目开发的主要语言是python，另外还涉及到C/C++, java, nodejs。尽管python，C/C++都有所了解，但是，要像 Java一样轻松驾驭去开发这么庞大的工程还是有点吃力。而在合作的过程中，发现他们语言的全能性，python，Java，C++，前端语言，他们都可以平滑切换，绝对的全栈工程师。

这个或许跟每个国家IT环境不一样有很大的关系，但是，作为 Java程序员，我个人还是比较建议再掌握一门动态语言，首选是python，像目前比较主流的数据分析、机器学习、科学计算、自动化和游戏开发等，Python绝对功不可没。另外，通过两种语言的对比，你能更好的看清每种语言的优点和不足，在日常开发中，或许就能借鉴另外一种语言的优点。

3. CR的重要性

CR，就是我们常说的Code Review（代码审查）。在国内的公司工作了这么多年，会做 CR的公司很少，包括一线大厂，能严格执行 CR的更是微乎其微，很多人说是因为业务太多，没有时间做CR，但是，究其原因是国内没有 CR的基因，技术管理者不推动，底层开发人员借着业务繁忙的理由，所以 CR就形同虚设。

下面给了几张项目CR的截图，因为涉及到商业隐私，所以部分信息被打码了：

图一：对于错误的实现，CR 会指正和给出正解。

图二：展示了 CR 甚至细化到了Doc文档级别。

图三：展示了 CR 过程中的探讨，给出自己意见的同时也征询组员更多的idea

CR看似很费时，反反复复的修改和讨论，但是，它和技术方案的讨论不一样，CR针对的是技术方案已经成型的代码实现，所以这个过程更能体现出不同技术人员对同一个技术方案的的思考和实现方式，对于整个项目的质量有大大的提高，另外对于开发者之间的磨合是一个很好的润滑剂。

4. 包容

越优秀的人越懂得包容。这句话放到这个项目上最合适，一个是对于我英语水平的包容。一个是对我 Python 掌握程度的包容。通过上面部分 CR截图也能体现出来。有了这些包容，让我可以更快，更有信心的融入到项目开发。

5. 较真

对于代码实现，技术方案的较真，通过上面的 CR截图也可以体现，他们对于代码的较真可以小到一个Doc文档和标点符号，以及代码的格式化，对于代码性能可以通过大量的技术测试和对比，甚至这块代码不是他们负责的，这个或许就是我们说的技术洁癖和极客精神。

依然记得几年前的一个技术峰会上，某大牛说：中国的码农千千万万，如何让你的代码有亮点，那就是不断的抠细节，大到技术架构，小到标点符号，然后不断的重构，重构。

总结

1. 通过这个项目，让我有幸见识了从 Google，AWS出来的优秀程序员的编码习惯。
2. 学英语绝对不是崇洋媚外，它在一定程度上绝对了程序员的技术高度和深度，可以观察你身边优秀的技术人员，英语是不是都不差。
3. 一定要向优秀的人靠近，和他们一起写代码，勇敢的让他们帮你CR，在交流和讨论中获取更多的葵花宝典；
4. 程序员是一个终身学习的职业，一定要持续学习；