使用.NET进行高效率互联网敏捷开发的思考和探索

不知从什么时候开始,创业变得很廉价,谈什么都是互联网,动辄融资千万。这阵风好像也刮向了程序员中,有那么一大批开发者,数据结构不好好学习、数据库原理不扎实掌握,在github上发布几个项目,用nodejs创建一些服务,再用H5写出APP,就自以为迈入了高级程序员的队伍,能够运筹帷幄互联网项目,难道学习新技术、新理念就是快速成长吗,显然不完全是,在这浮躁的氛围中,各种粗制滥造的互联网网站、APP接踵而至,很多看似漂亮的APP,连简单的http接口安全都没有措施应对,很多美丽的响应式网站,目录结构随意堆叠,这实在是一股歪风邪气,我觉得程序员还是应当踏踏实实的多学理论,多写代码,反复实践。

那么另外一个问题就来了,新技术、新理念难道就没有用了吗,显然也不是,新技术新理念是无数的技术大牛在长期的实践中反复重构的胜利果实,而作为一个.NET老司机,眼看着这些年微软拥抱开源,拥抱社区带来的改变和进步,也是深感欣慰,于是今天,我想和大家分享一下这些年我以及我的公司对于使用.NET进行Web开发乃至于互联网应用开发的一些经验和技术总结。

先看一个最新上线的典型案例,http://muban.printhelloworld.com(不好意思,正在重构,暂时无法访问),其中用到了诸如HTML5、Bootstrap、EF6 For MySql、阿里云RDS,阿里云CDN等新技术和新理念,然而却并没有脱离采用.NET进行开发以及采用.NET生态环境(IIS、Windows Server)进行部署这一基础,但整个开发流程,已经完全摆脱了WebForm甚至MVC,我们实践了一套全新的.NET开发模式,在开发效率和团队协作上大大提升,在开发时间上也极大地缩短,在这个案例里面,整个网站的前台和后台管理,从构思到设计、开发、调试、部署,1个人3天完成。下面就开发模式的细节详细描述,也听取大家的意见,继续改进和完善。

对于ASP.NET WebForm的评价,我想以下的话是客观的:ASP.NET WebForm托拉拽以及事件驱动的Web开发模式的创新,虽然方便了一大批.NET入门者的学习和理解,但最终严重阻碍了的.NET的普及和商业化使用,而且在很长一段时间内,.NET优秀的语言特性得不到重视,反而一直被扣着低效率、难扩展、不适合商业开发的帽子,ASP.NET WebForm在这其中有着不可推卸的责任。

遥想06、07年的时候,我还在惊叹于UpdatePanel的强大和方便,现在回想来看,这样的开发模式让开发人员对HTTP和Web本质的认识无疑是罩上了一层迷雾,从长远看是一种倒退,再往后来,到了ASP.NET MVC时代,微软高阶程序员的陋习依旧没有改善,虽然MVC开源了,但仍然充斥着各种自以为是的为开发人员提前想好的特性、绑定、快捷方法等等,这些东西初级开发人员可能会觉得很方便,但我想,任何从事过商业项目架构和开发的技术经理都会深有感触,在真正需要稳定的扎实项目中,这些小聪明,不仅毫无用处,而且难以扩展,更容易导致难以掌控的Bug和漏洞。

令人庆幸的是,在Nadella的带领下,在比尔盖茨重新担任技术顾问的指引下,.NET不断修正方向,除了在语言上大步向前,更在生态建设上愈加清晰可见。我一直在怀疑公司所创造的.NET敏捷开发模式是否是先进性的体现,直到vNext(MVC6.0)的出现,我豁然开朗,原来殊途同归,微软终于走对路了。

在谈开发模式之前,我想先谈一谈:

一、目前的互联网项目或者是传统Web项目的一些新趋势和特点

1、不再使用WebService,而是大量使用HTTP作为数据通讯的方式

2、数据载体不再使用XML,转而使用JSON

3、Web前端会使用Bootstrap、JQueryUI、EasyUI等第三方HTML5框架

4、有APP的需求,甚至APP优先的需求,APP需要对接各类第三方插件

5、为了追求APP快速上线,有时候会采用HTML5的APP开发模式,例如PhoneGap、AppCan、HBuilder等

6、 有微信的需求,要求对接微信公众账号,进行微信浏览器中的移动Web开发

7、开发周期短、迭代频繁

8、数据量增长迅速,对报表展示、数据分析有较多的需求

9、项目组人员需求由Web开发工程师,细分为HTML5前端工程师、JAVA(.NET)工程师、数据库工程师等

10、单元测试减少,功能测试越来越多,甚至用互联网工具(worktile等)替代专业测试工具

基于以上情况,我们考虑,如果仍然使用.NET进行系统开发,那么在用户量<=50万的敏捷项目里:

