小土刀

新博客地址 -> wdxtub.com

【简单之美】敏捷之外

现在的项目开发,敏捷风正盛,好像垂死的病人找到了起死回生的灵药。很高兴这本书给我稍稍降了温,敏捷方法不是银弹,真正正确的做法总是潜伏在蓬勃的表象之下。通过了解作者的思考,我对于软件开发也有了全新的认识,虽然不知道自己能做到如何,但是至少应该避免那些已经明确被证明是错误的方向。


这本书其实是作者十年来对于软件开发的一些思考,究其根本,就是回到那个最简单最初的本质,从原点来看我们到底走了一条怎么样的路。唯一的遗憾要数作者的“情景故事”了,这一尝试的初衷是好的,想用故事的形式把道理说得更清楚,可是每一章开始就来一段故事,使得阅读体验非常糟糕,经常变换的人名和职务始终让我困惑。后来我发现,其实大可以跳过编造的故事,直接看思考的部分就好。

软件的美和价值在于创造,创造的根源在于想象。能够充分展开想象,是创造能力的集中体现。

一般来说,人们认识事物从简单开始,经过简单认识的不断堆积,然后在混乱复杂中摸索,最后又回归简单的认识。

任何时候都不要轻易丢弃一个非常简单的原则性想法,同时,在任何时候都不要固执于一个具体的想法细节。

具有讽刺意味的是,在软件开发实践中,很多设计人员提出的针对性能的解决方案往往是性能的最大瓶颈。

第一章是总论,在我看来,全书最精彩的部分,就是第一章。但反过来想,这对于一本书来说,很可能带来毁灭性的后果,就像一开口调就起高,后面很难办。这里有一点我很赞同,就是学习一定要建立自己的体系,然后把新学习的东西努力融入到自己的体系中,这才是效率最高,最能融会贯通的学习方法。

开源软件的开发人员,常常以一种松散的形式组合在一起,兴趣爱好是他们最主要的驱动力。对于这样的组织来说,过程可以最简化,只需要保留减少混乱、提升效率的活动,而剔除在缺乏主动性的情况下进行约束的所有内容。

当我们的智慧经过积淀和结晶,当这些积淀和结晶被记录在案,当我们拥有了知识基础,当我们的软件开发思想形成体系,我们将可以轻松面对任何变化。

为了提高软件开发人员的主动性,通常有两种方法。一种方法是,传播信仰,使团队成员成为同志;另一种方法是,建立一系列以人为本的实践方法集,用习惯和文化融合组织成员。敏捷软件开发致力于第二种方法。

软件开发方法不是解决执行问题的银弹。从约束到习惯的演变过程才是关键。你看,软件开发过程带来约束,长期的约束形成习惯,丰富的习惯促生文化,文化制造氛围,氛围产生最佳的执行效果。神奇的逻辑,约束最终将转变成自然!

第二章说的是软件开发的方法论,主要讲的就是CMM和敏捷方法,这两种方法可以看成是两代武林霸主,各有各的时代。但是其实具体的方法我一直觉得不靠谱,就像时尚风向,你永远追赶不上,唯一靠谱的就是找到最适合自己的方法,走上巅峰,引领潮流。最后所说的约束的进化实在很神奇,这个道理基本上可以用在任何团队和教育领域。

期望通过一两位专家就能把所有的需求传递给软件开发人员是不现实的。 不现实的原因有三点:首先,客户是一个群体,提出需求的人只是客户中的一小部分人;其次,提出需求的客户并不能完整地考虑到所有的场景;最后(也是最重要的),客户往往不能准确表达出自己的需求。

从技术角度来看,要保证信息的准确传递必须借助于术语。术语,是领域常识、是领域知识的浓缩。

限制需求的变化,不是解决问题的正确方向。这就像用“堵”而不是用“疏”的办法来治理洪水。正确的方向是,站在客户的立场,努力去发现和解决客户真正的需求。

需求变化永远是客观存在的。我们必须尊重客观规律(该来的变化迟早要来到),积极参与需求的变化之中,并尝试领导这种变化的发生、发展和消亡。

第三章说的是信息与需求,这一点我是深有同感。项目立项之前,老师跟我大致说了一下项目的方向还有目标,于是我根据自己的理解,做了前期调研还有初步的框架设计。但是上周跟唯*会研发部门的项目经理和技术负责人开会时,明显能感觉到我们思考问题的角度存在着巨大的差异,他们甚至有些天马行空,让我无所适从,根据他们的大致需求(虽然是一个合作研究项目),之前我设计的架构其实是不足以承载如此多的东西的。不过开内部小组会议的时候导师说暂时还用先前说的方案,我才真正放下心来。这给我的启发就是需求真的时时刻刻都在变,鸵鸟的做法没有办法解决问题,只能在设计的时候,预留更多的扩展能力。

框架的本质是约束。框架的设计者正是通过约束来传递软件构架思想的。在软件开发过程中,采用一个框架就意味着接受一种构架软件的思想以及随之而来的约束,所以从某种程度上来说,框架担负着传承知识资产的重任。

不是所有的隐喻都直接有助于软件开发,只有越简单的隐喻才越有价值。 在软件开发中,抽象的特征,是简化对事物的主观认识,隐喻的目标是抽象,因此,隐喻也肩负着简化认识的使命。

