野生码农的架构实践_.NET_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > .NET > 野生码农的架构实践

野生码农的架构实践

 2017/10/22 9:47:02  老坏猫  程序员俱乐部  我要评论(0)
  • 摘要:一、自传IT圈子重所谓“出身”。在B乎、各种码农圈子,经常看到晒学历、晒工作经历。不是BAT,就是麻省,北清。就如龙母见任何人都要报出一堆头衔,以证明自己血统的高贵。而本人,就是一个纯野生“双非”码农:非计算机科班出身、非IT名企出身。大学学的机电自动化,毕业也是一直跟机器、图纸打交道。没有自带光环、没有拜师学艺、没有群星荟萃,全凭个人兴趣,业余爱好而已。然而诸葛亮说过,不要妄自菲薄。兴趣是最好的老师。因为偶然机会,帮朋友设计一个进销存软件
  • 标签:架构

class="PublishStatus">一、   自传

        IT圈子重所谓“出身”。在B乎、各种码农圈子,经常看到晒学历、晒工作经历。不是BAT,就是麻省,北清。就如龙母见任何人都要报出一堆头衔,以证明自己血统的高贵。

而本人,就是一个纯野生“双非”码农:非计算机科班出身、非IT名企出身。大学学的机电自动化,毕业也是一直跟机器、图纸打交道。没有自带光环、没有拜师学艺、没有群星荟萃,全凭个人兴趣,业余爱好而已。

然而诸葛亮说过,不要妄自菲薄。兴趣是最好的老师。因为偶然机会,帮朋友设计一个进销存软件,一发不可收,经常熬夜研究,不但要理解需求,还要编写代码,从无到有,无师自通。

那时候,成功连接数据库、弹出来第一个窗体,都是极大的喜悦。虽然彼时水平极菜,自己却认为已经是“高手”了。现在想来虽然可笑,但也是这种良好的自我感觉,给了我持续的动力。

对我这种野生码农而言,没有资历可晒,资本就只有一样:码力,写代码的能力。能证明自己的,就是代码和架构的水平,比如这个

二、   起步:看山是山,看水是水

  • 我的起点

起点就是零点。大学里也“学过”计算机,C,FORTRAN。甚至图书馆里借过几本计算机书啃。然而中国的教材,你懂的,最大特长是把简单问题复杂化。当时不喜欢英语,吃了大亏。

后来逐渐明白,无论技术还是教材,还是国外原版的好。后来再没怎么研究过计算机,直到我搞那个进销存软件为止。所以开始,我就是一个软件盲。

感谢宽带,感谢百度,感谢微软。家里有了宽带,就可以百度:看博客园、看csdn、看MSDN。好在.NET门槛很低,帮助齐全,神器加持,如果是C++,陡峭的自学曲线,说不定就放弃了。

  • 摸索之路

也许正因为是从一张白纸起步,虽然走了些弯路,但也没有窠臼之见。既不知道什么设计模式,也没有编程套路和规范。一切都是自己摸索,也形成了自己的“风格”。

最开始的进销存设计,我不懂代码,但是需求分析还是有的。只是彼时初生牛犊不怕虎,不知深浅。什么能实现,什么不能实现,实现的难度有多大,一概不知。

这个进销存系统虽是业余练笔之作,但最初拟定的需求,却是参照一款国内流行的管家婆软件。需求来自于管家婆的说明书。

没办法,发挥我国人民山寨的特长,管家婆有几个页面我也几个页面,管家婆有哪些功能我也来一套。

VS神器+Winform,从拖控件开始。有些控件达不到管家婆的效果,就百度。涉及到的财务知识不懂,百度。如此也练就了一身功夫:搜商。现在想找什么资料,关键字往往一击命中。

有人说C#、.NET坏就坏在拖控件上。把码农惯坏了,惯成不求甚解只会拖控件的傻瓜了。我只想说,只会拖控件的确说明你是傻瓜,但这不怪微软,只怪你自己没有追求。

这样经过若干昼夜的鏖战,总算出来几张基本的数据库表,几个还算齐整的页面。代码是吃百家饭,从百度上抠来的。比如数据库的连接啦,button的效果啦,等等。

现在看那些代码,既不是面向对象,也不是面向过程,而是纯粹为实现功能拼凑的代码。前后台代码混在一起,一个类千行代码,一个函数洋洋洒洒。