二、一些传统的.NET Web开发模式和方法就应该被抛弃

1、ASP.NET WebForm以及MVC模式不再合适,他们均存在前后端耦合严重,简单流程复杂化的问题,而且前端始终无法脱离.NET架构。

2、SQL Server数据库不再合适,虽然SQL Server 2014的特性让人激动,但随着公有云的使用越来越普遍,同时相比其他数据库来说,大小、价格、可扩展性甚至性能方面,SQL Server都显劣势。

3、传统三层架构不再合适,很多互联网项目,从设计之初就要求能够支持多服务节点,不同应用场景使用不同数据库。再加上三层架构大量使用反射牺牲性能增加代码,也不再适合敏捷开发。

4、Server 2003的IT架构应当被抛弃,无论是IIS6.0落后于IIS7的HTTP请求处理模型,还是Server 2003落后于Server 2008、2012的稳定和扩展,都不应当再考虑基于Server 2003和IIS6的.NET部署。

虽然被抛弃了一些东西,但微软毕竟是微软:

三、一些.NET特性应当被强化

1、深入使用Visual Studio 2015开发工具,VS2015是宇宙级开发工具无需多说,甚至在前端编码(CSS、JS、HTML)上也愈加纯熟,配合适合工程师自己的自定义设置以及第三方插件,将会如虎添翼

2、TFS源代码管理的使用,无论是内部安装TFS Express版本还是在tfs.visualstudio.com上申请免费空间,都能够很好的进行团队协作,以我们实践来看,切勿被Git模式冲昏头脑,事实上TFS管理模式才是最适合.NET开发的

3、.NET高阶语言特性应当加强使用,在理解的基础上,如果能熟练使用Linq、Lamda表达式、反射、Task并行编程等.NET特有的优质语言特性和方法,将会极大地提升开发效率,缩短开发时间。

4、IIS的高级功能和动态管理应当加强使用,IIS7以后,IIS服务器就是高性能Web中间件的代名词,加上Server 2008、2012的Core模式,加强对IIS的动态管理和配置能够极大地提升Web处理效率。

5、Server 2012 R2操作系统应该加强使用,虽然跨平台是.NET的方向,也在mono上实践的很好,但在PC服务器和云服务器越来越便宜的今天,还是多用用Windows最新的服务器操作系统吧。

 

有了以上这些认识,经过总结,我们现行的.NET开发模式,可以简单概括为如下:

一、前后端高度解耦

首先要做的就是彻底抛弃ASP.NET WebForm和MVC模型,前后端高度解耦,前端的所有逻辑处理均使用JS进行处理,包括Dom元素布局与绘制以及数据请求,而后端为纯粹的业务逻辑处理,包括逻辑处理以及数据处理。目前我们的项目由于使用了ASP.NET中的Routing特性,依然Host在ASP.NET模型以及IIS中,在理论中以及不久的将来,替换为Core IIS或者Linux下的Nginx来Host纯HTML5以及HTMl5缓存也将非常容易。

二、前端使用纯HTML5

前端抛弃传统HTML,尽量全部使用HTML5技术,其中做出的牺牲有,抛弃IE11以下的浏览器,但在互联网思维的今天,这样的思路也未尝不可,当在前端全部使用HTML5技术后, 文件、图形图像、音频视频、地理位置等各种处理将变得非常简单,而且扁平化、数据化。

三、前端充分利用成熟框架

使用新的开发模式后,很明显的一个改变就是,公司的美工不再或者很少进行前端切图,而对于技术美工的需求(会CSS开发和JS开发、也懂设计)则日渐增加,带来这一改变的根源就是那些不断涌现先进的、优秀的前端框架,我们目前正在使用的有JQuery、Zepto、JQueryUI、JQueryMobile、Bootstrap、Amaze UI、inoic、Framework7、SUI、MUI等等,以及伴随着这些优秀框架的第三方插件。客观的说,通过优秀框架的使用,不仅没有增加前端的系统风险,反而由于框架的开源、架构清晰、稳定等特性,实现了更加稳定、可扩展的前端。简单的举个例子,在解决困扰很多Web工程师的全兼容性的布局以及响应式布局问题上,Bootstrap就功不可没。

四、前端开发面向对象化

将前端开发,通过JS面向对象特性进行简单封装,在Dom元素操作以及业务逻辑数据请求的处理上,与后端数据类型、实体结构以及处理逻辑上保持一致,不仅拉近了前后端开发人员之间对业务需求的理解,也是极大地降低的技术培训的门槛,提升了团队合作的效率。

五、使用CDN服务

