V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
liuhanyang0
V2EX  ›  程序员

贯彻单点真理,打造 KISS 项目

  •  1
     
  •   liuhanyang0 · 2015-02-13 09:10:12 +08:00 · 2225 次点击
    这是一个创建于 3331 天前的主题,其中的信息可能已经有所发展或是发生改变。

    原文链接 http://jjyy.guru/how-kiss-work/

    零、 编程的核心困难的是什么?
    复杂。编程是很复杂的工作,以至于作为一门工科显得很不严谨,只要运作不出问题就当做没问题。编程最核心的技巧是抽象和间接。

    抽象是简化核心问题的功夫。为什么要抽象?主要原因是一方面代码是写给人看的,要符合语义;另一方面,人在一个层次上能同时处理的概念通常只有7,抽象恰恰就是在为这种符合人性的需求,对问题规模进行切割。抽象能够带来间接,间接能够隔离变化,间接能够控制依赖方向,间接能够提供扩展性等等的项目需求。

    抽象要我们对已有的业务概念进行裁剪,做减法,需要我们加深理解业务;间接需要我们为项目增加能力,做加法,需要我们有一定的想象力。

    一、 要去理解业务,业务理解深刻了,那么逻辑自然就清晰了,写框架不完全是技术问题
    如果你之前从头到尾做过一款有一定规模的游戏,那么下一次再写就会很漂亮。就像单词背多了,英语句子总能看得懂。游戏框架,需要你对写过大量游戏进行共性提炼。举个例子,你很容易发现数据与显示分离的好处,并且设计出MVC模式。

    二、 坚持单点整理,把真理自动推导到系统每一处
    如同几何一样,我们可以定义最基础的公理,推论出一系列的有用的推理。这需要不懈的努力才能做到,其中一个编程中给力的工具就是元编程。它能够把这些变量推导到系统的每一处。比如你定义了一系列xml数据格式,那么每添加一份xml就不应该写具体的parser以及定义结构体,应该能够做到在业务中直接使用这些数据,parser过程自动化。比如UI拖了一个按钮,那么业务也不用写一行xx = getButton(“xx”),而是应该直接用,获取按钮的过程自动化。比如定义了网络协议,那么封包的过程自动化。比如美术给了新的图片,应该命名与策划定义id一致,程序只管按照约定读取,不用知道有新的图片,不用配置一个id。把所有的中间环节砍掉,代码量、工作量都会少很多,这些工作往往复复,会乘很多倍,在时间上积累起来一定是个数字,最糟糕的是,前期没有把框架做好,那么业务的技术负债就会越来越深。语义的另一个方面就是代码写下来就是完备的,比如写了创建,那么通常都要写删除,先把系统考虑成能够独立存在的,那么自然就少依赖,少bug。

    三、 重新思考面向对象
    先把一个观点放在这里,强类型语言(C++、Java)的面向对象都是不完整的,或者说那根本就不是面向对象。指着他们说面向对象不行就像指着太监说天下的男人不行。真正能玩耍面向对象的语言应该是动态语言,鸭子类型让我们不需要折腾继承这套玩法来进行多态。在静态语言中,继承职责有两个,一个是复用,一个多态。继承应该只用来复用,而不应该做多态(这就是C++多继承邪恶的地方)。

    从历史的角度来看,面向对象是好东西,它带来的变化如同过去代码的结构化编程一样:取消goto语句,用顺序、循环、分支替代,从而让代码统一易读。而面向对象则是对数据的结构化编程,让数据更加抽象,让大家操作数据的时候不用关心数据有什么字段,而且对象的思路也能帮助我们进行抽象,提升代码抽象层次,而且还让我们更容易进行思考。

    四、 提前构建好,胜于等待需求冲击。有些东西易放难收,前期就把抽象做起来
    杀鸡用牛刀是没问题的。对于全局性的接口,要一开始就把接口打磨干净,信息传递完整,把简单的完整的信息留给用户。如果项目中扩散着各种因为这个接口导致的脏代码,想在后面再收,那就很痛苦了。一些东西确实需要提前想清楚。比如热更新的支持、性能指标、UI系统等等。

    五、 分层模式是最好的架构,每个层面实实在在地解决一些实际问题
    分层的优点在于,依赖方向得到最好的控制,而且代码复用高、耦合低。每个层次有自己的核心问题,比如引擎这一层就是做一些业务无关的功能,比如渲染器、物理引擎。比如框架层就是为业务支撑的,着眼于开发效率。分层架构的另一个好处是增加人手分工也是很容易的事情。

    一个好的框架,能让业务逻辑清晰简单的表达,让用户的每一行代码都在解决业务问题,而且还能让业务问题简化。

    六、 训练编程直觉,训练自己写出简短的符合语义的代码。每次都把代码写好,写得多了,能够做到下意识地把代码写漂亮。
    程序设计就是语言设计 –松本弘田
    只知道要符合语义并不够,还要知道怎么才能做到。把平时的代码写好,写干净,多阅读优秀的项目架构,那么开发的时候,自然就会不断地进行重构,得到漂亮的架构。也许你懂得保护模式就能开发操作系统,但是写得是否漂亮,能否把它写好写大又是另一回事。不断归纳总结进行高强度练习,时间长了,你很难说清楚为什么要这么写,但这么写就是好,而且逻辑清晰,符合语义。就像绘画大师一样,画画就是好看,但也很难说清楚为什么每个动作,每个因素的变化,都会有不同的行为,如此多的细节,不可能全部都说出来。我们写程序也是要看着各种因素的变化,随着需求、性能指标、历史包袱、人员分工因素等等的不同,会开发出不同的代码。而不是机械地跟着教条走,新手才这么做。在你不断地漂亮地、快速地完成需求,自信心也随之而来,正反馈不断循环。

    目前尚无回复
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1262 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 165ms · UTC 17:54 · PVG 01:54 · LAX 10:54 · JFK 13:54
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.