竹笋

注册

 

发新话题 回复该主题

程序员修炼之道第二版 [复制链接]

1#
治疗白癜风的方法 http://m.39.net/pf/bdfyy/

时间过得好快,过年左右还在看云风在博客中说自己正在翻译这本书的第二版,然后现在就拿到并且已经看完,还带着少爷看了一点;这本书上次看还是在刚走出校门的时候,当时对这类以及软件工程书籍多少都看了一些,然而发现理解不了;最大的部头还是CodeComplete这样的巨著,修炼之道坦白讲,我已经忘记第一版说的了,所以,没有等Kindle版出现,买了实体的书拿来看。

其实说全忘记也不科学,这本书的英文标题叫做ThePragmaticProgrammer,以前在文章里面写过我内心对自己定位的方向第一个就是这个词,大概率跟这本书有关,也跟一个法国电影有关。三个词是:

Pragmatic

Sharp

ValueTrend

这次看第二版,我觉得以后还会经常翻出来看看,他大致属于心法那种,需要你有过体会有过共鸣才会aha的一本书;所以,刚走出校门就看,然后都忘记,应该是符合逻辑的,哈哈,其实应该经常翻出来看,计算机技术和工程毕竟是实践性非常强的一门手艺,加上发展又很快,所以,其实需要这样的心法不断校正自己的思维和习惯,形成务实的风格和体系。

这次读,在项目声明周期管理上对几个问题也算找到了一些答案,觉得还蛮有意义的,所以就记录下来,可能不仅仅是答案,也有共鸣,也有一些精神烙印的加强。从设计、到重构、到测试、到交付需求,最后究竟追求的是什么?所以,我们可以慢慢来讲讲,会比较长。

优秀的设计比糟糕的设计更容易变更。

这个是作者的14号提示,后面也提过几次,篇幅很短,力量却很重。ETC,——EasiertoChange,不是我们过高速的那个,是优秀设计的原则,甚至已经超越原则,是价值观念。项目最终面对的是他本身的复杂度跟程序员大脑容量之间的矛盾,加上每天都在变化的外部环境,ETC就是最终状态,甚至以前看过一篇文章写,尤其如果你是做业务系统的,你的代码应该Easytodelete,该删就删。所以,在第二章中,作者讲了很多从这个价值观发展下来的原则,例如DRY、SRP等;其实,感觉这里没有什么好说的,就应该是这样的,最后体系结构的发展什么的,都是离不开这个原则,比如我们做分层,为什么分层,就是职责分离,为什么职责分离,在后面的发布部署扩容都是ETC的,所以,觉得没什么好说的。不过总要放在这里,表示这个是本书中最重要的一句话!

问题1:重构的目的是什么?以及一个大问题,是作者在书中跟着重构的这个部分发表的一个观点——系统究竟是像建筑那样,使用模式规划出来,还是类似一个有机体,自己“长”起来的?我记得以前好像有个Google的架构师还写文章说过这个问题。

随着程序的演化,其实需要程序员不断的停下来去还技术债;我觉得大部分技术人员或者技术管理人员一个苦恼的来源是,没有办法在项目进展过程中插入自己的checkpoint,没有办法叫停PM或者老板在新项目上的投入和进度安排,眼看着自己的代码变成一团乱码,自己心里越来越焦虑,最后离开团队,然后来了新人,压根不想接,索性,跟PM或者老板讲,上任太差了,我接不了,我必须从头做,于是第二个循环开始了~谁能打开这个loop呢,我自己会去平衡项目的进度和技术债的堆积,必须要重构;必须要review,做完每个里程碑,都要review,如果当初为了让功能work已经欠很多债,那就必须要切换到“扫房子”的工作上去。这就是重构的意义。——不要开启这个恶性循环。

好像是n年前毕业的时候,设计模式开始流行,然后弄得一个建筑师写建筑模式的书也很火,从那个时候开始,我们就被打上了一个精神烙印——我们程序员跟建筑师的思维方式是可以一样的;因为在当时,软件开发最常见的隐喻就是建筑的构建。商务人士或者职业经理人也觉得这个隐喻太高大上了,并且工程可重复,管理上有严格的汇报层次关系,于是这个系统就围绕着这个隐喻教育了我们很多年;到现在我都觉得从那个时代过来的程序员还保留着对模块化可插拔、高重用高复用这样美好世界的YY,然鹅每次都是一次巨大的挑战,也许就跳下了深渊。作者在书里面倾向于把软件工程或者架构设计类比为园艺,他需要你不断的修剪,不断的松土,不断的更换某个区域的布景等;我自己一直都觉得他像是个有机体,终究有部分会死去,那需要砍掉,也有部分在不断的在发展增强;所以,作者也说,尽早重构,经常重构。