CDN服务在几年前还是大企业、大公司的专属,现在已经完全普及化、平民化,Web前端越来越重是不争的事实,但真正的业务逻辑往往只有几十K甚至几K,1个几百K的页面,90%是JQuery等第三方框架,因此,合理的使用CDN加速,不仅提升用户端的体验,更直接将基于HTTP架构Web服务的负载能力提升5-10倍以上。

六、业务逻辑HTTP服务化

这句话的描述可能不是很恰当,但这也是我们全新的.NET开发模式中最重要的环节,经过对阿里开放平台等先进互联网架构的学习,最终我们形成了结构化但松散的业务逻处理模式,即每一个业务逻辑行为均有1个唯一的路由名称,业务逻辑只对路由名称负责,而路由名称对流向、性能、权限、安全等上层需求负责。这样做的好处是,能够充分利用3-5年左右经验的开发人员(这也是大部分公司的开发主力军),让他们专注于业务逻辑的编写,而业务逻辑之外的事情,在架构层面由其余的控制器去解决,而一个大的.NET项目工程,也可以灵活以不同的方式拆分为各个子模块。对于HTTP服务的实现,我们尝试过ASP.NET ASHX处理器、Windows Service HOST WCF服务、ASP.NET Web API,当前较为稳定版本是Web API,当然针对HTTP服务化这一需求,Wen API也显略重,以后会继续改进。总之这一改变过程,在实践中提升了至少3倍以上的开发效率和测试效率。在后一章节中,将会进行详述。

七、分布式与热加载HTTP服务建设

互联网应用要求的是敏捷开发和反复迭代,同一个逻辑架构下的不同请求会使用不同的服务器和数据库已经是家常便饭的事情,因此项目设计初期,分布式HTTP服务的建设至关重要,而业务更新更是需要能够进行热加载,在.NET体系里面,就是DLL托管代码的动态加载使用,可惜的是,由于公司现有项目并未出现大规模分布式场景,因此还未研发出较为稳定的DLL动态加载架构,在后一章节中,将会详细讨论。

八、使用阿里云解决大数据问题

我想任何一个使用过阿里云以及其他云服务的IT架构师,都能深深的感觉到,阿里云已经领先其他云不止一个身位。事实上,特别是阿里云的数据库相关功能,例如RDS、DRDS、KVStore等,都已经在实践环节真实的解决了很多传统需求里的复杂点和困难点,具体细节后面详细讨论,但真心的说一句,赶快使用阿里云吧,至少在现阶段,不是阿里云在绑架你,而是在帮助你。

今天写了很多,总的来说,就是告诉大家,.NET的春天已经来了,.NET不仅可以进行互联网化的敏捷开发,更能处理大型项目大型数据大型逻辑,这一点我在实践中已经尝到甜头,而作为一个写Pascal数据结构出身的程序员,也至今十五年有余,我也对各类新技术非常感兴趣,都有涉猎甚至尝试,不怕被别的语言喷,我甚至可以大胆的说一句,其他语言,从综合(语言、开发环境、开发效率、技术社区、团队协作、应用能力)上来看,在应用级开发领域,已经落后.NET太多太多,只是.NET程序员自己还没察觉,所以从这一点上来看,需要大家的共同努力,不断钻研和探索。

接下来的时间里,我会抽空继续把公司这一套开发模式和相关工具抽丝剥茧,开放出来,也听取大家的意见和建议,不断改进和完善,今天先写到这啦。

时间: 2024-08-03 09:50:48

使用.NET进行高效率互联网敏捷开发的思考和探索的相关文章

谈谈软件项目管理——敏捷开发

敏捷开发(Agile Development) 随着"敏捷"一词出现在越来越多的项目中,于是,敏捷开发本身也被赋与了越来越多的意义,而敏捷的真正内涵反而变得越来越模糊.如何迈出敏捷开发第一步?是按照敏捷宝典.操作指南或是教父语录,还是因地制宜.因项目定方法?完成所有这些工作后,我们就真的"敏捷"了吗? 一.前言 Agile是指企业能够对外部环境做出速捷.有效的反应,是未来企业的必备素质.21世纪企业面临的竞争环境将是一个不断变化.不可预测的环境.由于高新技术的出现和

详解互联网产品开发中的“快”字诀

当今互联网的发展,已不是大鱼吃小鱼的时代,而是快鱼吃慢鱼的时代.互联网产品的制胜原则就是一个字--"快".在各种形态的产品研发中,我们始终贯彻如一的价值观之一就是"快",我们应该如何来理解和诠释"快"?又会从哪些方面来执行贯彻这个原则呢? 一.快速迭代,快做快发 互联网产品不同于传统软件开发,我们面对的是上亿用户这样一个庞大的使用群体,他们是谁,有什么喜好,有何种习惯,会怎样使用我们的产品,是否喜欢我们的产品--这些情况我们并不能准确地知道.因此

