写 Code 规则怎么规范？同事和我从社群中吸收了很多最佳实践，我们把这些东西整理出来变成新手指南、最佳实践，甚至是包装成 Gem 和 Generator，越后进的开发者能花越少的时间追上前辈，在短时间他们的作品也能跟前辈一样预先搭载 Best Practices。我最近也开始在撰写另外一本书 Essential Rails Pattern for Beginners。

Rails 本身还有丰富的生态系统，和预设的架构最佳实践就更不用说了。

新创团队资源很少，人事预算没有这么够，反而要巧妙的运用天然资源并让团体战力很高才行。

2. 功能设计给当下使用，考虑一定程度的扩充性：

我也不相信在新创团队有人可以预知未来，即使很多东西看起来未来往那个方向扩充很合理。对我来说，我在设计功能时并不会 overthinking，甚至我也禁止同事 overthinking。因为专案中最高的原则是 get things done，not over design。

但这不代表不需要在设计上不需要留一定程度的扩充性，在内部的工作流程通常最后一道是有重构整理空间的。在这时候同事会把杂乱的 code，整理回当初规范中必须写的样子。如果这是常见功能，一再出现，就必须整理成程序库，或架构模式。一但是模式，扩充性就留出来了。

在之后新的专案中，就可以拿上一个案子打下来的基础一再重复利用再利用。甚至最后竟然还有 Event Generator 这种东西…（Authenication ， Rails Admin， SEO， …etc.）。

3. 程序本身即注解

一般软件实践上本身也不赞成写注解。而是鼓励程式本身即要可以表达自己的行为。如果写的程式乱七八糟让人看不懂，进审查时是会被回退的。我们团队能够被接受的程式是可以写得很笨拙，但每个同事都看得懂。因为笨拙但能理解，其他前辈有时间可以去重构。但乱写，之后就没人动得了了。

4. 尽力写下所有的 documentation

世界上没有人能够写出一份完整的系统架构书可以详尽的描述现在系统上真实的状况。但是一个好的 issue tracking system 和写的 commit log，可以能够很好的协助你了解为什么现在系统会是这样设计的，为什么当时会做出这样的决策，导致程序必须要这样设计。

在新人训练期时，我通常会训练新人要有将任何实作上遇到任何的细节和状况详细 document 在票上的习惯。而在完成整个专案时或者是技术架构稍具规模雏形时，要把这些 ticket 上的笔记梳理纪录下来。

这样会对整个团队程度的跃升会有非常强大的正面效益。同时在人员流动（新进或离职时，冲击会非常非常的小。