• 不是

  • JavaScript

  • 求推荐机械键盘 at 2017年3月15日

    来个链接吧: https://www.zhihu.com/question/23105050/answer/23706016

    蛮值得参考

  • 常见重构手法 (上) at 2017年1月20日

    其实我现在越来越倾向于认为,写代码的问题只能在招聘这一关解决。

    知道吸烟喝酒对身体不好还要吸的大有人在。知道要早睡早起、坚持锻炼身体才能好但还总是熬夜、几乎不怎么运动的更是数不胜数。人们总是抱着侥幸的心理,却没有意识到不好的东西一直在以你很难注意到的程度积累,只是还没爆发。在遇到什么重大变故之前,期望他人改变根深蒂固的习惯和观念几乎只能得到绝望。而软件开发这份工作,似乎代码再怎么乱也不会引起多大变故,对那些早就习惯了在泥潭里打滚的人来,最坏的情况也就是丢掉一份工作罢了。

    不停的提醒别人早点睡觉、坚持锻炼是很让人烦的,对别人的代码指指点点人家会觉得你吹毛求疵。对于非家人的身体健康,我们当然可以完全不管不顾,但现在开发软件总是需要“团队”来“合作”完成。

    我无意与任何人争论,只想求一个解。

  • 常见重构手法 (上) at 2017年1月20日

    #21楼 @u1440247613 这样说,写代码还得先精通算命,写之前给这个项目算一卦。

  • 常见重构手法 (上) at 2016年12月21日

    #3楼 @qinfanpeng 这个我觉得不一定吧。改遗留代码好像更多时候仅仅只是让人觉得难改,但是对认识到自己平时开发中的各种坏习惯并没有帮助。而且多数程序员好像总会有各种办法在原来的基础上打补丁的。就更别说从中总结出好的写法了。情况好像往往是程序员一边难过地写代码,一边还认为自己的各种想法和做法始终是对的。你要说一个方法的参数超过 2 个很多时候是个 bad smell, 多数人只会笑话你,然后继续写出自以为正确的代码,然后继续痛苦。

    像《重构》这样的书,很多人好像也就是看看而已,用他们的话说:“实际项目是很复杂的”。

  • 常见重构手法 (上) at 2016年12月21日

    感觉比起重构手法,价值观来得重要一些:什么样的代码是好的,什么样的代码是不好的。或者说有这些价值观是对代码进行重构的动力。请问大家是怎么对团队成员进行价值观洗脑的?对这个问题我一直比较苦恼。

  • 先粘贴两个链接,不知道 lz 是不是需要:

    领域模型的价值与困境

    再论领域模型的困境


    然后说点题外话。实际上我觉得写代码就是 3 件事:实现功能,去除重复,最后使表达清晰——主要是命名。

    但是在完成后面两个目标的时候,特别是是“去除重复”这个目标的时候,我们会不断的遇到困难。这时候就不得不动用你所在的那个世界(那门语言)所能提供的所有方法资源:封装、组合、继承、mixin、元编程等等。

    极端地去除重复必然导致模块粒度细化,各种最细粒度的模块互相结合又成为更粗粒度一些的模块,最后软件成为各种不同粒度(不同抽象级别)组合而成的一个组合体。它的内部因为没有重复而条理清晰。似乎很多写不干净代码的人会嘲笑这种情况只是个梦。

    所以,我觉得没有必要去纠结太多概念,也没有必要迷信各种框架的写法。有了原则,什么都好办,没有太多固定的模式。

    其实以我自己的一点经验,多写写脱离现有框架的东西。比如公司项目里看似比较边缘的,跟整体框架关系不是很紧密的,又没有现成框架可用的东西。把那些东西写干净的话,对自己的提升其实比在一个框架(比如 Rails)里写代码来得大得多。

    希望以上这些能有点帮助。

  • 新功能上线:公司/组织 at 2016年10月24日

    有离职的功能么?

  • 其实 OrderReview 跟 ProductReview 不是一个东西。

如何写代码才本应该是程序员多多讨论的事情。这个圈子最不缺的就是不懂装懂的扯淡。同时这些人也习惯性地以己推人,把所有自己无法理解的东西当作是别人在扯淡。稍微深入点的正经讨论和扯淡都无法让他们理解,所以这二者在他们看来是一样的:都是扯淡。所以正经讨论中经常夹杂着这些以为你在扯淡的人跟你扯淡。