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

我是一名软件工程师，在过去的六年里我一直在开发网站。在新公司中，速度节省时间，时间就是金钱，金钱可以邀请更多的工程师让整个发展更快。学校没有教很多软件工程方法，或者如何成为一名好的程序员。其实这些东西在台湾省行业并不存在，大家都是边做边摸，从经验中学习。我从书籍和网络上学到了很多方法，可以让团队更有效率，因为我相信我必须首先在新团队中这样做，并被业界公认为快速和合理的方式。以下几点可以和大家分享。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或小版本中制作的。好的东西是好的。但不要孤注一掷。综上所述，我想说的是，在开发的早期阶段，任何战斗力都是相当宝贵的，所以没有理由扔掉程序代码，不执行某些规则，导致到处着火。总是做重复的白工。对于任何措施，最好尽量将成本降低到几乎低，但效益非常高

以上就是关于新创网站，如何开发得又快又有道理的相关介绍，更多新创网站，如何开发得又快又有道理相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对新创网站，如何开发得又快又有道理有更深的了解和认识。