×

Loading...
Ad by
  • 推荐 OXIO 加拿大高速网络,最低月费仅$40. 使用推荐码 RCR37MB 可获得一个月的免费服务
Ad by
  • 推荐 OXIO 加拿大高速网络,最低月费仅$40. 使用推荐码 RCR37MB 可获得一个月的免费服务

【精华】IT 入门攻略 (6) 知识(C)

本文发表在 rolia.net 枫下论坛俺前面说过,照俺的知识篇做,能抵一年经验。知识(A)抵三个月,知识(B)抵六个月,还差三个月。有一本书,叫《Test Driven Development: By Example》。读完这本书,你就有了剩下的那三个月。

之所以把这本书单独列出来,是因为 test driven 这个理念很重要。软件的一个巨大特征,就是一个软字。因为软,所以可以多变,而且做软件也确实是多变。一个程序,从想法到产品,要经过无数次修改。即使成了产品,新的东西也会源源不断地被加进去,所以变还是必然的。只有充分的领会到这个多变性,才能真正领会很多做法的重要性,包括 test driven development。

我做过很多地方,同事都是经验丰富的码工,但是真正遵循 test driven 的地方,基本上是没有。大部分地方,上一个新 feature 是很痛苦很危险的事,要花很多时间测试,即便如此,出错也是很常有的事。

没有 test code,也是导致软件 complexity 的一个重要原因。因为没有 test code,很多应该改变的代码没有被改,因为怕牵一发而动全身。久而久之,这种不合理的代码就越来越多,程序就越来越复杂。

俺觉得,如果你能领会书里的精神,能照书里说的做,你比大部分做了三年五年混饭吃的码工都强。xml 老兄质问,你为什么老是要跟混饭吃的比?因为俺的经验是,大部分人都是混饭吃的。如果你有天资,又有 passion,却混不到一碗像样的饭,俺窃以为不公平。

这就是俺乐此不疲写这些文章的原因。更多精彩文章及讨论,请光临枫下论坛 rolia.net
Sign in and Reply
Modify
Report

