• 郭解 置顶
    2019-01-04
    多些实例

    编辑回复: 您好,第一篇只是引子,后续内容会有很多正反面案例,请期待。😊

    
     13
  • Imperfect
    2019-01-05
    有一句很经典的名言:当我写这行代码的时候,只有我和上帝知道这行代码的意思。一年之后....现在,就只有上帝知道了。

    作者回复: 上帝很孤独……

     1
     31
  • W.J.Huang
    2019-01-05
    个人认为,条件运算符适合简单的结果取舍,带有复杂的表达式或嵌套运算符的应该用if语句。
    另外,代码规范和语句检查,可以使用SonarQube. SonarQube不仅带来代码评审的便利,还可以直接安装在IDE, 比如Eclipse, 会时刻提醒不规范或不安全的代码,以提高开发人员提交代码质量。

    作者回复: 👍,小伙伴们快来试试这个工具。 高手都在讨论区😊。

    
     18
  • 月城冥
    2019-03-08
    请教一个具体的问题:java lambda该用还是不该用?个人感觉这个东西的可读性还是有点差的。什么样的场景该用,什么样的场景不该用?

    作者回复: lambda的可读性,主要是和我们通常的编码习惯不太一样。lambda在异步编程和函数编程方面,还是有可读性优势的。

    我不是lambda的铁杆粉丝,主要是因为我做的工作大部分是非常基础的接口。lambda方式会产生大量的内部类和实例,这个有损效率。这个效率损耗如果发生在应用层,影响不大,可以忽略不计。可是要发生在使用频繁的底层接口,就是个不小的问题了。

    
     5
  • 秦凯
    2019-01-06
    老师从软件生命周期来看代码好坏的角度让我对代码质量有了新的认识,好的代码应该是服务于整个软件生命周期的,或者说是服务于软件开发目标的,不能说代码中用了某个高深的技巧或技术就是好代码,应该跳出开发视角,从整个软件的目标思考,能服务于软件目标,适合软件目标的,对于整个软件生命周期都是经济的才是好的代码。

    作者回复: 总结的特别棒、特别好👍。

    要有意识地从最基础的概念开始理解一些问题,这就是我想通过这个专栏让你收获的东西之一。

    
     5
  • Change
    2019-01-04
    以前觉得看不懂的代码就是厉害的有种不明觉厉的意思,看完老师的文章才觉得化繁为简通俗易懂的代码才是我们追求的好代码,其编写的过程是由简单到复杂,再由复杂到简单的一个转变。自己对安全这块也比较重视,期待老师的后续内容。

    作者回复: 我们第三篇聊安全。 如果哪一天,你觉得复杂很简单,告诉我一下,我要恭喜你。

    
     5
  • Woj
    2019-01-04
    好的代码是代码运行正常、bug很少、并且具有可读性和可维护性。一些企业自己有所有开发人员都必需遵守的编码规范,但是对于什么样的代码是最好的每个人的都有自己的标准、或者有太多的或太少的编码规则。这有多种原则和标准,例如,McCable 的复杂度度量。的确使用过多的编码标准和规则可能降低生产率和创造性。“同行评审”或“同事检查”代码分析工具等,都能用来检查问题或坚持标准。

    作者回复: 标准多就像没标准。

    
     3
  • 陈大发
    2019-01-07
    我觉得首先的是要职责单一,不要把过多的东西塞到一个类或者方法中,同一个功能的最好放到一起,或者有联系的地方。尽量把变化的抽离出来,不变的封装起来。

    作者回复: 赞,能坚守职责单一,就成功了一半。 我们后面的文章还有专门的讨论。

    
     2
  • alan
    2019-01-04
    谢谢老师,坚定了我认为代码是给人看的这个观念。

    作者回复: 给人看,也给以后的自己看。

    
     2
  • yaya
    2019-01-04
    一直觉得条件运算符复杂但是看起来漂亮,以后就安心用if语句了,命名这个问题是一个困扰我蛮久的问题,我英语水平就中等水平吧,可以读懂,看懂,但是自己写或者说就一般般,怎么好的来对一个函数命名呢,有什么比较好的规则吗?

    作者回复: 后面我们会专门讨论命名的。

    
     2
  • 虢國技醬
    2019-01-04
    打卡:
    经济--这个词概括好,好的代码并不是绝对的,而是相对的;相对于所处的环境、所服务的规模,根据环境、规模、目标来适配代码做的经济性更好才是最适合的

    作者回复: 相对的,你总结用的这个词也很妙。

    
     2
  • 南宁码王
    2019-01-04
    代码范例太少啦

    作者回复: 嗯,😊代码马上就来

    
     2
  • 路过蜻蜓
    2019-01-11
    我写代码时一般是先顺着写下来,然后再对需要重复使用的代码分离出去,写成一个方法,尽量将写在一个def里的代码简单点。

    作者回复: 代码整理术!

    
     1
  • 王小呱
    2019-01-05
    以前看到别人写简洁的代码时,追求简洁时,哇塞,好牛逼!现在明白了,那是傻逼。

    0 和 1 最简单了,但是组合在一起后却没什么人看的懂!

    最好有些练习、案例之类的

    作者回复: 我们先把概念交代好,练手题随后就到。

    
     1
  • vector
    2019-01-05
    我同意老师的观点,尽量用if,我有时候用if也会把条件写反,这个跟与语法无关,需要的是我们的细心。
    我有另外一个疑惑:有时候为了减少缩进,我会先用 if (obj != null) 判断,正常的逻辑就不用嵌套在括号里边了,少了一层缩进,自我感觉良好;但是又会看到很多代码又不是这样写的,其实从阅读和理解的角度来看,确实这样比较好,满足条件执行,不满足怎么怎么样。我想知道老师怎么看?

    作者回复: 对于文章中的我的那个错误代码,我更在意的是为什么我们的评审、测试环节对这个问题失效了。一般对于这种机制失效,我警惕性要高一些。

    如果空值是一个异常情况,先判断是一个好习惯,逻辑清晰就行。 换个角度想,就是不满足什么条件,就不继续执行了,要抛出异常,或者返回。

    编码规范并不统一,所以会有不同的偏好。找到一个大家必须遵守的有共识的集合。没有规范的部分,要依靠自己对基本原则的理解,结合上下文代码的具体状况,有点个人偏好。

    
     1
  • So Leung
    2019-01-04
    好的代码是"经济的代码",需要衡量编写时间和运行的空间,根据不同的情况综合考虑,在这之外的最重要的是安全!!!!安全是重中之重.

    作者回复: 赞这个总结!

    
     1
  • 右耳朵猫咪
    2019-01-04
    如何能做到代码写的又快可维护性又高呢?

    作者回复: 这就是这个专栏的目标啊,我们慢慢来。

    
     1
  • cocoa
    2019-01-04
    抛开业务逻辑逻辑不说,现在很多IDE都有基本的代码规范插件,比如Java还可使用阿里巴巴规范的插件,如果把这些问题都清理一下的话,质量会有一个基本的保证,也比较经济,不用投入人力去找错误。另外畅想一下,现在机器学习这么流行,可否给自己的业务代码指纹画像,让机器提取优秀业务代码的特征,做出提示。总之要经济还是想办法用机器来解决。

    作者回复: 哦,阿里巴巴已经出插件了?机器能干的事,就让它来做。

    
     1
  • 阿J
    2019-01-04
    写评论也写出bug了,看来真的要好好磨练😂

    作者回复: 😊哪有不出bug的人啊

    
     1
  • 阿J
    2019-01-04
    有时候觉得编码过程眼高手低,有时候觉得手高眼低。最终发现缺乏的原来是缺乏了反复的琢磨的过程。谢谢老师的第一课,会持续跟进学习。

    作者回复: 🤝,我们一起来琢磨

    
     1
我们在线,来聊聊吧