×

Loading...

【精华】IT 入门攻略 (5) 知识(B)

本文发表在 rolia.net 枫下论坛俺上篇文章说,读完了 Java Tutorial 算3个月的经验,其实俺是说低了,因为俺好害怕被那些码工卫道士们骂做以次冲好的劣币。其实外面大部分码工都不读书,很多人对基本的东西都是一知半解,跟他们相比,你读一两本好书,真不能用几个月的经验来相比。

俺这篇文章要教给你的,值6个月的经验。其实俺也是说少了,因为俺好害怕挨骂。俺觉得,这篇文章里的道理,如果你真懂了,真能吹,外面有几年甚至十几年经验的码工都不如你。

俺有一个观点,就是操作不重要,道理最重要。做一个码工,最大的道理是什么?这个问题俺也想了十好几年。俺觉得,码工最大的道理,就是懂得什么是 complexity,懂得如何 manage complexity。

有一次俺在坛子里鼓吹 complexity,某网友说,编程有什么复杂的?再复杂的东东,到他手里也是小菜一碟。听了这个网友的话,俺恍然大悟,原来俺说的 complexity,确实不是通常意义上的 complexity。俺举两个通俗易懂的小例子,解释一下俺的 complexity。

大家都知道,Windows Start button 有一个菜单,叫 Shutdown。不止一次,俺按了 Shutdown 就走了,以为电脑就真的 shutdown 了。很久以后回来一看,电脑没有关,屏幕上是一个窗口,里面还有几个选择:

1. Shutdown
2. Logoff
3. Switch User
4. Restart
5. Cancel

其实微软的这个设计就是 complexity。Shutdown 是一个很明确的动词,把它跟不同的动词绑在一起,而且还分两步,就复杂了。首先你要解释,documentation 变复杂了。其次即使解释了,用户也可能不知道 logoff 或者 restart 原来在 shutdown 底下。再者码工在实现这个功能的时候十有八九也是把这几件事掺和在一起,程序变复杂了,所以容易出错。

俺们家买 grocery,俺负责买水果juice和面包。不止一次老婆自作主张也买了面包,俺们家一个礼拜都吃不完一袋面包,结果现在有了两袋。想想全世界吃不饱穿不暖的阶级兄弟们,俺真是羞愧啊。两个人干一件事,就有了 complexity。这种 complexity 在软件里是比比皆是。

做软件,效率低,bug 多,软件做出来不容易读懂,不容易改,往往都是因为诸如此类的 complexity。这个道理,大部分码工不懂。你懂了,你就胜他们一筹,这种知识绝对不是几个月的经验可比。当年俺面试码工,一百个人里也就几个人知道有一个概念叫 coupling。其实 coupling 是软件设计里最重要的一个概念,complexity 的一个罪魁祸首就是 coupling。

如何 manage complexity,换一种说法,就是如何写好的代码。好的代码之所以好,是因为它 reduce complexity。

想写好的代码,捷径也是读书。有一本书,极端通俗易懂,叫 Refactoring: Improving the Design of Existing Code。读完了,可以抵6个月的经验。还有一本书,叫 Code Complete,对我的影响也很大。这种知识的经典书,应该是四人帮写的那本《Design Patterns》了,可惜那本书不容易读。

外面诸如此类的书数不胜数,网上的文章博客也是层出不穷。只要你有心,你能找到很多好书好文章。更多精彩文章及讨论,请光临枫下论坛 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 也不会改变其本质。
                • 老兄我早就说过,你我只是观点不同而已~~~不要动不动上纲上线的
                  • 请别说我和你观点不同。在谈计算机基本概念的时候,如果我的理解是错的,我希望大家指正。这个不是你有你的观点,我有我的观点的问题。