但有两个习惯让我能进入下一步,一个是追求完美主义,一个是喜欢追根究底。没有这两点,不可能进阶。

比如ADO,里面有一系列对象,什么游标、什么DataTable、什么数据库连接池,这里涉及到大量概念,我这人不习惯死记硬背,为从无到有理解ADO、数据库的一系列概念,熬夜思考若干天,终于有所领悟,理出头绪。而之后,数据结构、套接字、网络协议,这些概念自然而然就会进入你的视野,务求深入理解,磨刀不误砍柴工。我个人的经验,软件行业包罗万象,最好的学习方法就是掌握基本概念之后,用什么学什么。道理一通百通。

而追求代码完美主义,使我看着过往零碎、丑陋的代码,内心感到不满,也开始接触到一些面向对象、多层架构、UML这些概念,感觉真理就在眼前,开始考虑重构代码。

三、   思变:看山不是山,看水不是水

  • 从面向“过程”到面向对象

重构的第一步,提取出共性的东西,代之以函数。

原来大量的相同、相似代码合并,放到一个大的工具类,大家共享。这样做的好处显而易见,代码精简了,可读性强了,改起来容易了。

但是重构这个事,很容易矫枉过正。尤其是我接触到“面向对象”这个概念之后。

初识面向对象,总有一种发现真理的感觉。比如订单类,原来的风格是类大而全,保罗万象。

学了面向对象,就将采购单、销售单、入库单、出库单等等继承一个总的Order类,每个Order还要分订单抬头(客户、账号、订单号、日期),明细,又各自有所继承。

那时候的代码,真是万物皆对象,为赋新词强说愁。至于这么分类有什么好处,却没有清醒的认知。所以结果就是把简单的问题复杂化了。

比如每个订单都有自己的增删改查方法,然而订单的参数不同,增删改查都要重载;人说三层架构好,就把界面逻辑中所有数据操作的部分,都塞到一个DAL层。

 

可以说,这样做的结果还是有好处的,界面部分没有数据库操作的语句。修改界面的人(不一定是自己)只需要知道接口规范就可以。不用在意太多细节。

坏处是,一旦对象发生变化,不但要改接口,还要改数据库,数据库操作的DAL层。

这一阶段,总体代码量甚至有所增加,性能甚至有所下降,但思路更加清晰了,对面向对象的理解深入了,包括它的利弊。

  • 设计模式的改造

学习了设计模式之后,对面向对象的理解深入了一层。实际上,经常发现自己不知不觉中已经是设计模式的践行者。因为这些模式都是前人对某一类问题总结出来的最佳设计方案。

设计模式的目标,就是减少耦合性,提升扩展性。从哲学角度,编程并不简单的是写代码的问题。是对客观世界的抽象。牛逼的人能很快领悟到本质,用一个简洁的描述就能让人明白真相,比如

 

 大部分人,对复杂的问题理不出头绪,而且越来越乱。所以编程能力除了逻辑思维之外,很重要的一点是抽象能力。不管是编程还是做其他事,都需要这种能力。

在这之后,我并没有刻意去套设计模式,而是学会了一个简单的套路:分析核心业务对象,用接口提取某一类业务的共性,各业务对象之间用接口交互。

四、   破局:看山还是山,看水还是水

  • 简单的就是好的

等面向过程、面向对象、设计模式一路走来,经历了从繁到简、由简入繁的过程,对架构的利弊也有了更多的思考。

这时候,我最强的就是一个字,简。一切回到原点,风格倾向简洁。到后来,甚至变成极简主义,不想看到一行无用的代码。

可能很多码农都有体会,看某些网上的代码,痛苦不堪。因为千头万绪,本来几句话能说清楚的事情,绕很大一个弯。

当年我做组态设计,有用到一种DDE的技术。网上下载了一个库NETDDE,C#代码,为了追求所谓“普适性”做了几层封装,最后不但代码不忍卒读,性能还很差。

于是花了点功夫做重构,删繁就简,代码清晰,性能提高了一个数量级。

越简单的东西,可读性越好,可维护性越好,可扩展性越好,往往性能也越好。

而能用最简单的方式描述一个复杂的事物,我认为就是架构能力的体现。无论在我的组态软件设计,还是程序化交易软件,都遵循了最简化这一原则。

说说个人的一些体会。

首先,对需求分析,提取出核心业务。

