程序员如何高效开展开发工作？最近比较流行的一个说法是10xprogrammers，即10倍的程序员，意思是一个好的程序员的工作效率是普通程序员的10倍。做到这一点并不容易，需要在编程技巧、工作方法、工具使用等方面进行全面提升。第一条原则：抽象与分治拿到任务后，我们首先要做的就是定义模块，也就是抽象，然后分治。为了方便理解，给大家分享一个案例，几个前后端开发者在Facebook同时开发一个功能。该功能由一名前端开发人员和两名后端开发人员完成。整个开发过程至少涉及三个抽象和分治的操作：第一步，自然拆分前后端模块。这个时候前后端开发者肯定会一起讨论，明确前后端代码运行的流程，后端需要提供的API，以及交付这些的时间蜜蜂。第二步，两个后端开发人员拆分后端工作，确定各自的工作任务和边界。第三步，每个开发人员对自己负责的部分进行抽象和拆分。在这个过程中，需要理清模块之间的依赖关系，尽快确定接口规范和可调用性。比如在前后端分离中，往往会采用这些步骤来处理API：1.前后端开发人员一起讨论，明确需要的API。2、后台人员先实现API的Mock，返回符合格式规范的数据。在此过程中，后端开发人员会尽快向其他后端和前端开发人员发出代码审查请求，以确保格式正确。3、mock实现后，第一时间推送到主仓库的master（即origin/master），第一时间部署到内测环境，方便前端开发人员使用使用内测环境进行开发调试。4.这些API还没有面向用户，通常先使用功能开关，让它们只对公司开发人员可见。这样即使将API代码部署到origin/master上的生产环境，也不会影响到用户。通过这样的操作，就顺利完成了前后端任务的拆分。提高抽象和分治效率的一个技巧是在设计代码结构时注意寻找合适的设计模式。设计模式是指在设计过程中可以重复使用，可以解决特定问题的设计方法。最经典的是《设计模式：可复用面向对象软件的基础》和《企业应用架构模式》中列出的企业软件架构的23种设计模式。同时，还要注意公司内部具体的共性模式。这些模式在实践中被证明是有效的，并且被广泛传播并且易于理解。它们可以作为您进行模块拆分的参考。在实现功能的过程中，分而治之的思想也会处处体现。最重要的表现就是每个开发者都会尽可能让他们的代码原子化。代码原子性意味着提交包含不可分割的功能、修复或优化。在实际工作中，函数往往比较大。如果只用一次commit来完成一个功能，那么这个commit往往比较大，所以我们需要把这个功能拆分成子功能。比如某个后端API的实现，我们很可能会拆分成数据模型和API业务两部分，但是如果这样的提交量还是太大，我们可以进一步拆分成更小的部分，划分API业务分为两部分：重构和添加新的业务部分。简而言之，我们的目标是每次提交都能够独立完成一些任务，但不要太大。一般来说，一次commit通常不会超过800行代码。第二条原则：快速迭代第一，不追求完美，不过度规划，尽快实现功能，通过不断迭代完善。一个优秀的架构往往不是设计出来的，而是在实现过程中逐渐发展完善的。Facebook有一个常见的海报标语，叫做“Doneisbetterthanperfect”，意思是完成比完美更重要。为了实现快速迭代，我们注重功能设计和实现的简单性。一些开发人员技术性太强，花费大量时间设计漂亮而复杂的系统。这样做没有问题，但一定要有个度，切不可拿大锤杀鸡。因为复杂的系统虽然精致，但往往不容易看懂，维护成本比较高，而且不容易修改。所以我们在Facebook开发的时候，尽量采用简单实用的设计，然后快速迭代版本。第二，在设计的实现中，尽量让你的代码尽快运行起来，以便尽快验证结果。我们经常先实现一个可以工作的脚手架，然后继续往里面添加内容。在工作中，因为你经常在一个比较大的系统中工作，你不能轻易地运行新的代码。此时，我们可以编写脚本或单元测试用例来触发新编写的代码。通常我们更喜欢使用后者，因为这些测试用例可以在功能开发完成上线后继续使用，保证代码质量。在我看来，在开发过程中，能够触发新写的代码来帮助我开发，是单元测试的一个重要作用。第三，为了快速验证，一个重要的做法是设置本地代码检查，包括静态扫描，相关单元测试的方便操作，以及IDE可以进行的实时检查。第四，代码写好后，第一时间提交到主代码仓库，不要阻塞其他开发者。其实这也是代码提交原子性的另一个重要特性，即代码提交的原子性可以保证主代码仓库理论上可以随时基于master分支上的任何提交构建一个可运行的直接面向用户.产品。这样每个开发者都可以随时基于origin/master进行开发，从而保证Facebook的千人共享骨干开发时间，分而治之可以顺利进行。关于代码提交的原子性，我还有一个小技巧，就是如果当前写的代码提交确实不方便马上push到origin/master分支，我们也可以频繁的fetchorigin/master代码到本地，并在本地重新设置org/master以解决冲突。这样可以保证我们开发的代码是基于最新的主仓库代码，从而减少代码完成后推送时发生冲突的可能性。第三个原则：不要做重复的事情。不要做重复的事情。这是很多开发模式的基础，也是我们非常熟悉的开发原则。比如我们把一段经常用到的代码封装成一个函数，在用到的地方直接调用这个函数。代码逻辑的重复不仅浪费工作量，而且大大降低了代码的质量和可维护性。所以，我们在开发的时候，需要注意重复的代码逻辑，并进行适当的处??理。具体来说，首先是寻找重复的逻辑和代码。在实现功能之前，我们会花一些时间在内部代码仓库和知识库中搜索，寻找是否有类似的功能实现，以及一些底层的可复用库。在这个过程中，我们也可以直接联系类似功能的实现者进行讨论，寻求帮助。此外，一些IDE，如IntellijIDEA，可以在编码过程中自动检测项目中可能存在的重复代码。找到重复的逻辑和代码后，主要的处理方式是将公共部分抽象出来，封装成模块、类、函数等结构。如果在开发新功能时发现需要重构，一种常见且有效的方式是先用少量commit完成重构，然后再用少量commit在重构的基础上实现新功能。