Replies, comments and Discussions:

  • 工作学习 / 事业与工作 / 【精华】IT 入门攻略 (4) 知识(A)
    • Java Certification Guide, 如果没记错的话,是蓝颜色的吧,很多回忆,99年时几乎每天伴我。
    • 【精华】IT 入门攻略 (5) 知识(B)
      • 说实话我真的挺纳闷你怎么就能这么乐此不疲地贴这类帖子。说你不懂吧,你好像还懂一点儿,说你懂吧,那你就是故意误导初学者了?
        和任何行当一样,coding 就是一个学习 - 实践 - 再学习 - 再实践... 的过程...
        看三个月这本书,再看三个月那本书,再背一通面试题 ----- 赶上垃圾面试官(或特善良的面试官),你可能能得到一工作。但这样你就比那些有几年经验的真正 coder 强了?(你非要和混事儿的 coder 比我也没办法)

        所有在这里强调编程经验的人(你所谓卫道士的),都是自己走过这段路,返回来想让初学者对编程循序渐进的步骤有个真正了解的好心人。
        大部分人都不是天才,不是看一本 21 天编程,第 22 天就开始看 design pattern 就能真正理解的了。
        围棋定式不是背出来的,是下出来的。
        大部分人都得看一点书,编两年程,再看深一层次的书,印证自己的 *经验*,然后才能提高。
        这是 “卫道士” 们的所谓经验观。从不动手一路看书就全明白的 ---- 那是王语嫣。

        这个论坛好些“卫道士”们热心解答初学者的技术问题(包括贴 code),而不是忙着给初学者指点莫名其妙的所谓攻略。

        另外,你关于 decoupling, single responsibility principle, user experience design 很多例子都不恰当。但实在没时间,也没兴趣一一纠正了。
        就这么着吧。
        • 借帖子问个问题。
          随便举个例子,做个项目。

          怎么才能越早并最大化地 UNDERSTAND 项目的 SOW 呢?有时候,或者很多时候不能完全明白 SCOPE,闷头做下去,在某一点会发现和 SCOPE 或者其他 ELEMENT 有冲突了。然后再 REVISIT 项目的 SOW。项目构思的时候,怎么才能减少以后走弯路的 RISKS 呢?

          还有初期的 PLANNING 很重要。你懂的。好像打仗布阵一样。这个“布”怎么实现呢?谁来实现呢?

          对不起,问题有点乱,我自己也没完全想明白。
          • 据说att 或是其他什么公司,你问问题先得对着一个玩具熊问 - 很多人把问题描述清楚后,自己就知道答案了 lol...
            • 我觉得 MENTAL HEALTH COUNSELOR 的工作就是这样的。
          • 只能说写sow的人水平不够。水平越高经验越多这种事情出现的可能性越低。
            • SOW 里都是 NEEDS 的时候,很难说水平不够。要说 NEEDS 翻译成 GOALS 的时候,NEEDS 不能完全完整透彻的理解,那例子可海了。
          • 软件工程和你的建筑工程很不一样。软件业现在的潮流认为这是不可避免的,所以只好每一步都迈小一点,每次只计划下个月要做的,做出来拿到反馈再计划后一个月的。大系统拆成小模块来做,每个模块换掉重做的代价也不大。
            • waterfall vs agile.. but most of the agile team is not really agile. and the problem is coming from the PMs, not the coders.
          • 如果想用人类语言没有任何ambiguity滴定义清楚一个项目要求,我认为这种想法是很搞笑的。
            • 我又看了一遍自己的帖子,还好我说的是“减少”,而不是说“杜绝”。
              • lol
        • 说你有成见,一点不假,你总是把我说的话看扁。我上一篇讲的就是实践,三个月的实践,资质好的三个月,资质差的六个月一年也未可知。这种强化的实践,绝对抵得过普通上班的混一年两年。我没有说背面试题,面试题问的是关键,研究面试题也就是学习关键,这是一种学习方法。
        • 我为什么乐此不疲的写这些文章?因为想帮第一代国移找一个饭碗,不光是初学者,也包括有些编程背景的人。这些人的痛苦,你老兄可能没法理解。如果能帮他们一个人找到工作,我就很欣慰了。而且我觉得我的这些文章对已经做码工的人也有启发,除非他们象你这样带着偏见看文章。
          • 尽管我不是developer,但对红卫兵这种用心得去启蒙新人的精神点赞
            • +1
        • 关于 decoupling,design,老兄如果有不同意见,我们可以讨论,我是相当有兴趣的~~~
      • 支持红兵这种分享编程心得的做法
    • 多谢兵哥的有营养的帖子
      • 谢谢捧场
    • 弱弱问一句:可以帮助提高我的码感吗?
      • 俺以为码感是天生的,没法提高的
    • 兵哥,兵嫂入行是不是十几年前IT大潮时代的事啦?你说的虽然有的地方有些道理,但是不觉得有人能这样通过我工作过的任何一个team的面试。
      • 本来以为兵哥是高人,以前还被兵哥批是半路出家。看了这几贴我才明白什么是秃驴看到的都是秃驴...
        • 我什么时候说你半路出家了?只不过说你概念不清,而且说的是事实
          • 对对,我是秃驴。
            • 讨论问题,何必生气呢。
              • 我这不是陪笑嘛,哪是生气了。
          • 兵哥,请解释一下啥叫Type Erasure. Cake pattern, Monad in Functional Programming不要Google哦。
            • 真的不懂,不好意思
              • 我这不是概念不清嘛...
      • 难度肯定比以前大,但是我仍然觉得可行。第一份工作要的不是通过你的 team 的面试,而是通过某些地方的面试,这些地方条件可能艰苦一些,pay的可能差一些。不过我觉得只要你们有 open mind,用我的方法的人,如果资质不差,应该能做好你们那里 junior 一些的工作。
    • 老实说我很佩服你们这些热心人, 读者能得着多少就不好说了, 毕竟每个人情况/能力不一样~~~ BTW, 卫道士是谁们? ~~~
      • 能帮上几个人,我也不抱希望。我觉得最难的还是克服不自信,所以我用了半年一年经验这些量化一些的说法,没想到卫道士们看了很不高兴~~~不过对已经走在这条路上的国移们,我希望我给他们指了一条正路
    • 那时候,扫地的王大妈培训Java半年也能拿六万, 所以兵嫂的转行经历现在不可行吧。
      • 我觉得基本面没有变,只不过市场变了。基本面就是做码工能者不难,码工市场任人唯贤,所以我觉得这条路仍然走得通,只不过是现在市场不热,找第一份工比以前难而已。
        • 您的帖子无论如何都是要支持的,这坛上有太多说话偏激,语气生硬,指手画脚的红卫兵小将。
    • 【精华】IT 入门攻略 (6) 知识(C)
      • 好书,我还在看
      • 这本书没听说过。兵哥,除了这本,能不能推荐几本软件测试的好书?正打算提高一下。
        • 这一本就够了。test driven 讲的是编程的理念,而不是如何做 QA。我个人不看好QA,我觉得如果程序有足够的 test cases,对 QA 的需求只会越来越少。
          • 不是要改行干QA,是要自己写点unit test代码。也看了几本书,老实说,书似乎看懂了,可还是不会做。所以请大家推荐测试方面入门的好书,能教会我些写unit test 就好。
            • 不知道你用什么语言和开发工具,你到 youtube里用tdd搜一下,有不少step by step的video。挑个最短的(8~10分钟)演示coding的看看,照着做一遍,可能就入门了。
              • 谢谢,我试试。估计我下一段要用 linux 和eclipse开发。其实我也看了几本测试的书,都是泛泛地讲概念,没例子。不具体。测试的概念倒是明白一了一点。
      • 兵哥,test driven还只是技术性的书,推荐你去读cmmi方面的书,可以让你的工作从战术上升到战略的高度看问题,充分理解老板的意图,进而在玩弄办公室政治上游刃有余
        • 我从来都觉得 CMMI 是 wasteful useless harmful paperwork,但愿我是错的,你是对的~~~
          • 我只能说你不懂。。。。
            • 不懂是肯定的,知道一些,觉得是学究般的荒唐,所以没有深究。个人觉得搞软件 agile 才是正路,CMM 不光是方向反了,而且在反方向走到了 extreme。
              • agile和cmmi其质量控制体系原理是一样的,只是操作的方式有所调整,做到extream的不是cmmi不行,而是操作的人不理解其原理导致的,不过这本就是隔行如隔山的事情,你不懂也没什么,contractor只要听话就行
        • 想起来你是说办公室政治那位网友了。冠冕堂皇的大东西确实可以用来压人,真的建议你能把经验写出来。我们做短工的,不太需要办公室政治。
      • 刚好最近看完了这本书,写的不错。兵哥能否多说说TDD的好处和坏处?还有敏捷开发?好像肉联上挨踢盖很多,但讨论这个的不是太多。
        • TDD 的好处我文章里谈过,一是测试自动化(大部分取代QA),二是改变程序更容易(没有QA)更有信心(自动 regression 测试)。坏处就是要写要维护两套代码。你回 xml 兄的帖子我同意,很多代码不用测试的。
          • 我想我已经解释过几次了,TDD 的第一好处是帮助验证 design 是否 loose coupling。TDD 主要是帮助 dev 的,不是取代 QA 的 work。 repeat qa 的 work, 那个不是 unit test, 那叫 QA 自动化。很多人把这两个混为一谈。
          • 就我看TDD和QA,一个是白盒,一个是黑盒,再加上UAT的话,测试的手段方法目的都不太一致吧。
            • 这里有没有专业QA?说说区别?
              • LS两位是对的,红卫兵知识需要拓展
                • 你不要误导好伐。
                  • 说说你的正确观点,哪里误导?
                    • 呵呵,我是 IT 盲,专来捣乱的。
                      • 小C你就不要呆在一边幸灾乐祸了~~~IT 这一行我做了无数年了,也思考了无数年,说出来的话顶多是观点 debatable,不会离谱的~~~
                        • 是不是离谱,由不得你说。不过呢,别人怎么说,你还按自己的来。任天下人怎地,红卫兵自岿然不动。心态啊心态,这叫一个强大。
                          • 小C啊,你对我发那么大火,生这么久的气,真是不理解啊~~~我写这么多文章,肯定有误导的地方,人非圣贤,岂能不误导?我批评你,直接原因是你误导,但是根本原因是你对当时的话题一无所知,而且你也知道
                            • 跟你生气?真抬举你自己。跟着起哄,我看热闹罢了。我就算不跟你的贴,你也得得瑟瑟的跟我的贴。与其被动,还不如主动。
                              • 生不生气,大家有目共睹~~~我有没有跟你的贴,大家也是有目共睹~~~在我的文章里看热闹,肯定是要让你失望了~~~说句不吹牛的话,我做过很多地方,从来没有遇到过一个码工像我这样想的深,想的广
                                • 哈哈哈哈。尊敬的 KING OF WORLD,您好。
                • 老兄过于拘泥于文字了。
                  • 我觉得你是做合同太久了,很多东西了解很狭隘,看法都是程序员的角度,让我觉得外行,如果你有机会去操作一下大点的项目,你就会理解我说的
                  • 你很多基本概念混乱,别人指出,你就说别人过于拘泥文字了。别的题材无所谓,但这方面真心不想看到初学者被你这样误导,才顶着砖头指出来。都是特简单的东西,叫你几个名词一说,几个不恰当的例子一举,初学者反而跟着你把几个基本概念都弄混了。
                    • 我没有基本概念混乱,只不过我从不咬文嚼字。我的文章给初学者讲方法,讲道理,不是讲名词定义。
                      • 这么说吧兄弟,你说的那些书都是好书,你就给初学者列个书名就行了,但别去解释里面的内容了,也别给例子了。因为你很多解释/例子都是似是而非的,似是而非对初学者误导最大。你很多理解不到位,之所以会这样,
                        我觉得就是和你的治学观有关。

                        前面已经说了,我们都想帮助初学者入门,但一定要循序渐进。初级 coder 应该会什么,中级会什么,高级会什么,得一步一个脚印。
                        得像医生或会计行当一样,有的证书你必须干够一年或两年以上才能去考。

                        你说的那些书没问题,问题是你给初学者画不切实际的大饼 ---- 看了这本顶三个月功力,这本 6 个月,这本又 6 个月,这样你就成大牛了...
                        no way...

                        那些书都是好书,但是看了,和看懂,是两码事儿。很多书必须有一定项目经验(项目大小无所谓,但要两个 version 后)之后才能明白为什么。
                        一气看下来,就会和你一样不求甚解,似是而非了。

                        我也能理解为什么初学者喜欢看你的文章系列(这里就不分析了) ---- 但是麻烦你象个 coder 一样,稍稍严谨一些,ok?

                        我们 coder 写一点点东西,很累的 --- 因为很仔细很仔细,生怕误导别人。和技术有关的,一般 post 之前一再 google 一遍又一遍,生怕出错误导别人。
              • 对别的公司不太了解,只能说说我现在公司的情况。在我们公司,程序员写程序加unit test;专职的QA写test plan,然后做测试,一般依据BA的文档测功能,不太写程序;客户有专职QA做UAT测试。
                多一句,客户自己的QA基本上都不是cs出身的,大部分是从客服部门转过来的,对business比较了解。
            • 个人觉得没有必要分黑白。最佳的情况是 contiuous delivery,任何 change,从 code 到 deployment,全部 automate,没有QA。
              • 不可能地。客户需求和BA文档总有出入,介面流程也常常可商量,UAT的测试也就不可缺少了。而保证BA和程序员间的一致性就靠内部QA了,除非BA take内部测试,当然也有公司只有老板和程序员,没BA也没QA,哪是比较极端的情况。
                • WhatsApp据说只有30来个人,支撑好几亿的用户,不知道他们咋整的,有QA吗?
                  • 我想大部分原因是他们的业务逻辑很简单,甚至于连transaction control都不用太考虑,客户message偶尔丢包也不是严重问题。如果是金融保险业只怕就不可能了。
              • QA做的是integration test,码工做的是Unit test,两者不能互相代替。
              • Unit test最多只保证自己的程序和自己的理解一致,没法保证自己的理解和BA的要求一致。现在有些招BA的广告要求BA能写test case,实际上就是BA take了QA的工作。但从工作的细化而言,这可能不是潮流。
                • BA写的是UAT的rest case 吗?
                  • 我们公司BA不写test case。我想即使要写,也是写内部QA(FT)的test case。
                • BA 写 test case 也应该只 cover happy path,QA 还应该进行边缘条件测试。
                  • 按道理来说,应该如此。一般而言,BA工作的侧重点是收集用户需求,应该没时间做面面俱到的测试。
                    • 对啊。我的意思也是这样 --- BA 和 QA 应该各有各的侧重点,有一点点交集,但不应很多。
                      • agree。
              • 这句话一说,就显得你完全在故意误导了。我和上面几个兄弟解释很多遍了,unit test 是 dev 以降低 dependencies + 解耦和为手段,对 dev 的 code 每个 *unit* 来 test 的。QA 是以最终客户角度来对 app 进行 end to end 测试的 --- automated 也不会改变其本质。
                • 老兄我早就说过,你我只是观点不同而已~~~不要动不动上纲上线的
                  • 请别说我和你观点不同。在谈计算机基本概念的时候,如果我的理解是错的,我希望大家指正。这个不是你有你的观点,我有我的观点的问题。