软件架构师应该具备的素质:诚实、想象力、生活经验、逻辑思维、理想主义者、兼容并蓄、反思精神。

第四章的内容则是框架与架构。我还记得大二的时候,懵懵懂懂跑去老师办公室,问如何才能成为一个架构师。当时看着架构师的年薪都是冲着百万去的,自然想要升职加薪当上总经理出任CEO迎娶白富美走上人生巅峰好吧我就是随口一说。这次真正要设计架构,唯一的感觉就是自己是真糊不上墙。真正演示时一页PPT,我想了一个星期,才大致有了个眉目,而且之前从来没有关注过这方面的知识,经验也不够,做不做得出来我自己都没有把握。好在这次主要也是我自产自销,希望我的架构不要让我受苦太多。

至于后面的部分,就感觉有些故意凑字数了,虽然故事很好看,历史也很有意思,动辄两三页的故事给我的印象就是:啊你真的没东西写了吗这样真的好吗。总感觉从第五章开始就逐渐偏离了简单这个原则,变得厚重而复杂了,不过既然是因为作者想要表达的东西太多,也就不能过分苛责了。

团队建设是一个很大的话题,不是一章两章可以说清楚的,而且我也没啥经验,这里就暂时留着,不过提到的常见的反面模式(就是错误例子)倒是很有参考意义,这里列出来,提醒自己不要犯同样的错误了:

  • 意外的复杂度(Accidental Complexity):向一个方案中引入不必要的复杂度。 

  • 积累再开火(Accumulate and fire):通过一系列全局变量设置函数的参数。 

  • 在远处行动(Action at distance):意料之外的在系统分离的部分之间迭代。 

  • 盲目信任(Blind faith):缺乏对bugfix或子函数返回值的正确性检查。 

  • 船锚(Boat anchor):在系统中保留无用的部分。 

  • Bug磁铁(Bug magnet):指很少被调用以致最容易引起错误的代码,或易出错的构造或实践。

  •  忙循环(Busy spin):在等待的时候不断占用CPU,通常是因为采用了重复检查而不是适当的消息机制。 

  • 缓存失败(Caching Failure):错误被修正后忘记把错误标志复位。 

  • 货运崇拜编程(Cargo Cult Programming):在不理解的情况下就使用模式和方法。 

  • 检查类型而不是接口(Checking type instead of interface):仅是需要接口符合条件的情况下,却检查对象是否为某个特定类型,可能导致空子类失败。 

  • 代码动力(Code momentum):过于限制系统的一些部分,因为在其他部分反复对这部分的内容做出假设。 

  • 靠异常编程(Coding by exception):当有特例被发现时才添加新代码去解决。 

  • 隐藏错误(Error hiding):在显示给用户之前捕捉到出错信息,要么什么都不显示,要么显示无意义的信息。

  • 异常处理(Exception handling):使用编程语言的错误处理系统实现平常的编程逻辑。 

  • 硬编码(Hard code):在实现过程中对系统环境作假设。

  • 熔岩流(Lava flow):保留不想要的(冗余的或是低质量的)代码,仅因为除去这些代码的代价太高或是会带来不可预期的结果。

  • loop-switch序列(Loop-switch sequence)使用循环结构来编写连续步骤而不是switch语句。 

  • 魔幻数字(Magic numbers):在算法里直接使用数字,而不解释含义。 

  • 魔幻字符串(Magic strings):直接在代码里使用常量字符串,例如用来比较,或是作为事件代码。 

  • 猴子工作(Monkey work):指在一些代码复用性或设计上很差的项目中的反复出现的支持性代码。通常会被避免或是匆忙完成,因此易于出错,有可能会很快变为Bug磁铁。 

  • Packratting:由于长时间不及时释放动态分配的内存而消耗了过量的内存。 

  • 类似保护(Parallel protectionism):随着代码变得复杂和脆弱,很容易就克隆出一个类似的结构,而不是直接往现有的结构中添加一些琐碎的属性。

  • 巧合编程(Programming by accident):尝试用试验或出错的方式解决问题,有时是因为很烂的文档或一开始就没把东西搞清楚。 

  • 馄饨代码(Ravioli code):系统中有许多对象都是松散连接的。 

  • 软代码(Soft code):在配置文件里保存业务逻辑而不是在代码中。 

  • 面条代码(Spaghetti code):指那些结构上完全不可理解的系统,尤其是因为误用代码结构。 

  • 棉花里放羊毛(Wrapping wool in cotton):常见的情况是某些类的方法只有一行,就是调用框架的代码,而没有任何其他有用的抽象。 还有一些项目管理上的反面模式,也很有趣。 

  • 死亡征途(Death March):除了CEO,每个人都知道这个项目会完蛋。但是真相却被隐瞒下来,直到大限来临。

  • 拖后腿的无知(Heel Dragging Blindness):项目经理的无知拖了后腿。出于某些动机,员工趋向于减少努力来延长项目时限。例如,他们是按时间(而非结果)付费,又没有能顺利转移过去的后续项目。

关于项目管理的书可能最近这就是最后一本了,希望能借用一下前人的经验,少走一些弯路。

评论(1)

热度(5)

©小土刀 | Powered by LOFTER