需求采集为小公司敏捷开发中的用户服务

网页制作Webjx文章简介:最近也许是因为大家面试很多,讨论用户需求采集的话题越来越多,好像突然大家一下子都在关注产品的这一流程.当然需求采集的方法很多,众多前辈们也都总结了许多,完全可以参考甚至搬到自己的项目中来实现.这些方法用到大公司大项目上,只要把握的好,数据分析工作做 最近也许是因为大家面试很多,讨论用户需求采集的话题越来越多,好像突然大家一下子都在关注产品的这一流程.当然需求采集的方法很多,众多前辈们也都总结了许多,完全可以参考甚至搬到自己的项目中来实现.这些方法用到大公司大项目上,只

利用Rational Team Concert在敏捷开发中进行持续集成

本文将介绍如何利用 Rational Team Concert(RTC)在敏捷开发过程中进行持续集成.详细说明了如 何在 RTC 中通过采取一系列的步骤和脚本开发,来保证持续集成过程的连续性和提高整个项目的效率. 同时还阐述了每一步可以利用的工具和最佳实践,从而使开发过程更加规范化,高效化. 概述 Rational Team Concert(RTC)是 Jazz 产品中最重要的一个,是一个可以任务分解集成,源代码版 本控制,进行自动构建和报告的工具.Jazz 做为 IBM 下一代的软件交付平台,

敏捷开发的几点建议

同步发表在:http://snowdream.github.io/blog/2016/04/07/agile-development-advices/ 移动互联网行业由于节奏快,产品迭代周期短,因此多采用敏捷开发进行快速迭代.下面我从Android客户端研发的角度,说说敏捷开发中的几点建议: 模块化 当项目开始变得很大时,需要按照主要功能进行模块化.同时对人员进行分组,每组负责一个主要模块.由于迭代周期短,任务重,可能在开发过程中,某个模块无法按照要求,在既定的时间内完成开发任务.这时,应该由产

解析敏捷开发的特点

近期公司在着重推进项目的敏捷开发,虽然以前也接触过,但还是去参加了下敏捷开发的培训,对于产品经理来说,如果推行了敏捷开发,则产品经理的协调沟通作用会更加的凸显出来,毕竟前期没有文档,只有演示稿甚或是图纸的情况下,沟通是非常重要的,特别是确认所有的需求功能点,并给需求功能点的优先级排序,确定敏捷开发的迭代周期,这些都需要沟通去解决,例行的会议也会比较多,产品经理肯定都要参与其中.对互联网行业来说,敏捷开发能更快速的响应不断变化的需求,对产品经理来说,如果同时参与的项目多一点的话,那就更加的杯具,你

敏捷开发实战随记

敏捷实战实施背景,地产行业信息化管理某知名企业,为了快速切入和抢占互联网市场,某产品研发部实施敏捷开发,通过短期快速灵活方式提升自己产品生产能力. 1.团队建立.确立目标和制度 以两周为一个大冲刺周期,大冲刺内实现和完成产品指定功能升级: 以每周为一个小周期,实现每日构建,开发人员完成后立即提交到测试环境由测试人员进行测试: 团队化分为平台小组.接口小组.开发A组.开发B组进行不同分工作业,每组设置小组长一名带领各小组完成冲刺目标: 整个团队设总监1名.有个产品经理.2个PM带领大团队进行产品升

敏捷开发 PK 瀑布模型

   在去年12月底开始接触高校平台项目,到现在也快有小半年了.这次的开发不同以往.是以敏捷开发作为开发方式.以前都是遵循传统的瀑布模型,而新方式的开发思路直接与传统的开发思路来了个正面碰撞,擦出了阵阵"火花".     在一开始接触敏捷开发时,有些兴奋,有些期许,但是在真正用来做项目时,由于瀑布模式已经根深蒂固,再加上对需求不熟悉,对开发环境不熟悉,新方式的开发反而让人感到别扭,麻烦,甚至抵触.     由于对敏捷开发的不理解,大家也爆发了很多争论,不过也正是这些争论,引导我们逐步走

老曹眼中的敏捷开发【中生代北京闭门会实录】

引言 世界上不存在这样一种方法: 只要套用,就可以写出完美的软件,无论使用的哪种设计模式: 但确实可能存在一种开发方式,可以帮助我们一步步构造出需要的软件和架构--这有可能就是敏捷开发. 源自贝尔北方实验室的开发流程 相对于软件开发流程,有一门专门的学科--软件工程.最早接触软件工程,是20年前在北电贝尔北方实验室工作的时候,当时的开发流程是这样的: 其他主流的瀑布式开发流程也大致如此. Scrum的敏捷流程 随着技术的演进,尤其是互联网的发展,BS架构的广泛应用,用户反馈的及时响应成为了可能.