服务热线:
13215994088
您当前的位置:网站首页 > 资讯中心
行业知识更多 >

风口上的HTML5,今年的发展方向会有哪些?

 2014年下半年,微信捧火了HTML5小游戏,自此国内各行各业开始对HTML5保持持续高涨的关注。2015年是国内HTML5行业迅速发展的一年,在媒体大肆渲染“互联网寒冬”之际,HTML5作品的生产数量和传播广度却居高不下,为寒冬增添一把热火。   如图,根据百度指数对关键词“HTML5”搜索趋势结果,2015年“HTML5”的指数约是2014年的1.5倍;而HTML5的简单说法“H5”在2015年的检索量是前一年的2倍多,直逼“HTML5”。   2015年,国内HTML5的传播仍以移动端为主,但简单的翻页这种低层次的设计已经不再适应大部分受众的需求,HTML5平台也开始由简单的工具应用逐步转型。其中,发展得比较快的是面向商企用户的iH5,自主研发引擎,并于2015年年底添加即时通讯功能和线上交易机制。   为什么是HTML5?   Web应用开发新标准   HTML5,第五版超文本标记语言,于2014年10月由万维网联盟(W3C)发布为正式推荐标准。它是HTML自1991年问世以来,最具变革价值的技术规范,历经多年修订与完善才制定完成。   过去,Web开发面临两种困境:   (1)不少人质疑Flash的安全性等问题,却找不到替代它的合适插件;   (2)工程师们抱怨PC端和移动端应用的多次开发,仍旧得为微软、苹果、安卓等系统设计不同方案。   而HTML5提供了良好的解决方案。与JavaScript、CSS等紧密结合后,HTML5能使浏览器不需要类似Flash的插件也能实现桌面应用的交互效果,它的跨平台可用性更令应用的一次开发成为可能。   如上图,Youtube使用HTML5的video元素进行标记后,网页不需要第三方插件就能播放音视频等。因此,HTML5的兴起具有非常深远的意义,它已经从简单的标记语言化身为Web应用开发的先驱。   HTML5应用现状   从硬件角度来看,国内手机和平板两种移动设备应用最广,PC端次之,紧接着是电视和游戏设备。   从软件角度来看,桌面浏览器对HTML5的支持高于移动浏览器,最高可达95%;而从整体上而言,移动浏览器对HTML5的支持却优于桌面浏览器。   HTML5具有较好的浏览器向后兼容性,开发者能对浏览器不支持的情形设计各种各样的回退方案。因此,HTML5页面的实际显示性能与开发者、制作平台密切相关。   2015年,越来越多公司在HTML5品牌推广上进行布局。6至7月份起,鸡汤、自媒体等个人作品呈下降趋势,商企用户作品则保持高速增长。在商业需求的驱动下,HTML5页面设计的目的性更强,获得最好传播效果的基本是经过一定时间策划,在团队操作下有针对性地进行投放的企业案例。   相对应地,原有HTML5平台也进行了大面积升级。从平台性质而言,HTML5平台可分为轻营销模板类、功能引擎类和基础工具类三种,分别以易企秀、白鹭引擎和iH5为代表。   三类HTML5平台的特点如下——   (1)轻营销模板类:提供类似PPT页面切换的HTML5制作工具,通常面向C端(个人)用户,部分为B端(企业)用户。该类平台的数量较大,只适用于轻度营销,所能提供的页面动态效果局限于翻页。   (2)功能引擎类:提供HTML5网页的开发引擎,通常面向B端用户。该类平台主要提供基于Canvas(画布)的游戏引擎,适用于轻游戏的开发,依赖于开发者。   (3)基础工具类:提供用于页面交互的HTML5可视化编辑工具,主要面向B端用户,部分为C端用户。该类平台只有iH5,采用自主研发的闭源引擎,应用领域广泛,涵盖轻度营销、重度营销、媒体电商内容应用、视频、动画、游戏等方面。   与浏览器多采用谷歌开源引擎的状况相近,国内HTML5平台基本使用国内外开源框架或引擎。但和浏览器面向网页内容显示,只需提供高性能的技术支持不同,HTML5平台面向的是HTML5制作或开发,需要对网页质量负责。因此,使用开源框架或引擎意味着这些HTML5平台进一步拓展业务会比较被动,容易面临同质化的困境。   三类HTML5平台的对比   因为整体上移动端浏览器对HTML5的支持优于PC端,2015年HTML5平台主要面向移动端网页的制作和开发。   如上表,三种HTML5平台以PC网站、APP和软件三种形式提供制作或开发工具,成品为网页或HTML5源码。由表可见:   (1)轻营销模板类HTML5平台只能做轻度营销,能实现翻页等简单动效,分为场景展示、电子出版和动画制作三种。如下图为易企秀桌面编辑界面,该类平台最大的共同点在于工具结构以页面为基础,与软件PowerPoint架构相近,能通过增减页面、使用功能组件和点击快捷菜单来调整内容。   (2)功能引擎类HTML5平台的用户专指性很强,主要是有开发经验的技术人员。下图为Egret Wing软件设计师视图下的基本架构,使用HTML5引擎把基础代码流程化,再借助第三方集成开发环境Adobe Air构建可视化工具,就能通过让用户使用软件组件来简化开发过程。   (3)基础工具类HTML5平台提供底层交互型产品,开发目的、设计原理和实现思路都以交互为基础,国内只有iH5。iH5于2015年9月上线,提供HTML5制作工具、工具培训和作品交易等服务。它本质上封装了DOM(文档对象模型)引擎的一个集成开发环境,使用者以设计师为主,适合广告公司、大型媒体公司和公司市场部等使用。   如上图,iH5提供的是舞台、屏幕、页面、多媒体素材、事件、数据库等对象组件,而不是构建好的模块组件。在提供可视化编辑的前提上,它最大程度还原了HTML5页面的开发过程,具有较高的拓展性。由于提供底层交互功能,它的应用领域较广泛,能用于微信推广、网站建设、轻游戏设计、轻APP开发和视频交互等多个方面。   同样是HTML5规范,对HTML5技术与性能的取舍成为国内HTML5平台工具定位和提供服务的差别所在。   HTML5行业发展的趋势   伴随着HTML5兴起的是Flash的没落,HTML5能打败在多媒体领域称霸多年的Flash,除了移动设备的跨平台性和较好的多媒体支持外,它的应用范围也广于Flash。比如,Flash动画作品的复用性极低,基本没有模板市场,而HTML5却能作为基础填充材料,用来制作报纸图文等模板。   参考Flash发展的演化路径并结合HTML5的新特性,HTML5近几年会在重度内容、网页游戏、垂直领域解决方案和内容直接填充四个方面有所突破。   (1)内容往重度化方向发展。   重度营销并不完全意味着大项目、高预算、长周期、大团队,而是相对轻度营销以用户生产内容为主,它更注重专业内容的生产。在用户对页面交互能力和HTML5拓展功能的要求提高之际,轻度营销的市场份额会逐渐降低,往重度营销内容转化。   (2)网页游戏往交互游戏方向发展。   尽管HTML5游戏具备无需下载、包含社交属性、开发成本低等优势,但如果没有充分利用HTML5的新特性,加强移动游戏的交互能力,它很难在游戏市场中异军突起。由此,网页游戏未来更有可能结合HTML5优良的通信功能,往跨屏互动等交互特征更明显的形式发展。   (3)垂直领域解决方案往在线应用方向发展。   与HTML5行业密切相关的垂直行业主要包括在线教育、电商和流媒体三种类型。   以世界最大的在线课程平台Coursera为例,授课视频即使用HTML5实现“课间小测”。如下图,在Coursera网站上,当视频播放到特定节点时会出现与课程相关的问题,提供用户选择答案,记录答题情况并反馈答题结果。   (4)传媒业往内容直接填充方向发展。   国内HTML5制作工具基本都提供模板服务,这与HTML5网页较强的复用性有关。网页基础架构设计完成后,修改源码中各元素的参数便能替换素材、改变对象属性,因此HTML5网页能用于制作基础填充材料。在HTML5模板的帮助下,新媒体内容能通过应用母版进行编辑,用户只需后期进行图文内容的替换,因此很有可能成为传媒业转型的契机。   反观国内不同类型的HTML5平台,只有以HTML5提供的新特性为根本,着眼于底层交互才可能适应各行各业对网页开发的需求。因此,基于HTML5元素和属性进行设计的基础工具,未来更有机会占领尽可能多的市场份额。