比如在进销存,核心业务就是物流、钱流;而驱动物流、钱流周而复始的核心对象就是订单(采购单、销售单、入库单、出库单等等)。

在组态软件,核心业务就是网关,核心对象就是变量(Tag)。无论HMI的动态显示,还是下位机的扫描轮询,承上启下的就是变量。

在程序化交易,核心业务就是行情、交易,核心对象就是Bar(K线)。驱动核心业务运转的就是订单(Order)。

分析出核心业务、核心对象之后,整体思路就清晰了。

第二步,根据业务特点做技术选型。

我认为,作为一个好码农,能够在多种方案中选择一种最佳或者次佳的方案,是基本能力。

在多年编程实践之后,应该对同一个问题已经有了多种方案。比如最基本的,用.NET还是JAVA还是Python?通讯是用Socket还是HTTP?是用字典还是列表?是用第三方还是自己造轮子?

每种方案各有利弊,最后你要善于抓住主要矛盾,比如你需要的是开发效率,就尽量利用.NET;做互联网项目,尤其是复杂业务、在Linux上运行,就要用JAVA;需要的是性能,就要Socket,字典;可能存在并发,那就要考虑高并发解决方案。

第三步,架构设计。

对我最熟悉的桌面程序而言,一般都包括三部分:界面-服务-工具。

在组态项目里,后台服务提供网关功能,核心业务封装在服务;可以驱动多个客户端界面。因此服务要求稳健、高性能。服务这部分需求尽可能完善,尽可能稳定。设计服务部分的一般为架构师、资深码农。

界面需要前后台分离协作,因此界面设计应尽可能简单、直观。最好就是傻瓜式的拖拽控件,复制模板,连连变量。界面设计人员不需要考虑后台怎么实现,只需考虑具体业务需求。甚至都不一定会编程。

工具如组态软件的变量管理器等,设计目的是减少界面人员和服务设计人员的交互工作。把两者共同用到的配置项、变化最多的数据分离出来,用简单的可视化工具管理。VS本身也是这样一种工具。

服务-界面-工具,三者之间用不同的方式交互。服务与界面可以使用通讯协议、WCF交互;界面、工具之间可通过数据库、配置文件交互;工具和服务之间往往通过数据库交互。

  • 对性能的关注

数据结构是码农的基本功。很多人说.NETer因为框架的强大对数据结构一无所知。这是P话。因为我在代码追求完美主义,所以我对我程序的性能也追求的孜孜不倦。

很多人说.NET性能如何如何不行,博客园有老赵,xiaotie的文章为什么不去看?老赵和xiaotie的性能优化手段,我也用过。因为不同的数据结构、不同的索引都能带来巨大的性能差异。

比如在组态软件里,如果要按变量名在一个几千变量的变量表搜索到一个变量(Tag),你可以用1.遍历2.二分法排序之后查找3.字典。三种方法的差异有如天壤之别,如果这种操作是频繁的,就一定要仔细考量。

如果你仅仅写代码为交差,为糊口,就不会关注性能,更不可能去编译.NET的代码,或者去百度谷歌搜索最好的性能解决方案。

如果这是一种习惯,日积月累,几年后,同为.NETer ,做出来的东西无论架构还是性能,就有巨大的差别,当然也会反映在个人收入上。

园子里有人发帖说学.NET的如何被PHPer,JAVAer歧视。我只能说,你被歧视怨不得.NET,怨不得微软。只是你自己水平太菜而已。我也接触过不少搞JAVA,PHP的,谁有资格搞语言歧视?

没有一种语言能解决所有问题。各有所长。如果有搞JAVA,PHP或者任何其他语言的人,如果仅仅因为语言的偏见就想贬低我个人的话,可以到github下载我的程序,然后自己想出更好的解决方案来,我就服你。否则自己去打脸。

五、   下面的计划

写一系列帖子,把架构、原理讲清楚。大致如下:

  • 网关层接口概述
  • 上下位机通讯原理
  • 如何实现一个设备驱动
  • 如何设计图元
  • VS插件模块及原理
  • 归档模块及文件格式
  • 如何进行功能扩展
  • 组态变量表达式实现

github地址:https://github.com/GavinYellow/SharpSCADA。QQ群:102486275。

上一篇: Anroid四大组件service之本地服务 下一篇: 没有下一篇了!
发表评论
用户名: 匿名