×

Loading...
Ad by
  • 最优利率和cashback可以申请特批,好信用好收入offer更好。请点链接扫码加微信咨询,Scotiabank -- Nick Zhang 6478812600。
Ad by
  • 最优利率和cashback可以申请特批,好信用好收入offer更好。请点链接扫码加微信咨询,Scotiabank -- Nick Zhang 6478812600。

如何提高你的码感 (之二)

本文发表在 rolia.net 枫下论坛顺便说一下一个 coder 应该有的最最基本能力:基本逻辑推理,归纳,抽象

有了基本逻辑推理能力,你至少能写好一个 method。
有了归纳能力,你能写好一组 methods (该在哪里实现的东西就在哪里实现),进而能设计合理的 class,做到符合 single responsibility principle.
抽象能力需要一点点天赋 + 很多实践经验。顺便说一句,这个技能 coder 需要,BA 更需要,虽然抽象的最终目标可能不同。

如何把用户需求抽象出来?一般书上都会举一些 employee, manager 之类的例子,大学教程里面会用 animal,cat,dog lol....
那些例子没有一个是错的,但是很多人很多年以后,”抽象业务需求“ 还是停留在拟人或拟物的思想境界...

看到过 jr dev 纠结于 book.Save() 是不是个好的 design -- book 能 save 它自己么?
看到过 jr dev 纠结于 fish 到底什么时候 implement 吃或被吃的 interface? hmm, 吃,或被吃,真的是个问题。
...

其实说破了很简单,你需要从业务需求的角度来做抽象设计,你的 fish class,根据你的客户是 1 餐馆, 2 fishing club,3 kids who play your fishing game,是完全不同的。
一旦跳出了拟人拟物的套子,很多问题就迎刃而解了,你多半不会纠结于 book.Save() vs bookManager.Save(book) 了。

完全理解需求,明白如何抽象,good。但和能设计出可扩展的抽象,还是有一点点距离的。
关键点在于,你是否能够预测需求的变化趋势 ---- 这个需要实际经验来弥补了。

返回来说 coding.
完全理解需求,明白如何抽象 --- 你的 class diagram 看上去简单,漂亮 ---- 连 BA 猛一看,都会说,这有什么难的,这不就是我的业务需求么(呵呵,几乎是的,这里省略 100 字,有时间再说)。把 code 写得难懂,猴子都会,写简单了,才能算是 coder。

-----------------------
同时,你的 code 要至少能 unit testable。
TDD 之所以重要,是帮助你验证你的 design 符合 single responsibility principle.
一个 method 里面做了太多事儿,你很难写出一个简单,漂亮的 unit test for it.
一个 class 里面做了太多事儿,你很难写出一个简单,漂亮的 unit test for it.
一个 method 里面有太多的 dependencies,你很难写出一个简单,漂亮的 unit test for it.
一个 class 里面有太多的 dependencies,你很难写出一个简单,漂亮的 unit test for it.

所以你觉得你设计的 class diagram 简单漂亮之后,写 unit test。如果你纠结于一个 unit test 很难写 ----- 多半你得改进你的设计。

unit testable 之后 ---- 真的所有的 method 都要有 unit tests 么?
真的。


真的么?
真的。


真的么?
好吧,你自己看着办吧。
很多人(比如我自己)的理由是,我写了那么多 unit tests,业务需求一变,30% 就废了,我的 design 很好,业务需求变了,我的 design 很容易适应,但 30% unit test 得老老实实重写,真的要么?真的真的要么?
真的。
如果一个需求会导致 30% 的 unit tests 重写 ---- 没准儿你的 product owner, scrum master, QA manager, DEV manager, VP... 得有个心理准备... lol...


会有 (之三)么?更多精彩文章及讨论,请光临枫下论坛 rolia.net
Sign in and Reply Report