Web开发在过去20多年时间里如何改变了我

web改变了,因而我的技术堆栈也变了。貌似我的堆栈变回到了roots。 20年前,我从HTML和JavaScript开始,再到使用VBScript的经典ASP。 2001年,我开始陶醉于ASP.NET和VB.NET,并用到了产品中,直到2006年底才不再这么干。2007年年底,我开始使用C#编写ASP.NET。HTML和JavaScript仍然参与其中,但多多少少被封装在第三方控件中,并且jQuery当时是JavaScript的别名。JavaScript的一切都是jQuery。ASP.NET WebForms感觉巨大又不是很灵活,但它能有效工作。后来——2010年——我用Silverlight、WinForms和WPF做了很多东西。   ASP.NET MVC出现了,web这个东西开始再次比ASP.NET WebForms感受更自然点。从一个ASP.NET开发人员的角度来看,web开始变得更好:更加干净、灵活、轻便和自然。   但也出现了一些新的东西。一些来自于ASP.NET世界之外的东西。强大的JavaScript库,如KnockOut、Backbone,以及后来的Angular和React。第一个单页应用程序框架(对不起,我不想提蹩脚的ASP.NET AJAX…)出现了,UI逻辑从服务器转移到了客户端。(好吧,我们确实在2005年搞回了一个很酷的SPA,但我们没有想过如何用它创建一个框架。)   NodeJS通过在服务器上使用JavaScript再次改变了世界。你只需要两个不同的语言(HTML和JavaScript),就可以来创建很酷的web应用。我不怎么对NodeJS感兴趣,除了在后端使用它,因为一些工具基于NodeJS。也许这是一个错误,谁知道呢; )   现在我们有了ASP.NET Core,这感觉比传统的ASP.NET MVC更自然得多。所谓的自然在这种情况下,意味着和编写传统ASP的感觉几乎相同。这也就是说使用无状态的web工作,而不是试图修复它。使用Request和Response比传统的ASP.NET MVC工作起来更直接,比ASP.NET WebForms甚至就更直接得多。自然并不意味着你必须编写和传统Asp同样非结构化的废话。 ; )   由于我们已经有了非常酷的客户端JavaScript框架。和简化了的、简约的服务器端框架,服务器部分就被减少到仅仅用于在REST服务上提供静态文件和数据。   正是这个时候,深入了解TypeScript变得有了意义。但是到这个时间点为止,它对我还没有意义。我用JavaScript编写代码大概有20年时间,但我从来没有在单个项目中写过这么多的JavaScript代码。之后,在过去几年时间里我开始使用AngularJS。Angular2是应该好好研究TypeScript的一个原因,因为现在的Angular2完全是用TypeScript写的。   几个星期前,我启动了我第一个真正的NodeJS项目:一个使用NodeJS来为用户提供高度灵活脚本运行时的桌面应用程序。NodeJS提供功能和UI给用户,所有都是用TypeScript写的,而不是普通的JavaScript。为什么?因为TypeScript有很多意想不到的好处: -   仍然可以编写JavaScript -   帮助编写小的模块和结构化的代码 -   帮助编写NodeJS兼容模块 -   一般说来,不需要为每个模块写所有的JavaScript代码 -   只要专注于所需要编写的功能   这就是为什么TypeScript对我来说是个大帮手。当然类型化的语言在很多情况下也是有用的,但是——使用JS工作了20年——我喜欢隐式的类型JavaScript语言的灵活性,并且我对它很熟。这意味着,从我的角度来看,有关TypeScript的优点是,我仍然能用TypeScript编写隐式的类型代码,并利用到JavaScript的灵活性。这就是为什么我说“仍然可以编写JavaScript”的原因。   Web技术改变了,我的技术堆栈也改变了,工具也是。所有这些东西都变得更为轻巧,连同工具一起。控制台回来了,IDE变回为它们的root:只不过是一些有着类似语法高亮和智能感知这些作用的文本编辑器。目前,我更喜欢根据我工作的项目类型使用有着“瑞士军刀”之称的Visual Studio Code或Adobe Brackets。两者都开始变得非常快速,包括一些不错的功能。   使用轻便的IDE令人愉悦。一切都很快,因为通过我需要开发的app可以使用机器的资源,而不必通过我需要使用来开发app的IDE。这使得发展速度快了很多。   现今启动一个IDE意味着启动cmder(Windows上我最喜爱的控制台),改变项目文件夹,启动控制台命令,从而查看typescript文件,保存后编译。我可以启动另一个控制台来使用如NPM、gulp、typings、dotnet CLI、NodeJS等工具;以及启动我最喜欢的轻量级编辑器来编写代码! : )