问题2:怎么做测试?这个其实是困扰我挺久的问题了,上上个工作,我们核心研发才10个人左右的时候,老板把我们叫到办公室开会,说只讨论一个问题——“我们需要设测试的岗位吗?”,所有人都说不需要,于是就定下了后续在那个部门长达很久的没有测试岗位的惯例。上个工作,我提过几次,我觉得几乎不会有人答应,我就很怀疑当初我们是怎么那么快的做出决定的呢?

从沟通层次和管理层次上来看,虽然整个部门都没有测试团队,但不会意味着我们不去做测试工作,当然我也不能说我们当时的单元测试就特别全,或者覆盖率就特别高,但是因为缺少守门员,所以每一个开发同学就会更慎重,不能随便扔锅给别人了;lead会多少承担一些集成测试和压力测试的工作,因为workload比较大,所以,这些lead上来就会考虑自动化测试的事情,先驱者(项目开启的人)大概率也会提供mockserver的功能,因为他们自己上来就需要。产品上线之前,我们会召集所有PM、运营同学做bugbash,大家其乐融融互相杠……

如果有测试部门,我以前的经历中面对的问题是,开发同学自测的很少;测试同学压力很大;ticket的流程中转很多,尤其是开发和测试同学不在一个楼层,基本我们只盯着ticket的状态,天天刷列表;测试同学其实也不太了解业务逻辑,所以,还是会有很多的沟通工作;出事之后,真的谁来承担责任,这个算是千古难题吧,因为太取决于老板的性格了~团队之间,我觉得要么就互相吐槽,要么就互相取暖;虽然说共同承担责任,但是挺理想化的,不太务实~

嗯,我没有什么结论,我们现在团队也小,所以,3年内应该不会有测试岗位,但是不代表不做测试工作,也不代表就推荐给大家的团队,但是感兴趣的话,可以搜搜国外公司对QA职位的思想变化,但关键的一点,程序员不要把自己从测试工作中剥离出去。

坦白讲,工作20年了,我的第一份工作就是QA,到现在我还不愿意写测试用例,虽然n年前我也研究过TDD,也跟室友炫耀过写case的数量,但是有时候在想TDD是否真的合适,会不会overdo,你究竟要测试的是什么,尤其是我们做CRUD,上来写case判断入库出库,那你是在测试自己的代码,还是在测试人家ORM的框架呢?还好作者基本消除了我的疑虑:

测试与找Bug无关。

哈哈,标题*啊,不过很认可作者后续的逻辑了。“测试获得的主要好处发生在你考虑测试以及编写测试的时候,而不是在运行测试的时候。”所以,“测试是代码的第一个用户。”醍醐灌顶有没有,其实实际上可能自己是这么做,比如做webserver,我大概率先会写URL会怎么安排、参数怎么传递,这些请求体先写好,然后才去写handler,不过总觉得人家作者总结的更好,也基本为我不去追求覆盖率和case数量提供了很好的借口,哈哈哈。不带着大家回顾TDD的大致过程了,虽然最后你的测试代码数量远远超过业务代码数量,然后case全绿色pass给你特别大的安全感,但是这里关键的问题不是TDD,也不是全pass,而是case;我以前总在想,我们怎么衡量一个case写的好不好呢,他究竟是randomcasepassed,还是logiccasepassed,不觉得这是个难题吗?所以,不管使用什么方法、流程和指标,最底层的问题是你的目标是什么,你有没有在解决问题,是不是工作在Value的80%解空间域上?

这里有一个很大的延伸问题?构建系统“自上而下做,还是自下而上做”?你可能会问,我擦,这算什么问题?我们还拿比较常见的CRUD来举例,自下而上通常就是我们先做实体存储,然后做实体的API,然后做实体对应的缓存结果,然后提供实体基本的resetfulapis,然后再看最后需求端比如是个app他需要什么样的接口进行组装;自上而下可能就是,我们先看App那边的接口,然后大概率提供的是rpc类似的api,比如payAndOrder,然后再组装实体、存储啊缓存啊等等。自下而上是先提供小功能模块,然后逐渐组装;自上而下通常是逐渐拆解大问题,形成小问题,然后再解决小问题。

