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

在之后新的专案中，便可以拿上一个案子打下来的根本一再重复操纵再操纵。甚至最后竟然还有 Event Generator 这种东西…（Authenication ， Rails Admin， 搜索引擎优化， …etc.）。

3. 法度自己即注解

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

4. 极力写下所有的 documentation

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

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

这样会对整个团队水平的跃升会有很是强年夜的正面效益。同时在人员活动（新进或去职时，冲击会很是很是的小。

因为至少很多的 "basic" 的教育本钱，在这部分会几近于 0。一路都在 startup 的历练，让我很早就理解到一件事，人员活动几近是无可避免的，所以重要的是要怎样让人员活动造成的冲击更小。

在新创事业让同事投资一项新手艺，也是很昂贵的。所以要学的话，年夜家一定也都全都要会，不然就会一直很贵。

这是 documentation 可以带来的价值。

5. 要有测试情况和政策

从昂贵的教训里面我学到的就是一定要有测试情况和 policy。在 Rails 中将情况切分成好几份，并没有超坚苦。并且一定要有测试情况（staging），是因为每小我开辟的情况不一样，在当下核心在自己电脑前，很多设计其实不会斟酌那么多。丢上远程办事器你才会知道炸失落一年夜片，或是性能极端欠好。这都是会伤害商业信用或弄砸买卖的（比如说你跟客户谈好明天on档一支几十万的告白，但明天因为人为疏失倒站一天，请问你要去挪谁的队列给他，一天到晚产生这样的事。谁要跟你做生意？）。

至于政策就更重要了。

很多加班的状况其实都是不需要产生的。比如说在头脑不清醒的时候写了烂 code commit 上去。致使自己清醒时要去清理这摊烂泥。在吃饭前或下班前摆设了最新版的 code，成果中午倒站数小时；原本可以准时下班，十点都走不了。

但写了好东西不直接 commit master 和不马上摆设，会让 RD 很是痒。这种病连我都不克不及倖免。

可是商业网站是不克不及一天到晚失火的，团队仍是有人要去捍卫这种年夜局。所以最后也只好执行了这样的规范：

1、写功能一律上 feature branch

2、上线前必须使用开辟办事器， apply feature branch 测过一轮

3、绝对不在中午 11 点 - 12:00 摆设，绝对不在 17:00 后摆设。

4、摆设流程必须使用东西自动化，失事要能反转展转。

5、执行了这样的规定之后，几近就没有人需要饿着肚子修 bug，三更因为软件的问题跳起来加班修理了。

因为我深信：持久处在失火/救火的情况下，会快速减低一个团队的战力。

热血的投入通常会让人有假象，我投入的工时越高，功能会越好。事实上这是一个完全的伪命题。而创业早期的不稳定，忙碌，失火，更让你会有只要我努力加班，一切就改良的错觉。肾上腺素最多只能让你撑三个月，接下来一切城市破灭的。作一个网站要到可以出场，年夜家比得是命长，而不是 Startup weekend 冠军。

6. PM 的话听听当参考就好，但要好好沟通

在很多情形下，PM 也许打算出来的方案 A，需要 10小时。但你知道可以把它改酿成方案 B，只需要 3 小时。但前提是，你要好好的去追问出来，为什么他会做出 A 设计案这样。不成否定台湾具有专业素养的 PM 极端稀少，能遇到一个就是烧香了。所以很年夜的水平遇到的多是一个只会照抄其他网站画架构图的人，或是负责卖告白的Sales 自己兼，但这都没关系。要紧的是你要问出为何这样设计，因为他的外行水平可能会让他估出一个让公司严重赔本的实作案，你却没阻止他。或是这个案子架构是公道的公司标的目的，但你却误解背后的设计原理擅自修改而失效：