测试代码时你会犯的 11 个错误

 1.没有测试   我们很容易毫无原因地掉入这个陷阱。从现在开始,制定计划添加测试到你现在正在处理的代码中,并添加测试到将来的项目中。   2.没有从项目一开始就启动测试   我们很难再回过头去添加测试,并且可能需要改变架构才能添加测试,这样做最终将需要你花更长的时间才能产出可信任的代码。从一开始就在项目的生命周期添加测试可以节省时间和精力。   3.编写失败的测试   TDD方法的普及将红—绿—重构的理念带到软件测试世界。这个理念常常被误认为应该“通过编写一个失败的测试开始”。其实并非如此。在写代码之前创建测试的目的是定义系统的正确行为应该是什么。在许多情况下,它是一个失败的测试(红色表示),但它可能会通过一个非决定性的或未实现的测试来表示。   4.担心未实现测试   软件开发中的一个大问题就是,代码和任何关于系统实际上应该做什么的文档之间的沟壑。通过拥有一个名称中明确定义你最终想要实现的预期行为的测试,你将从测试中得到一定的价值,即使将怎么写测试目前还不得知。   5.没有很好地命名测试   命名软件这件事出了名的很难做好,这同样适用于测试。关于如何命名测试有几种流行的约定。无论你使用哪一种都没有关系,只要你能够一贯使用,并准确描述正在测试什么。   6.让测试做太多事情   又长又复杂的名字通常说明了你想同时测试多件事情。单个测试应该只测试一件事情。如果失败了也应该在代码中注明是什么地方出了错。你没有必要为了知道代码中出了什么问题而查看是哪部分测试失败。这并不意味着你不应该在测试中有多个断言,但这些断言应该紧密相关。例如,一个查看订单处理系统输出,并确认输出中是否有一个单一项目以及它是否包含具体项目的测试,是ok的。但一个验证相同系统的输出的测试,既创建一个特定项目,又记录到数据库中,还发送确认电子邮件,就不行了。   7.没有实际测试代码   经常可以看到测试新手创建过于复杂的模型以及不能实际测试代码的设置程序。他们可能会验证模拟代码是否正确,或者模拟代码是否和真正代码做相同的事情,或没有任何断言而只是执行代码。这样的“测试”都是白费力气,特别是如果它们的存在只是为了提高代码覆盖率水平的话。   8.担心代码覆盖率   代码覆盖率的理念很崇高,但往往实际价值有限。知道运行测试的时候有多少代码被执行应该是有用的,但因为它不考虑正在执行代码的测试的质量,因此就变得没有意义。代码覆盖率在它数值非常高或非常低的时候,是挺博人眼球的。如果非常高,就表明,比起带来的价值,过多的代码可能正在被测试。非常低的代码覆盖率表明有可能代码的测试不够。因为这样模棱两可的意思,有的人就不知道单一片段的代码是否应该进行测试。我用一个简单的问题来明确这一点:代码是否包含重大的复杂性?如果包含,那么你需要一些测试。如果没有的话,你就不需要。测试属性访问器不过是浪费时间。如果它们失败的话,那么比起你正在写的代码,你的代码体系出现了一些更根本的问题。如果你不用看一段代码,就立即知道一切,那么它就不重大。这不仅适用于代码,也适用于你写代码。如果我们在任意点重访代码,那么它就需要测试。如果在现有代码中发现过bug,那就说明这一块的代码对其复杂性没有进行充分的测试。   9.着眼于一种类型的测试   一旦你开始测试,很容易只纠结于一种风格的测试。这是一个错误。只用一种类型的测试,你就不能充分测试系统的所有部分。你需要单元测试来确认代码的各个组件是否能够正确工作。你需要集成测试来确认不同组件是否能够协同工作。你需要自动化UI测试来验证软件是否可以如预期使用。最后,你需要为任何不容易自动化的部分和探索性尝试进行手动测试。   10.着眼于短期测试   来自于测试的价值大多数会随着时间的推移而获得。测试不应该只存在用于确认事情是否正确写入,而应该随着时间的推移继续起作用,并且对于代码库做其他的改变。有回归错误或新的异常,那么测试应该重复运行以尽早发现问题,这将意味着错误和异常可以更快,更便宜和更容易被修复。没有变化(人为错误)可自动和快速执行的测试,是为什么编码测试如此有价值的原因。   11.作为一个开发者,依靠于别人来运行(或编写)测试   如果不运行,那么测试几乎没有价值。如果测试不能被运行,那么就可能遗漏bug。自动运行的测试(作为一个持续集成系统的一部分)是一个开始,但项目的任何一个人都应该能够随时运行测试。如果需要特殊设置,机器,权限,或配置来运行测试,那么这些将成为执行测试的壁垒。开发者需要能够在检查代码之前就运行测试,因此他们需要能够访问并有运行所有相关测试的权力。代码和测试应保持在同一个地方,并且所需的任何设置都应该写好脚本。关于这个方面我见过的最坏的例子是一个做的很糟糕的项目,在这个项目中测试人员的子团队定期取走开发人员正在处理的代码副本,他们修改代码以便他们能执行一系列测试,但这些测试是开发人员在特殊配置(无证)的机器上所无法访问的,然后测试人员再发送一个很大的邮件给所有的开发人员以说明他们找到的问题。这不仅是一个坏的测试方式,而且也是团队工作的糟糕方式。不要这样做。代码能够正确执行是专业开发人员的部分属性。要保证代码的准确性,方法是使用伴随它的适当测试。依靠其他人为你写的代码编写测试和运行测试,不会帮助你成为一个专业的开发人员。   如果以上这些都不属于你的情况,那么恭喜你!继续保持开发稳健又有价值的软件。   如果上面有一些确实发生在你身上,那么是时候做一些改变了。

