《
新创网站这样开发才够快_》文章地址：http://www.tfxk.com/wangyesheji/jianzhanjingyan/110A512012.htm
3、绝对不在中午 11 点 - 12:00 部署，绝对不在 17:00 后部署。
1、写功能一律上 feature branch
5、这是主要功能， 一定得这样作， 否则失去此系统意思
一般团队喜欢用 PHP。因为PHP工程师好找，Rails 工程师不好找。但在我一路走下来的教训，我认为这是一个假命题。因为在人力市场和公司实际运作的状况里面，你会发现这个命题不怎么坚固。没错，你是找的到 PHP 工程师，但很负疚，很多人写的代码是不能用（更准确的说是 write only ） 的居多。（我没有触犯 PHP 开发者的意思）
9. 少用 Fancy 的东西，实作前先估算成本与效益
我重要是想论述以前在T客邦的经验方法。T客邦在一年半里面，就从台湾 Alexa 400 名以外，冲进台湾 Alexa 100 名内。这一年半时间技术团队开发出了四个大网站，十数个子网站，和当面一群深沉的基础建设（HA， backup， PV stat， advertising system…etc.）。
8. 要追求一定以上的网页效能，tune 在刀口上
4、客户要求
但实作一个桌面版网站完整没必要。而在网站性能调整的时候，优先调整的也是界面性能，因为 C/P 值高很多，压缩一下 CSS 也许就可以省 3 秒。db 或程式语言 tune 的要逝世可能才省 0.1 秒。
我是一个软件工程师，从前六年我都在开发网站。在新创公司里，速度节俭时间、时间就是金钱、金钱就可以再去请更多工程师让整个开发速度更快。学校并没有教很多软件工程的方法，或是怎样才算是一个好的程序员。这些东西在台湾业界其实不存在的，大家都是边做边摸，从经验中学习。我从书籍上和网络上学了很多能让团队更有效力的做事方法，因为我信任我在新创团队里我必须先这样，用业界公认觉得快，且快得有道理的方法。底下是几点可以和大家分享的。
但写了好东西不直接 commit master 和不立刻部署，会让 RD 非常痒。这种病连我都不能?免。
1. 让全团队都用一个成熟的开发框架和环境：
不可否认有些开发者效能和设想力技术着实寻求过火，好比说甚至一开始就用 Backbone 写整个网站，或者是从头到尾使用 Node.js 写网站。这都是一开始就盘算写 mobile 版 web service 给 mobile phone 使用才需要做的事。因为 3G 的 Latency 其实太大，要努力的紧缩频宽使用量和追求页面 response time。
比方说一直追 Rails 新版，换上效力很好的 Ruby 1.9.2，改用 SCSS 去写 CSS，改用 CoffeeScript 写 JavaScript。Apply 新发现的 Asset Pipeline 架构。这些都是很新很棒的货色。（T 客邦都有，架构从最早的 2.3.2 始终 upgrade 到 3.1.3，行家人才晓得这样工程有多大）
原因是 PHP 开发并没有太多一致性的规范，基本上就是爱怎么写就怎么写。这导致了即使你团队里面就算里面有一个很厉害的开发者，也是没有多大的用途。因为大家 代码格局不一样，甚至连网站构造也不一样。补人几乎是没有措施施展到加成作用，大家只能各写各的，就算爆炸了也几乎只有当初的作者可以修。
但跟其他事物的情理其实是一样的，新的东西就有新危险。而且通常引入这些东西，不是自己一个人爽就好，是大家都要用的东西。
3. 程序本身即注解
所以不能是自己喜欢 B 就 B。开发一个系同一定有成本、预计收益，而实作的方案必需要去找出这两者的均衡点。这就是靠沟通沟通沟通…
3、ART 请求
2. 功效设计给当下应用，斟酌必定水平的裁减性：
从昂贵的教训里面我学到的就是一定要有测试环境和 policy。在 Rails 中将环境切分成好几份，并没有超艰苦。而且一定要有测试环境（staging），是因为每个人开发的环境不一样，在当下焦点在自己电脑前，很多设计并不会 考虑那么多。丢上远程服务器你才会知道炸掉一大片，或者是机能极度不好。这都是会损害贸易信誉或者搞砸交易的（比如说你跟客户谈好明天on档一支几十万的 广告，但来日因为人为疏失倒站一天，请问你要去挪谁的队列给他，一天到晚发生这样的事。谁要跟你做生意？）。
这样会对整个团队程度的跃升会有非常强盛的正面效益。同时在人员流动（新进或离任时，冲击会非常非常的小。
5、执行了这样的划定之后，几乎就没有人需要饿着肚子修 bug，深夜因为软件的问题跳起来加班修理了。
这在我眼中是极度挥霍团队战力的首恶。
我也不相信在新创团队有人可以预知将来，即便很多东西看起来未交往那个方向扩充很合理。对我来说，我在设计功能时并不会 overthinking，甚至我也制止同事 overthinking。因为专案中最高的准则是 get things done，not over design。
1 2 下一页
世界上没有人能够写出一份完全的体系架构书可以详尽的描写当初系统上实在的状况。但是一个好的 issue tracking system 和写的 commit log，可以能够很好的协助你懂得为什么现在系统会是这样设计的，为什么当时会做出这样的决议，导致程序必需要这样设计。
在良多情况下，PM 兴许计划出来的计划 A，需要 10小时。但你知道可以把它转变成方案 B，只须要 3 小时。但条件是，你要好好的去追问出来，为什么他会做出 A 设计案这样。不可否定台湾具备专业素养的 PM 极度稀疏，能碰到一个就是烧香了。所以很大的程度遇到的可能是一个只会照抄其他网站画架构图的人，或者是负责卖广告的Sales 自己兼，但这都没关系。要紧的是你要问出为何这样设计，因为他的外行程度可能会让他估出一个让公司重大赔本的实作案，你却没禁止他。或者是这个案子架构是 公道的公司方向，但你却曲解背地的设计原理擅自修正而生效：
新创团队资源很少，人事估算不这么够，反而要奇妙的应用自然资源并让集团战力很高才行。
Rails 本身还有丰盛的生态系统，和预设的架构最佳实践就更不必说了。
1、PM 路上随意抄
很多加班的状况其实都是不用要产生的。比如说在脑筋不苏醒的时候写了烂 code commit 上去。导致自己清醒时要去清算这摊烂泥。在吃饭前或下班前安排了最新版的 code，成果中午倒站数小时；底本可以准时放工，十点都走不了。
身为开发者，世界上天天会冒出许多新的好东西，这些不去玩玩看手切实会手痒。但是实在每引入一项都会有一定的本钱存在，而且效益/成本比不见得是你当初想的那样。
我的特长是 Ruby on Rails。我并没有偏好推举别人如果现在是用 PHP 或 .NET 或 JAVA，就要不计成本的导入新框架。就像我其实也没有很喜欢硬导入Scala 或 Node.js 一样。它们可以在它们派得上用处的地方加分，但是绝对不能是主体。道理很简略，我不认为他们成熟到够让所有成员快速上手，不重造轮子。
因为我坚信：长期处在失火/救火的环境下，会倏地减低一个团队的战力。
写 Code 规矩怎么标准？同事和我从社群中接收了很多最佳实践，我们把这些东西收拾出来变成新手指南、最佳实践，甚至是包装成 Gem 和 Generator，越落后的开发者能花越少的时间追上前辈，在短时间他们的作品也能跟前辈一样预先搭载 Best Practices。我最近也开端在撰写另外一本书 Essential Rails Pattern for Beginners。
7. 要写出一定程度的程序码
学习曲线过高，我也不感到这件事真的存在。Rails 高手是难寻没有错，然而 Rails 中低手只有训练切当，出产力也是十分惊人。因而只要把重心放在如何帮助普通想入门者，可以疾速战胜入门多少大门槛（搞定开发环境，RESTful，Plugin，Debug，Deploy），剩下的局部就可以靠网络教材跟实战练习出来。这也是我创造Rails 101 的起因。
至于政策就更重要了。
效能调校这件事，过与不迭都是不好的事。
任何举动，最好都要是能以尽量把成本压到差未几低，但效益都异常高。
个别软件实际上本身也不同意写注解。而是激励程式自身即要可以表白本人的行动。假如写的程式乌七八糟让人看不懂，进审查时是会被回退的。咱们团队可能被接收的程式是能够写得很愚笨，但每个共事都看得懂。由于笨拙但能懂得，其余先辈有时光可以去重构。但乱写，之后就没人动得了了。
开发中遇到任何东西发生过错了当前，开发者几乎可以用 Google 找到任何可能发生的原因，修复结束。而这几乎不是一般自建 Framework 可以比的上的地方，如果你在公司自建一套 Framework，基础上发生任何问题，最后几乎都得去烦当初设计的 Architect 才行。（这也是很糟蹋钱的地方，因为 Architect 的薪水都很贵）。
2、PM 自己爱好这么作
如果是新主意，则是在一个 event 或是小版面先行制造尝试后果。
5. 要有测试环境和政策
在新人训练期时，我通常会训练新人要有将任何实作上遇到任何的细节和状态具体 document 在票上的习惯。而在实现整个专案时或者是技术架构稍具范围雏形时，要把这些 ticket 上的笔记梳理纪录下来。
但这不代表不需要在设计上不需要留一定程度的扩充性，在内部的工作流程通常最后一道是有重构整理空间的。在这时候同事会把混乱的 code，整理回当初规范中必须写的样子。如果这是常见功能，一再呈现，就必须整理成程序库，或架构模式。一但是模式，扩充性就留出来了。
但是商业网站是不能一天到晚失火的，团队仍是有人要去保卫这种大局。所以最后也只好履行了这样的规范：
我发明很多工程师友人经常有自干且以为自己的东西最好的偏向。认为外界的办法相对不适用在自己的团队上，美国的常态并不合适在台湾使用。但事实上这 世界真的无比大，说真实 未审真的没什么理由把自己的成长速度绑在自己的眼界里面，很多的 principle 在不同工业不同国度都是实用的。多看看别人怎么作，你会惊奇这些方式的引入，对自己事业加成的幅度是如许惊人的。
而网站的指标和 用户休会并不是说打的开就好。比如说网站开的速度会直接影响 Search Engine 和 Alexa 排名，不知道这到底有多少人知道？还有正常使用者对 Blog / Album 和 Video 各自可以忍耐的 response time 基本是不同的，Video 大家可以忍个5 秒还没翻开都能接受，但是相册和博客开一页要 5 秒这大略就没人要用了吧…
-->
一个设计方案会这样设计的背后原因有很多个，有可能是：
4. 尽力写下所有的 documentation
热血的投入通常会让人有假象，我投入的工时越高，结果会越好。事实上这是一个彻底的伪命题。而创业初期的不稳固，繁忙，失火，更让你会有只要我尽力 加班，一切就改良的错觉。肾上腺素最多只能让你撑三个月，接下来所有都会幻灭的。作一个网站要到可以出场，大家比得是命长，而不是 Startup weekend 冠军。
2、上线前必须使用开发服务器， apply feature branch 测过一轮
要使用 HTML / CSS 架构设计网页，不要滥用 ORM，不要重造轮子，不要写出会被人公干的 code ，这些都是基本的开发常识。很多新创网站写出初版很快，但之后就陷入开发泥淖，无奈配合业务模型快捷调剂，几乎 90% 的原因以上都是因为第一版 code 烂到当初的开发者自己也改不太动，结果光是后续调整架构作小改版就耗掉超多时间，变成超大抵命伤。
这是 documentation 可以带来的价值。
我设计这一套教材的目标是要让所有新进的开发者，在最长两周时间内要学完根本 Linux 指令、Git、Rails 所有基础的常识、部署、SCSS 撰写等等，一个月之内就能上战场跟我们一起开发功能开发新网站。这样的进度很夸张吗？不，不夸大。这里的每一个开发者都有这样的程度，他们有些人应聘时是连 Rails 都不会写的。你能相信连T 客邦的PM 和 ART 他们也会写 Rails 吗？（ no kidding）
综合以上，我想说的是：在开发初期，任何一点战力都是相称可贵的，所以没有什么理由把程序码乱扔，不履行一定的规则而导致到处都失火。永远都在作重复的白工。
6. PM 的话听听当参考就好，但要好好沟通
Rails 没有这样的状况吗？这是我认为 Rails 上风的处所，它是一个非常热门的 Framework（只有在台湾你可能没有感到到他很热点）。因为这是一套 Framework，也就是它本身有很强的束缚性，至少 MVC 和 routing 规则，一般就算新手也不会乱放的太离谱。写 code 有一定的潜规则存在。
4、部署流程必须使用工具主动化，失事要能回转。
好的东西是不错。但不要孤注一掷。
因为至少很多的 “basic” 的教导成本，在这部门会几近于 0。一路都在 startup 的历练，让我很早就理解到一件事，人员流动简直是无可防止的，所以主要的是要怎么让职员流动造成的冲击更小。
在新创事业让同事投资一项新技巧，也是很昂贵的。所以要学的话，大家一定也都全都要会，否则就会一直很贵。
在之后新的专案中，就可以拿上一个案子打下来的基本一再反复利用再应用。甚至最后居然还有 Event Generator 这种东西…（Authenication ， Rails Admin， SEO， …etc.）。
不追求效能实在是一句非常不堪设想的话。
以上我上面所说的这些东西都不是我的创举，事实上几乎所有 Rapid Development， Agile Development， 还有很多 Engineering Blog 常常都在聊这样的话题。
所以通常我是这样做的：先 branch 一个版本，我自己或是请资深 RD 自己下去把全部实作方法都做出来或者是进行评估，断定可行后整顿成可行的 SOP。才大符推行。
相关的主题文章：
(责任编辑：网站建设)
新创网站这样开发才够快_相关文章