Replies, comments and Discussions:

  • 工作学习 / 学科技术讨论 / 如何提高你的码感
    本文发表在 rolia.net 枫下论坛码感这个词有些主观了,作为 coder 我们谈谈一些客观的东西。

    (如何去读书我就不提了,各个时期有各个时期的编程圣经,每个人都有自己心目中的编程书架。)

    这里是我对我写的代码的要求:(假设我们使用高级语言比如 c# / java 编写商务应用程序)
    我尽量告诉计算机 what to do, not how to do it
    我告诉计算机 what to do,尽量用接近业务需求的人类语言
    我写的 method:一个初中级 coder 浏览我的代码,应该能够平均每秒看懂一行,绝大多数 methods 应该在 20 秒之内理解。否则我应该改进。
    我设计的 class:一个中高级 coder 浏览我我的 class diagram 应该能够平均每分钟理解一个 class,即如果 object graph 有 10 个 classes,应该 10 分钟内理解 design。否则我应该改进。
    那些 coder 看我的 code,应该觉得非常 enjoy it。
    (整体架构设计不容易这样定量,这里跳过。)
    编写 c# 程序,我使用 resharper,我写的程序,resharper 不应该有疑问,如果有,我一定要 review 并 confirm。
    我写的 code 就算没有 unit test code,但设计一定要 unit testable,除非碰到不可抗拒的外因(比如必须使用一个很难 unit test 的第三方框架等等原因)。

    回到那个主观的“码感” --- 我觉得如果你 enjoy 读你自己写的 code,别的 coder 也 enjoy 读你的 code,refactoring tool 也喜欢你的 code,unit test framework 喜欢你的 code,甚至 BA 都能理解你的大部分 code (如果你做 business app),你可以说你自己有码感了。更多精彩文章及讨论,请光临枫下论坛 rolia.net
    • 不好意思的说一句,你这个怎么看也不象是讲码感,倒更像怎么写好的code。
      • 你说得对。我只是个 coder 比较喜欢务实。如果谁能抬手就写出好的 code 我就说谁的码感好。
    • 激将法又让坛子里多了个写手,呵呵。
      总结一下哈,有“感”,不是自己说的,自己说了也没用,要从 PEER 上体现和反馈出来的。有木有?
      • 对。这个 peer 还得包括 cpu, ide, tools, unit test framework ...大伙儿都喜欢才行 lol... +1
        • 给个赞!
      • miss 看小孩 practice 好几分钟了,后悔 ing...
        • 比赛不是总有嘛。昨天俺妞的 100 YR FREESTYLE 后半截我都没看到,她还拿了个小组第一,有个家长非得让我给她看 HEAT SHEET。恨。
          • 就算比赛天天有,今天的比赛已经不是昨天那场了,今天踢比赛的那个小孩已经不是昨天那个了。lol...
            • 看着小 P 孩一天一个样,真是有意思。看她水里拼的时候,突然想:怎么一下子就这么大了呢?昨天看她不是从台上 JUMP 到水里,而是 DROP 到水里,我还训了她。她说:妈妈,I DID MY BEST!
    • 如何提高你的码感 (之二)
      本文发表在 rolia.net 枫下论坛顺便说一下一个 coder 应该有的最最基本能力:基本逻辑推理,归纳,抽象

      有了基本逻辑推理能力,你至少能写好一个 method。
      有了归纳能力,你能写好一组 methods (该在哪里实现的东西就在哪里实现),进而能设计合理的 class,做到符合 single responsibility principle.
      抽象能力需要一点点天赋 + 很多实践经验。顺便说一句,这个技能 coder 需要,BA 更需要,虽然抽象的最终目标可能不同。

      如何把用户需求抽象出来?一般书上都会举一些 employee, manager 之类的例子,大学教程里面会用 animal,cat,dog lol....
      那些例子没有一个是错的,但是很多人很多年以后,”抽象业务需求“ 还是停留在拟人或拟物的思想境界...

      看到过 jr dev 纠结于 book.Save() 是不是个好的 design -- book 能 save 它自己么?
      看到过 jr dev 纠结于 fish 到底什么时候 implement 吃或被吃的 interface? hmm, 吃,或被吃,真的是个问题。
      ...

      其实说破了很简单,你需要从业务需求的角度来做抽象设计,你的 fish class,根据你的客户是 1 餐馆, 2 fishing club,3 kids who play your fishing game,是完全不同的。
      一旦跳出了拟人拟物的套子,很多问题就迎刃而解了,你多半不会纠结于 book.Save() vs bookManager.Save(book) 了。

      完全理解需求,明白如何抽象,good。但和能设计出可扩展的抽象,还是有一点点距离的。
      关键点在于,你是否能够预测需求的变化趋势 ---- 这个需要实际经验来弥补了。

      返回来说 coding.
      完全理解需求,明白如何抽象 --- 你的 class diagram 看上去简单,漂亮 ---- 连 BA 猛一看,都会说,这有什么难的,这不就是我的业务需求么(呵呵,几乎是的,这里省略 100 字,有时间再说)。把 code 写得难懂,猴子都会,写简单了,才能算是 coder。

      -----------------------
      同时,你的 code 要至少能 unit testable。
      TDD 之所以重要,是帮助你验证你的 design 符合 single responsibility principle.
      一个 method 里面做了太多事儿,你很难写出一个简单,漂亮的 unit test for it.
      一个 class 里面做了太多事儿,你很难写出一个简单,漂亮的 unit test for it.
      一个 method 里面有太多的 dependencies,你很难写出一个简单,漂亮的 unit test for it.
      一个 class 里面有太多的 dependencies,你很难写出一个简单,漂亮的 unit test for it.

      所以你觉得你设计的 class diagram 简单漂亮之后,写 unit test。如果你纠结于一个 unit test 很难写 ----- 多半你得改进你的设计。

      unit testable 之后 ---- 真的所有的 method 都要有 unit tests 么?
      真的。


      真的么?
      真的。


      真的么?
      好吧,你自己看着办吧。
      很多人(比如我自己)的理由是,我写了那么多 unit tests,业务需求一变,30% 就废了,我的 design 很好,业务需求变了,我的 design 很容易适应,但 30% unit test 得老老实实重写,真的要么?真的真的要么?
      真的。
      如果一个需求会导致 30% 的 unit tests 重写 ---- 没准儿你的 product owner, scrum master, QA manager, DEV manager, VP... 得有个心理准备... lol...


      会有 (之三)么?更多精彩文章及讨论,请光临枫下论坛 rolia.net
      • #5404259@0 虽然不是编程人员,但看的我很同意
        • 虽然很荣幸得到您的同意,但我还是要和您 argue 当年 win95 ko os/2 的陈谷子烂芝麻 ---- (以前贴过)貌似多数 ibmer 还是觉得当年 os/2 虽败犹荣... 我觉得那是一个唯技术论最后不顾用户体验的错误经典案例 (后来微软也常有类似的错误)。
          win95 当年 ko OS/2;iphone 1代 2007 年 ko 其他 smart phone; android phone 近一年逐渐占上风都是用户体验胜出的结果。但用户体验这件事儿很微妙 ---- 审时度势很重要。
      • 问题
        NEEDS 和 CONCEPTUAL UNDERSTANDING 是有差距的,永远有。一个是 PRE,就是 IDEA,你个是 POST,由 NEEDS 产生了 SOW,落实到下面,下面的人要回去找 NEEDS。

        在大的 TEAM 里,不容易做到。以为最早的 NEEDS,被翻译了无数层,无数个人,早都变了。小小的 CODER 怎么回去了解/理解 NEEDS 呢?
        • 这个问题比较大。简化点说,这就是为什么(在软件开发领域)大家用 agile (敏捷),一是离客户需求更近,二是减小迭代周期。但是,一则这又会带来其他问题,二则不是所有项目都可以这样做的...
          • 依您之见,什么样的项目适合用敏捷?
            • 这可是个 $1M question, 换别人我肯定不回答...
              敏捷的项目可以用 agile
              Lol....
      • 写的不错,盼之三。关于Unit Test,我觉得不应该太教条,如果你预期需求将会发生变化,就不要做大百分比的覆盖,关键点写UT就可以了。
        • 嗯,很多时候大家就是这样做的。比如什么 abcEngine 之类的关键东西,算法之类的,肯定得有一堆 unit tests 保护着 lol...
    • 不错,不过很多时候程序员所面对的是改造、升级老的代码,而且90%可能性会碰上垃圾代码,根本不可unit test的垃圾代码
      • 说的不错。
      • 这个确实很常见 --- 没办法,你现在也知道那些 code 是哪些人写的了 lol... 痛心疾首的就是这个... 你懂的... 书上说,在改造时,你还是应该用 unit test 先“网住”一部分,然后开始动手(施工时的安全网?不懂那个行当的术语)。理想情况下,以后这部分就好了...
        别问我在现实中是怎么做的 --- 痛心疾首的就是这个...

        你一边在那儿网着,有人一边在另外一头儿给你拆着... 你建安全网的速度没他们快... 他们三个月就学成的... 你懂的...
        不说了...
        • 有没遇到过故意把代码写的晦涩难懂的?我就见过。时间久了,大家会心一笑,job security!哈哈。
    • 你说得不错,不过这市场嘛。。。看看有不少招工广告,希望你十八般武艺样样俱全,工资又极低。不少老板只要能实现功能可以交差(交货),谁管你码感。即使不少本地白人,嘴巴皮子会说,写个垃圾code,反正PM也不懂,能应付客户就充大牛。
      兵哥那篇文章对开始混个工作的国人还是有用的。入行后,各人的造化就看你这篇了。
      • SHORT TERM 和 LONG TERM 的纠结。
        SHORT TERM,就是强化训练,找到单位儿,进了门再说。速成,时间端,针对性强。

        LONG TERM,细工慢活,逐步修炼。时间长,涉及广泛,但是走得稳,走得远。

        老生常谈了。
      • 想了想,不知道怎么接这个帖子,还能同时维持住“政治上的正确性”... 所以,呵呵... lol...
        • 我只是觉得你俩的观点是针对不同人群人,不同层次的码工的。那些cheap的老板,那些二百五的PM是不会在意的,那怕他们常常把可维护性可扩展性等等挂在嘴边。试想一下,你把framework, design pattern, DTO这些都做得很好,PM一句话所有逻辑都放在SP里。
          结果你的那些都成了摆设,更别谈什么对business logic的unit test了。对这些老板,PM,码感都是浮云了。现在太多的PM自己不会写code,很有些外行领导内行的意思。他们让你把客户需求划成一小块一小块的,问你每一小块要几小时,列个清单,向客户收钱,然后拿着清单看你进度打勾勾。最后美其名曰scrum。遇到这种 PM, 你如何与他们谈码感?

          作为专业工作而言,其它各行各业都有自已的规范,有自己的专业行会。唯独 IT没有,所以只要你嘴巴皮子利害,你就能当大爷。很难想像一个非PE的人可以当一帮PE的经理去指挥他们howto design,去问他们一根梁一根柱一个变电器要算多长时间。但现在这在IT行业里是常态。lT人和非lT的经理谈码感就好像PE和非PE的经理谈规范一样,人家经理不理你。人家经理只在乎以最少的时间完成客户的要求,把钱拿回来,这时agile往往就成了这些PM最好的工具。
          • 维生和热爱,是两回事。鉴于 PE 的事,举两个身边的例子。
            FDOT:Stephanie Kopelousos 这女人在位 4 年,估计干得不错。DOT 里面能人很多,FDOT 是个很不错的单位儿。

            http://en.wikipedia.org/wiki/Stephanie_Kopelousos

            SFWMD:Carol Wehle 这女人好像就一个 MIT 的 BS 毕业,不记得是不是 PE。

            • 她是civil engineer出身。哪怕和水不是一个专业,但PE的训练是一致的。而且无论设计还是施工,水是有规范可依的,她是不可能插手设计施工的。更何况这种例子在PE里是少见的,但在lT里是常态。
          • lol 也是,碰上那样的 PM,我撤,内谁,您上 ~~~ lmao...
            • 这种人不少,非IT的人当PM的更多。只能说这是市场的现实。
          • 深有同感。
    • 唱个反调。
      我同你一样,喜欢将码写的简明易懂。而且能 cover 尽可能多Exceptions。

      结果是在原公司很不被头当回事 - 程序不大出错,不需要大的维护。反倒是有人CODE一团乱,常调链子被头当回事。

      到新公司更开眼。一系统被有意搞的极复杂,弯弯绕的少有人能搞懂。

      有位老兄高薪康揣多年 - 他的系统別人搞不定。国人缺这本事。
      • 只维护旧系统完全没有新项目的地方,不去也罢。如果有了新需求(无论是扩展现有功能还是新项目),和那些人相比,你能不能数倍于他们的 productivity 就看厚积薄发的能力了。
        不光是 coding 的能力,而是多方面,比如了解业务需求,项目规划,领导团队,沟通协作...
        如果你用更短的时间,带领团队做出更好的项目,而且同样重要的是,能让老板了解到你的团队对公司的贡献,并感觉能依赖你和你的团队,老板还会一直把掉链子的人当回事儿么?
        如果是,那就换一家公司好了。
        就那么简单。
    • 说个笑话摸当真,码感太高同时会提高你nerd屌丝气息,直接结果就是找不到女朋友(好吧,最多只能找到理工科的呆头眼睛女)。
      当年本科毕业做屌丝程序员时,code除非是接口那块大家要共享的,其他的我能写的多猥琐难懂就要多猥琐难懂,能用循环的我一定要用递归,能用二叉树的我tmd一定上红白树,class里基本都private了,public变量想都别想,如果能提供编译库我是肯定不会给源码的,继承是不要想的了。当然仅限于老板不会看的那部分(否则会被骂死的)。

      为什么这么做?万一那天准备炒我鱿鱼了那么他们得掂量掂量是不是上手的能接着无缝接上而慎重考虑炒我鱿鱼的代价。。。。我邪恶的笑了。
      • 哈哈!你应该改行做standup comedian!
        • 嘻嘻
      • 高人啊,您这哪是猥琐啊,简直就是高手中的高手
        能用循环的我一定要用递归 ----- no side effect! thread-safety!
        能用二叉树的我tmd一定上红白树,----- guaranteed O(log(n)) worst case performance!!
        class里基本都private了,public变量想都别想,----encapsulation and immutability!!!
        如果能提供编译库我是肯定不会给源码的,继承是不要想的了---- Composition over inheritance

        你这程序这样写,能有错才怪。全部都是高手范儿,都是best practices 啊!!! 说,你老板给多少钱你了,这么卖命?
        • 程序员在妹子眼中永远是猥琐男。。。。
    • 嘻嘻!
    • resharper俺用了几天删掉了,把VS搞得很慢