谷歌等公司重写OpenStack生命周期管理工具

虽然 OpenStack 已经成为受欢迎的开源云软件堆栈,但是另一方面,它的 DevOps 项目 Fuel 却在赢得用户方面遇到难题。现在,谷歌、英特尔和 Mirantis 正在重写以利用 Kubernetes 作为底层调度引擎。   聪明之举!   从 Fuel 原设计者的方方面面来看,这个工具从来就没有崛起。另一方面,Kubernetes 已经拥有了很多用户。   正如大多数人所知,Kubernetes 是一个容器管理和 DevOps 项目。在 OpenStack 上,Kubernetes 部署将利用 Docker 容器。基于 Kubernetes 的 Fuel 将提供单一平台让虚拟机、容器、裸机系统动态地控制 OpenStack 操作和生命周期管理。   该计划是提供一个持续集成/持续交付(CI/CD)通道。新的 Fuel 将让用户可以精细地控制服务部署和管理,可以推出更新,并让 OpenStack 控制面板能够自愈且更有弹性,而且这还将让创建基于容器的应用路径更加平滑。   这业界三巨头并不是第一次提出这个观点。Mirantis 和 CoreOS 从去年就开始致力于这个方向了,当时他们将 Kubernetes 引入了 OpenStack。这是该计划自然而然迈出的下一步。   毕竟,作为 Mirantis 首席运营官 Boris Renski 在声明中称:“随着 Docker 的兴起成为标准的容器图像格式,Kubernetes 成为容器调度的标准,我们终于看到人们处理分布式应用操作方式上的持续性。将 Kubernetes 与 Fuel 结合起来,这将打开 OpenStack 的一种新交付模式,让更新消耗地更快,帮助客户更快地得到结果。”   到目前为止,谷歌都还不是主流的 OpenStack 玩家,现在它也加入了 OpenStack 阵营,正如谷歌高级产品经理 Craig McLuckie 说:“在 Fuel 中利用 Kubernetes 将把 OpenStack 变成一个真正的微服务应用,弥合传统基础设施软件和下一代应用开发之间的差距。从使用容器和先进的集群管理作为实现弹性的、高度可扩展的基础设施打下基础,这将让很多企业受益。”   这是否有助于加速 OpenStack 的部署?我当然希望如此。OpenStack 是一个非常强大且有用的云计划,但也存在难以部署和维护的缺点。我认为将 Fuel 和 Kubernetes 结合起来正是 OpenStack 需要的。

