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