(「哪些Guide与设计模式是无用的?」「全部!」)
「设计模式 Design Patten」
这东西并不是种程序码,而是种用存粹口语文字描述的概念与策略思维,它的运作方式有点像是:「某专案的起始工程师甲使用了模组X,接手的工程师乙只需要知道工程师甲使用了模组X,就会知道工程师甲的程序码会长什麽样子,也能快速掌握如何扩充、如何除错、如何升级、如何进行专案客制修正。」
像Android对Activity设计了「生命周期」特性,这本身就是种设计模式,很多平台的模组都有「生命周期」的概念,(但具有生命周期概念的各平台元件长得还是有点不太一样,精通Android APP的生命周期,并不表示能够快速掌握Windows App的生命周期。原因.......不言自明啦!)
所以...设计模式并不是用来提供一个可以具体解决什麽问题或产生什麽功能的技巧,它真正的价值仅仅是方便工程师互相沟通而已。
但现实运作碰到几个问题...
很多工程师自己对设计模式的认知变得很狭隘,明明是使用了相似的设计模式,但「惯用A元件」的工程师似乎会被认为是「不懂/不具备/不熟练如何使用B元件的技术」。(这其实是「认为工程师在到职前就要懂各种需求的施工技巧去完成专案任务」的延伸。)
而且「使用设计模式去进行开发」的策略经常被执行了一半。
以Google自己来说,像ListView跟RecyclerView这两个「List介面」的实作物件中,都使用了Adapter去进行「大量产生重复View」,而後者算是用来取代前者的新增支援/扩充元件...这大概是因为Google工程师懒得去修正或扩充ListView,就乾脆新增一个「策略上不相容」的元件,来想办法让List的样貌在Android上可以更多元......
什麽叫「策略上不相容」,简单来说,要改用RecyclerView,就要针对专案进行大量的打掉重做(而不仅仅是修改)。将专案程序中使用ListView的地方改成使用RecyclerView,结果Adapter的程序也要重做,呼叫Adapter的地方也要重做。
简单来说,Google的工程师自己就犯了我在Day 4中讲的「懂很多的工程师」会犯的毛病!——它几乎不管其他要遵循它所释出的元件与标准的工程师会死得多难看。
也许我可以把这件事情讲的好听点:这些工程师忘了Adapter本身是个设计模式,但View一样也是个设计模式,既然是具有相同概念、也计划被用来解决同样问题的View,彼此之间应该要在物件导向使用上有种策略连续性......但那就不诚实了,而且Google身为一个累犯,实在不值得我说谎为他们掩饰。
所以......为什麽很多专案在技术上会死掉?
因为在元件升级(专案维护)这件事情上,主导的工程师并没有在管其他工程师死活,就擅自的跟随(认可)了Google工程师的无脑行为。
因为在选取专案工程师这件事情上,是否真的懂策略性思维(设计?使用?配合现有的设计模式?)比不上「读了多少Guide」「读了多少核心套件程序码」这类的事情来的重要,所以专案会碰到问题无法解决、会忽然失去扩充性、会忽然无法维护。
(任何Guide与设计模式都可能变成无用、拖累专案的废物,如果思维上不遵循着一些正确态度、或没有避免去犯「会问哪些Guide与设计模式无用」这类的错时。)
SQL 是常见的资料库语法, 许多网站都使用 SQL 语言来取得资料。 而所谓的 SQL Injec...
感觉经历了一段乱流区,我走到柜台,跟太子点了杯冰咖啡,就在等咖啡的时候,门打开了,看到一个身影,坐到...
已经迈向第29天了,但我还在熟悉Nodejs的表面的感觉, 想在这倒数第二天做出有点技术的东西, 可...
RegScanner 今天来认识看名字应该是注册表扫描?的小工具.... RegScanner 是可...
这篇文章,要来做一个最简单的 LiveView 范例,简单了解一下他怎麽用,体会一下他的运作方式。 ...