新创网站，如何开发得又快又有道理

我是一名软件工程师，在过去的六年里我一直在开发网站。在新公司中，速度节省时间，时间就是金钱，金钱可以邀请更多的工程师让整个发展更快。学校没有教很多软件工程方法，或者如何成为一名好的程序员。其实这些东西在台湾省行业并不存在，大家都是边做边摸，从经验中学习。我从书籍和网络上学到了很多方法，可以让团队更有效率，因为我相信我必须首先在新团队中这样做，并被业界公认为快速和合理的方式。以下几点可以和大家分享。1.让整个团队使用一个成熟的开发框架和环境:我的专长是RubyonRails。如果现在使用PHP或者PHP，我不喜欢推荐别人。.NET或JAVA，无论成本如何，都要引入新的框架。就像我不太喜欢硬导入Scala或Nodee一样.js一样。它们可以在它们可以使用的地方加分，但绝对不能是主体。事实很简单，我不认为他们足够成熟，可以让所有的成员快速开始，不重建轮子。一般团队喜欢使用PHP。因为PHP工程师好找，Rails工程师难找。但在我一路走下去的经历中，我认为这是一个虚假的命题。因为在人力市场和公司的实际运作中，你会发现这个命题不是很可靠。是的，你可以找到PHP工程师，但是很抱歉，很多人写的代码不能用(更准确的说是writeonly)。(我没有冒犯PHP开发者的意思)原因是PHP开发没有太多的一致性规范，基本上就是爱怎么写就怎么写。这导致即使你的团队里有一个强大的开发者，也没有多大用处。因为每个人都有不同的代码格式，甚至网站结构也不同。几乎没有办法补充人。每个人都只能写自己的东西。即使爆炸了，几乎只有原作者才能修复。在我眼里，这是极度浪费团队战斗力的罪魁祸首。Rails没有这样的情况吗？这就是我认为Rails的优势，它是一个非常受欢迎的Framework(只有在台湾，你可能不会觉得他很受欢迎)。因为这是一套Framework，也就是说，它有很强的约束力，至少MVC和routing规则，即使是新手也不会太离谱。写code有一定的潜规则。在开发中遇到任何错误后，开发者几乎可以用谷歌找到任何可能的原因并修复它们。这几乎是自建Framework无法比拟的地方。如果你在公司自建一套Framework，基本上会出现任何问题，最后几乎都要打扰原来设计的Architect。(这也是浪费钱的地方，因为Architect的工资很贵)。学习曲线太高，我不认为它真的存在。Rails高手很难找到，但Rails中低手只要训练得当，生产力也很惊人。所以只要把重点放在如何帮助一般想入门的人身上，就能快速克服入门的几个门槛(搞定开发环境，RESTful，Plugin，Debug，Deploy），剩下的部分可以通过网络教材和实战训练。这也是我发明Rails101的原因。我设计这套教材的目的是让所有新开发者在最长两周内完成基本的Linux指令，Git、Rails的所有基本知识、部署、SCSS写作等，都可以在一个月内上战场开发功能开发新网站。这样的进度夸张吗？不，不夸张。这里的每一个开发者都有这样的程度，他们中的一些人在申请时甚至不会写Rails。你能相信连T客邦的PM和ART都会写Rails吗？（nokidding）如何规范写Code规则？我的同事和我从社区中吸收了很多最好的实践。我们把这些东西整理成新手指南和最好的实践，甚至包装成Gem和Generator。开发者越后进，赶上前辈的时间就越少。在短时间内，他们的作品也可以像前辈一样提前携带Bestpractices。最近也开始写另一本书Essentialrailspaternforbeginers。Rails本身也有丰富的生态系统，更不用说预设架构的最佳实践了。新团队资源少，人事预算不够。相反，我们应该巧妙地利用自然资源，使团队具有很高的战斗力。2.功能设计适用于当前，考虑到一定程度的扩展：我不相信新团队中的任何人都能预测未来，即使很多事情似乎在未来向那个方向扩展是合理的。对我来说，我在设计功能时不会overthinking，甚至我也禁止同事overthinking。因为专案中最高的原则是getthingsdone，notoverdesign。但这并不意味着不需要在设计上留下一定程度的扩展，最后一个内部工作过程通常有重建和分类的空间。这时，同事们会把乱七八糟的code整理回原规范中必须写的样子。若这是一种常见的功能，则必须将其整理成程序库或架构模式。但是模式，扩展性就留出来了。在后续的新专案中，可以拿上一个案子打下的基础重复使用。甚至最后还有EventGenerator...（Authenication，RailsAdmin，SEO，…etc.）。3.程序本身即注释一般软件本身在实践中也不赞成注释。相反，鼓励程式本身应该能够表达自己的行为。假如写的程序乱七八糟，让人看不懂，进入审查时就会被退回。我们团队可以接受的程序是可以写得很笨拙，但每个同事都能理解。因为笨拙但可以理解，其他前辈有时间重构。但是乱写之后就没人动了。4.尽量写下世界上所有的documentation，没有人能写出一本完整的系统架构书，详细描述系统中的真实情况。但是一个好的issuetrackingsystem和写commitlog可以帮助你理解为什么现在系统是这样设计的，为什么当时会做出这样的决定，导致程序必须这样设计。在新人训练期间，我通常会训练新人在票上有任何实践中遇到的细节和情况的习惯。而且在完成整个专案或技术架构稍有规模雏形时，要对这些ticket上的笔记进行梳理记录。这将对整个团队的跳跃产生非常强大的积极影响。与此同时，在人员流动(新进或离职时，冲击会非常非常小。至少很多“因为”basic在这部分，教育成本将接近0。一路走来，我很早就明白了一件事，人员流动几乎是不可避免的，所以重要的是如何减少人员流动的影响。让同事在新事业上投资新技术也很贵。所以如果你想学习，每个人都必须知道，否则它将永远非常昂贵。这是documentation能带来的价值。5.要有测试环境和政策，我从昂贵的教训中学到的是，一定要有测试环境和policy。将环境在Rails中分成几部分并不难。必须有测试环境（staging），因为每个人开发的环境都不一样，很多设计在自己电脑前都不会考虑那么多。只有把远程服务器扔掉，你才会知道炸掉一大块，或者性能极差。这些都会伤害商业信用或搞砸交易(比如你明天和客户谈好on档几十万的广告，但是明天因为人为疏失，你会把谁的队列挪给他，这样的事情整天都会发生。谁想和你做生意？）。政策更重要。事实上，许多加班的情况是不必要的。比如头脑不清醒的时候写了烂codecommit。让自己清醒的时候清理一下这摊烂泥。最新版本的code是在吃饭前或下班前部署的，结果中午倒站几个小时；本来可以准时下班，十点都走不动。但是写好东西不直接commitmaster，不立即部署，会让RD很痒。我甚至不能幸免这种病。但是商业网站不能整天着火，团队里还是有人要捍卫这种大局。所以最后还是要执行这样的规范:1、所有的featurebranch写作功能、开发服务器必须在上线前使用，applyfeaturebranch测试一轮3轮、中午11:00-12:00绝对不是:00部署，绝对不是17:00后部署。4、工具必须自动化部署过程，事故必须能够回转。5、在执行了这些规定之后，几乎没有人需要饿着肚子去修补bug，半夜因为软件问题跳起来加班修理。由于我深信：长期处于火灾/火灾环境中，一个团队的战斗力会迅速下降。热血的投入通常会让人产生错觉，我投入的工作时间越高，结果就越好。事实上，这是一个完全错误的命题。而创业初期的不稳定、忙碌、失火，更让你有一种错觉，只要我努力加班，一切都会改善。肾上腺素最多只能让你持续三个月，然后一切都会破灭。要做一个网站才能出现，每个人都比生命长，而不是Startupweekend冠军。6.听PM的话作为参考就好，但在很多情况下，PM可能需要10个小时来计划方案A。但是你知道只需要3个小时就可以把它变成方案B。但前提是，你要好好问，他为什么要做A设计案。不可否认，台湾省专业素质的PM极其罕见，能遇到的一个就是烧香。因此，在很大程度上，我们可能会遇到一个人，他只会复制其他网站的框架构图，或者Sales负责销售广告，但这并不重要。重要的是你要问为什么会这样设计，因为他的外行程度可能会让他估计一个真正的犯罪，让公司严重亏损，但你并没有阻止他。或者案例结构是一个合理的公司方向，但你误解了未经授权修改背后的设计原则：设计方案的原因有很多，可能是：1、在PM路上随便抄2、PM喜欢这样做3、ART要求4、客户要求5、这是主要功能，一定要这样做，否则会失去这个系统的意义，所以不能喜欢B就B。开发一个系统必须有成本和预期收入，而实际的计划必须找到两者之间的平衡。这是通过沟通...7.写一定程度的程序代码，用HTML/CSS架构设计网页，不滥用ORM，不重建轮子，不写会被公众干的code，这些都是基本的发展常识。很多新网站写第一版很快，但之后就陷入了开发的泥潭，无法配合商业模式快速调整。几乎90%的原因是第一版的code太差了，开发者自己也改不了多少。因此，仅仅通过后续的调整结构进行小修改就花费了大量的时间，成为一种致命的伤害。8.为了追求一定以上的网页效率，tune在刀口上不追求效率是非常不可思议的。不可否认，一些开发者真的追求过度的效率和想象力技术，比如甚至从一开始就用Backbone写整个网站，或者从头到尾用Node.js写网站。这些都是一开始就打算写mobilewebservice给mobilephone使用的事情。因为3GLatency太大了，所以要尽量压缩频宽，追求页面responsetime。但是完全没有必要做一个桌面网站。在调整网站性能时，界面性能也优先考虑，因为C/P值要高得多，所以压缩CSS可以节省3秒。db或程式语言tune的死亡可能只节省0.1秒。而网站的指标和用户体验并不意味着打开就好。比如网站开通的速度会直接影响Searchengine和Alexa的排名，不知道有多少人知道这一点？此外，普通用户对Blog/Album和Video可以忍受的responsetime有着根本的不同。Video可以忍受5秒钟，但在打开之前可以接受，但相册和博客需要5秒钟才能打开一页，所以没有人需要使用它。。。效率调整是不好的。9.少用Fancy的东西，在实施之前估计成本和效益。作为开发者，世界上每天都会有很多新的好东西，不玩看手真的会痒。但事实上，每一次介绍都会有一定的成本，而且效益/成本比并不一定是你当初想的那样。比如一直追Rails新版，换上效率好的Ruby1.9.2.用SCSS写CSS，用Coffescript写JavaScript。AsssetPipeline架构是Apply新发明的。这些都是很新很棒的东西。(T客邦都有，架构从最早的2.3开始.从upgrade到3.1.3.专家知道这个项目有多大)，但其实和其他事情一样，新事物有新的风险。通常引入这些东西，不是一个人，是每个人都应该使用的东西。所以我通常这样做：首先，我要求高级RD自己制定或评估整个实践方法，并在确定可行性后将其整理成可行的SOP。才大符实施。如果是新的想法，试用效果是在event或小版本中制作的。好的东西是好的。但不要孤注一掷。综上所述，我想说的是，在开发的早期阶段，任何战斗力都是相当宝贵的，所以没有理由扔掉程序代码，不执行某些规则，导致到处着火。总是做重复的白工。对于任何措施，最好尽量将成本降低到几乎低，但效益非常高