王淮是Facebook的早期员工，也是Facebook内部第二位中国籍工程师和第一位研发经理，曾经负责支付后台和安全系统，担任反欺诈部门的技术经理。最近，他分享了一些基本的码农原则，包括代码结构、测试重要性等。
正确性是第一要求，他认为“不能解决问题的代码是耍流氓”。
然后是代码结构，王淮觉得结构体现逻辑：
第一步，第二步，需要什么数据，需要做什么处理，处理完了结果到那里去，都应该在结构中被很好的体现出来。
结构体现设计。 设计一定要清晰。我的经验来看，一般来说，在设计结构图上面的每个组件都对应着自己的类，然后之间或类内部的通信通过成员函数来完成。
他提供一个可借鉴的做法：在一个大的功能实现过程中，给出第一个diff（提交代码增量）的时候，可以只把结构当做一个diff，里面的函数可以是 空的(place holder，作为占位符)。 把数据的生成和界面的展示分开来。典型的可以按照MVC的模式来，但也可以只把数据和UI界面分开来的比较轻量级的做法。结构应当是提交代码审查的时候最 最关注的地方。最需要问的问题就是“这个diff号称要解决的问题被正确解决了吗？”
测试的重要性不言而喻。王淮指出：
不论你再正确，还是有错误的时候。通过（相对）公正的测试一是来减少自己被绕到代码里的几率，二是让后续的或者别人的改动对自己代码不经意的破坏被最快的展现出来。测试应该把类主要的功能都测一遍。测试也应该把类和其他类最重要的集成部分也测一遍。
对于提交代码增量的问题，王淮说了几个需要注意的事项：
面向对象还是面向函数，王淮指出，Java本身就是面向对象，所以这个问题不大。但千万不要出现披着面向对象的外皮，在类里面写超长的面向函数的处理。这种情况下，尽可能的分流成辅助函数。
关于代码规范，他举了一些简单的例子：比如文件名，变量或函数名的命名规范，分行的前置空2个空格或4个；每行的字数（不应超过80字符）；如何使 用public/private/protected；用左右括号的原则；空行的使用；文件和代码comments的位置 （比如，代码注释只能单独成行）；对“// TODO:”的使用规范；宏、常量的使用。这里没有特别的哪一种样式一定更对，但是需要有一个大家统一的指南，一起遵守，让整体的代码有统一的风格和标 准。最大的好处就是有利于可读性，可读性的好坏决定着维护成本。
注释应当简洁但充分。有些人觉得代码应该自说名。王淮不大同意，代码是实现细节，适当的在意图上给予说明，可以大幅度的减少读代码的人的烦恼。
代码审查越来越受到重视，王淮指出：
说到代码审查，thoughtbot公司最近在上发布了自己的代码审查原则，其中几个值得关注的要点包括：
来自：
人的价值，在遭受诱-惑的一瞬间被决定
