创新公司如何快速、低成本的完成网站开发？

我是一个软件工程师，过去六年我都在开发网站。在新创公司里，速度节省时间、时间就是金钱、金钱就可以再去请更多工程师让整个开发速度更快。学校并没有教很多“软体工程”的方法，或是怎样才算是一个好的Programmer。这些东西在台湾业界其实不存在的，大家都是边做边摸，从经验中学习。我从书籍上和网路上学了很多能让团队更有效率的做事方法，因为我相信我在新创团队里我必须先这样，用业界公认觉得快，且快得有道理的方式。底下是几点可以和大家分享的。

1. 让全团队都用一个成熟的开发框架和环境：

我的专长是 Ruby on Rails。我并没有偏好推荐别人如果现在是用 PHP 或 .NET 或 JAVA，就要不计成本的导入新框架。就像我其实也没有很喜欢硬导入 Scala 或 Node.js 一样。它们可以在它们派得上用途的地方加分，但是绝对不能是主体。道理很简单，我不认为他们成熟到够让所有成员快速上手，不重造轮子。

一般团队喜欢用 PHP。因为 PHP 工程师好找，Rails 工程师不好找。但在我一路走下来的经验，我认为这是一个“假命题”。因为在人力市场和公司实际运作的状况里面，你会发现这个命题不怎么牢靠。没错，你是找的到 PHP 工程师，但很抱歉，很多人写的 code 是不能用（更精确的说是 write only ） 的居多。（我没有冒犯 PHP 开发者的意思）

塬因是 PHP 开发并没有太多一致性的规範，基本上就是爱怎么写就怎么写。这导致了即使你团队里面就算里面有一个很厉害的开发者，也是没有多大的用处。因为大家 coding style 不一样，甚至连网站结构也不一样。补人几乎是没有办法发挥到加成作用，大家只能各写各的，就算爆炸了也几乎只有当初的作者可以修。

这在我眼中是极度浪费团队战力的元兇。

Rails 没有这样的状况吗？这是我觉得 Rails 优势的地方，它是一个非常热门的 Framework（只有在台湾你可能没有感觉到他很热门）。因为这是一套 Framework，也就是它本身有很强的约束性，至少 MVC 和 routing 规则，一般就算新手也不会乱放的太离谱。写 code 有一定的潜规则存在。

开发中遇到任何东西发生错误了以后，开发者几乎可以用 Google 找到任何可能发生的塬因，修復完毕。而这几乎不是一般自建 Framework 可以比的上的地方，如果你在公司自建一套 Framework，基本上发生任何问题，最后几乎都得去烦当初设计的 Architect 才行。（这也是很浪费钱的地方，因为 Architect 的薪水都很贵）。

学习曲线过高，我也不觉得这件事真的存在。Rails 高手是难寻没有错，但是 Rails 中低手只要训练得当，生产力也是非常惊人。因此只要把重心放在如何协助一般想入门者，可以快速克服入门几大门槛（搞定开发环境，RESTful，Plugin，Debug，Deploy），剩下的部分就可以靠网路教材和实战训练出来。这也是我发明Rails 101 的塬因。

我设计这一套教材的目的是要让所有新进的开发者，在最长两週时间内要学完基本 Linux 指令、Git、Rails 所有基础的知识、佈署、SCSS 撰写等等，一个月之内就能上战场跟我们一起开发功能开发新网站。这样的进度很夸张吗？不，不夸张。这里的每一个开发者都有这样的程度，他们有些人应徵时是连 Rails 都不会写的。你能相信连 T 客邦的 PM 和 ART 他们也会写 Rails 吗？（ no kidding）

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

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

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

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

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

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

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

3. 程式本身即註解

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

4. 尽力写下所有的 documentation

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

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

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

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

在新创事业让同事投资一项新技术，也是很昂贵的。所以要学的话，大家一定也都全都要会，否则就会一直很贵。

这是 documentation 可以带来的价值。

标签： 网站 ��

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点！
本站所提供的图片等素材，版权归原作者所有，如需使用，请与原作者联系。