「能写代码」是愚公移山,「会写代码」是女娲补天

之所以提这个话题,跟前两天在微信群里的讨论有关,年后本该是跳槽、找工作的高峰月份,各公司面试邀约应该很多,但是听群里的反馈却是不太容易。从行业发展角度看,移动互联网连续火爆数年,已逐步走向稳定;从国家发展形势看,从去年开始,整个国家经济形势不景气,不只失业率增多,好多移动互联网公司裁员、倒闭;从程序员职业角度看,现今「挨踢」培训机构屡见不鲜,大都打着包学包会包分配,三俩月速成的口号忽悠人,导致很多学员没有打牢基础,就匆忙走上岗位,而且培训机构过分鼓吹使得学员们没有真正认清自身实际,没有正确定位!   建议大家这段时间不要裸辞,边工作,边寻找机会才是最好的选择。「裸辞」倘若一时找不到工作可能会导致心慌,没有安全感,甚至会产生「自我怀疑」和「自我否定」!如果在职场暂时迷茫也不要心慌,因为只有经历过了痛苦和绝望之后,才能够「浴火重生」,找到方向。   从本质上区分,一个是被动,一个是主动   由于近几年来移动互联网行业实在火爆,程序员这条路已经由10年前的「羊肠小道」,修成了「康庄大道」,跟高速公路似的,但是还是挤,拥挤的跟北京早晚高峰的地铁似的,涌入的人越来越多,感觉门槛似乎很低。很多人看准了计算机行业工资高,好就业,转行当程序员。其实不然,一个行业健康的发展是因为有很多有兴趣,有爱好的人涌入,这部分人由于兴趣和爱好,喜欢钻研,想要更深入的去了解底层知识和原理,所以容易提高,这就是优秀的程序员,而大部分人是被现实所逼迫,从而选择了一个职业,逼迫往往而导致被动,时间久了就会变得平庸。中国有句俗语叫「心随我动」,一旦从事了这个行业,时间久了,差距就会慢慢拉开,所以优秀和普通从根本上就有差别。   从能力上分,一个是搬运工,一个是设计者   「能写代码」是愚公移山   为什么说能写代码是愚公移山呢?我们中国大部分程序员都应该处于一个初级程序员的水平,怎么讲?只有少数的程序员处于中高级水平。愚公移山就是愚公为了有一条近道(可以形容为生存),而不停的去挖山,子子孙孙重复的去做同一件事,就像我们编程,如果你一直在公司重重复复的当代码搬运工,天天就会写界面,这就是能写代码!即使你有10年的工作经历,但是经验就是刚当程序员那一年!十年如一日的做同一件事,你确实足够坚持,也不否认你有爆发的那一年,就像愚公一样需要中彩票的几率依靠两个大神帮你解决问题。   能写代码是一个基础水平,初级能力,要想走的高,看的远,不要「安于现状」,勇于攀岩和破冰,才能改变世界。中国现在的基础情况是不缺乏初级程序员,而是缺乏大部分中高级程序员,这就是为什么大部分公司在招聘的时候为什么喜欢3到5年工作经验的程序员了,喜欢归喜欢,这个限制只不过是提高了他们能招聘到中高级程序员的几率罢了,毕竟「十年如一日」的程序员占据了市场的大部分。   「会写代码」是女娲补天   女娲补天?这又怎么讲?优秀的程序员就像女娲一样,拥有极其强大的能力,不仅仅可以探索和创造,也能及时出手,写出如五彩石一样的漂亮,严谨的代码去补天,堵上天一样的大窟窿和大漏洞,还人类一个美丽的「天上人间」,保持程序「完美运行」。如果人间恶魔兴起,扰乱民心,她可以有的放矢,一招制敌。优秀的程序员就是如此,他不仅仅是能写代码,而是会写代码,这种高境界的水平,不仅仅是有经验,经历过大大小小的崩溃战争,而是在制敌中探索和学习,如何保卫程序稳定生长和运行,把恶魔消灭在萌芽般的象牙塔之内!   会写代码就是如此,他知道怎么去搭建架构,构建地基,把恶魔封印在程序之外。优秀的程序员会写代码更是会一直保持在「深度学习」之中,白天打仗提升实力,晚上「闭关修炼」提高自己。使自己打造的天上人间如仙境一般,越来越美,偶尔来了雾霾,也会如女娲补天一样,能轻松得召唤到西伯利亚的寒风,把它吹走。   总结:会写代码和能写代码的差距就是 -   我喜欢闭关修炼,你满足安于现状 -   我是兴趣驱动型,你是迫不得已型 -   同样都是坚持,我是坚持学习,你是坚持复制 -   我追求的是长远进步,你疲于奔命的挣钱(挣钱没有错,错的是眼光)   差距就是在这些不经意的细节中拉大的。你感觉复制粘贴完成任务就行,人家想的是如何更好的写出代码,提高效率。你按部就班,日复一日的使用同样的方法,人家总想着学习和进步,使用最新的技术完成功能,两年之后,你还是只会一种落后的方法,人家却是用更好的方式完成了任务,你这时可能感觉没什么?假如一年之后,官方突然宣布,不再支持你的旧方法,你是否会「怅然若失」?而人家可能会「欣喜若狂」的在想:那个破方法,早应该被淘汰了。你说不急,我现在再重新开始学习, 殊不知一大批使用新方法的毕业生正在来袭,而前卫的学习者说不定又在探索更新的技术。这就是这个行业现状。   最近在看书,不说了,说多了都是泪,我也是仅仅处于「能写代码」的水平。要努力!要争取向「会写代码」的方向努力!今赋此文,纯属有感而发,希望能与大家共勉。
共8条 共1页 第1页 首页 上一页 1 下一页 尾页

版权所有 © 2017 河南方果电子科技有限公司

做网站:方果科技 豫ICP备16029994号