作者提供了一个68号提示:既非自上而下,也非自下而上,基于端到端构建。这个也暗合作者对于测试用例的看法,他也建议case大多都是端到端构建出来的case。作者相信,构建软件的唯一方式是增量式的。构建端到端的功能模块,不断学习和了解构建过程中的领域知识;因为作者觉得不管用什么方向是构建,前提可能都有一点不满足,就是我们并不知道我们的需求是什么?所以有了下面这个问题。

问题3:需求从何而来?开始看到作者写这个问题,甚至写下类似“程序员帮助人们理解他们想要什么”这样的话时,不禁在想,老外没有PM吗?需求有一个神话,就是他会在一定时间内已知的、不变的。然鹅事实从来不是这样,国内伟大的PM越来越多,开发人员能够接触实际需求的机会其实是非常少的,我觉得在大部分国内的PM和程序员之间也基本有了这种分工的默契;记得以前开会的时候,碰到一些跟产品发展有关的问题,我们程序员是需要离场的~很郁闷,我觉得大家都是在这个商业模式链条上的Stakeholder,关键利益者,在老外的很多书里面都会提到这个词。于是需求在开发者看来就更是一件神话的事情。

我觉得也没有什么好多说的,两点,作者也都提了:需求是一个过程;和用户一起工作。我觉得怎么强调都不过分吧。此外,从端到端的设计和构建这个角度来讲,UserStory是特别好的需求整理方式,他就是对端到端的描述,但是我们现在大概率首先接触到的都是设计稿,然后一个设计稿上n个交互点,哪种方式更好,估计每个公司都不一样——设计稿其实也是一种端到端的需求描述,但是被聚合在一起了,在任务和里程碑的拆解上,不算合适的。个人观点,毕竟隔行如隔山~

问题4:这些东西要解决的终极问题是什么?修炼的是什么?其实我最近还在同时看一本Devops的书,那本书前5章都在讲道,我觉得跟这本书的最终思想是一致的。所以,除了作者提到的敏捷,我又加了个精益。

学习这么多终极目标是什么?

把软件产品交付给用户!

什么是务实的做法?

敏捷、精益!

什么是精益?

小批量任务交付是提升质量、客户满意度和员工幸福感的关键因素,这就是精益!

什么是敏捷?

快速响应用户的需求变化,更新对用户领域知识的理解到系统中,做出容易改变的系统产品,及时交付给用户,这就是敏捷!

我按照我自己理解写的,虽然已经好多年不太去接触敏捷和精益这样的词了,不过一直很认可精益,我们也不断的在使用小里程碑的方式去做,绝对不赞赏“憋大招”,最后把自己憋坏了;不过今天读完,对敏捷又清楚了一层,以前还是有些困惑的,包括很多高级理念、流程、SOP、Scrum、站会,我都不太理解。技术永远都是手段,他是来解决问题的,那这些手段在解决什么问题?作者在这里也没有说太多,他说其实关键问题已经在敏捷宣言里面的价值观写的很清楚了。

敏捷宣言四条价值观:

个体和互动高于流程和工具

工作的软件高于详尽的文档

客户合作高于合同谈判

响应变化高于遵循计划

第一条尤为重要,团队要敏捷必然来自于一个充分沟通无障碍的团队,来自于实施团队跟用户之间的互动合作,我觉得是基础,所以,最近一个月我们都没有再更新sprint了,本来稍有些焦虑,后来发现,我们现在过程中的个体的互动沟通特别充分,那其实何必执拗于工具呢?

敏捷永远不是一个工艺流程,更不会是一个标准流程模型;他是一种选择,一个形容词;底层逻辑来源于系统动力学中的增强反馈,敏捷都在说要加强反馈过程;而最后结果是要为用户交付可工作的软件。

随着人的成长,软件的复杂度不仅仅来自于代码级别,越来越多会来自于项目级别,来自于沟通级别,但是为了更好的解决这些复杂度的产生,回避他们不会是出路,只有去迎接挑战。而伟大的项目管理者,都是复杂度的“高级驯兽师”,掌握的信息、广度和深度,自身和团队的思考、沉淀,鼓励改变、拥抱变化,迎接挑战,像每一个工匠一样,自豪的为自己的作品签上名字,传递给后人~

所以,作为一个四十岁的工程师,我们并不需要担心太多,嘿哈!

预览时标签不可点收录于话题#个上一篇下一篇
分享 转发
TOP
发新话题 回复该主题