简约之美 & 编写可读代码的艺术
最近陆续收到一些donation, 非常感谢哈, blog的文章说多不多说少不少, 大部分是笔记性质的, 主要目的还是积累以及方便自己查询回顾, 分享出来, 希望有所帮助:)
ps: 昨天将国内ip切到gitcafe了, 加载速度应该快了很多, 在此特别感谢下gitcafe. (关于如何国内国外切分访问, google大法)
今天要提的是«简约之美—软件设计之道>> 以及 «编写可读代码的艺术>>, 主要原因是, 经典, 更重要的是, 足够薄:), 建议买了珍藏, 也是属于那种不同时期反复读会有不同感受的书
———————————
简约之美
这本书, 用一百页来说明, 软件开发设计中, 一些十分简单的道理.
好的程序员和差的程序员的区别在于理解能力. 差劲的程序员不理解自己做的事情, 优秀的程序员则相反.
理解能力, 看起来蛮虚的一个词, 但是在工作中真正进行沟通时, 你会发现区别非常大, 决定了是一次沟通 还是 反复沟通; 是直达目标, 还是不断曲折; 是一次搞定, 还是改改改; 是反馈有效问题, 还是反馈不是你的问题的问题空耗你的时间. 所以花费时间去理解需求, 想明白之后再开始写代码, 这个很重要! (真正团队干活你会有直观感受的)
问题的根源通常在于编程……这一切都与复杂性有关……编程就成了把复杂问题化解为简单问题的劳动……”好程序员”应当竭尽全力, 把程序写得让其他程序员容易理解.
bug的本质, 归根结底在于编程本身.
我们往往容易把问题复杂化(大而全, 追求完美, 过早优化, 过早关注细节), 而过度复杂的后果导致后期代码的难以维护.(所谓的到时候再改/重构, 都是虚妄的), 程序员遇到一坨代码(别人写的或者之前写的), 有优化的冲动, 但是迫于需求或者时间或者系统稳定性, 往往惧怕变化, 这段代码能工作就行.
但是为什么要复杂化呢? 最简单的, 莫过于在最初就做到最好, 不要给自己到时候再重构的念头. 写好每行代码.
这里的其他程序员, 也可能是一个月后的自己. 如果经常发现回头看自己的代码都看不懂, 那么说明进步的余地还是很大的:).
到这里, 我们的目标转向: 寻找提高代码质量的科学方法.
每个写代码的人都是设计师
小到一个变量名, 一个判断逻辑, 大到一个函数, 一个类, 一个算法, 从代码里可以感受到很多东西. 拿建筑设计师对比, 写代码, 如同构筑一栋建筑, 不管是小屋/公寓还是摩天大厦, 好的设计永远美好, 而糟糕的设计, 无论大小, 永远丑陋. 很多概念, 意识和技巧在里面.(建议阅读编写可读代码的艺术, 然后是代码大全)
全部软件都有一个相同的目标: 帮助其他人……不能理解
帮助其他人的程序员, 只能写出糟糕的程序, 也就是说, 他们的程序提供不了什么帮助……在做与软件有关的决策时, 指导法则就是判断能够提供什么样的帮助
同样, 这里的其他人, 可能是你自己.
需求的优先级, 取决于这个需求对于用户帮助的大小.
你这样做/这个功能/这么处理, 对于目标, 对于团队, 对于个人, 有何帮助? 如果没有, 为什么要这么做?
软件设计科学的目标: 1.确保软件能够提供尽可能多的帮助. 2.确保软件能够持续提供尽可能多的帮助 3.设计程序员能尽可能简单地开发和维护的软件系统. 才能实现1/2
1代表软件本身的价值, 2代表软件的可维护性可扩展性, 3代表, 好的/简单的设计, 决定了可维护性和可扩展性, 是万丈高楼的地基. 不过1和3, 在有限资源的情况下(资源永远是不够的), 是互相冲突的, 所以要思考如何保持平衡.
这里提到, 软件的开发和维护都应当简单, 要避免困难和复杂.
软件设计方程式 可取程度=价值/成本 => 可行性=(当前价值+未来价值)/(实现成本+维护成本)
当前价值和实现成本往往是可评估的, 人们会关注于这一点, 带来的问题就是忽略了未来价值和维护成本, 这两个和时间相关, 不易评估, 但是却更为重要. 人很容易只着眼于现在而忽略了未来. 所以写代码时需要注意, 存在着未来.
相比降低实现成本, 降低维护成本更为重要. 很直观的感觉, 一个设计良好的接口, 在需求变更的时候, 只需要动个参数或者动几行代码或者压根不需要改. 而一个糟糕的设计里, 每次需求变更, 会发现需要改动很多代码, 甚至是重写, 连带测试等时间, 你会发现很多时间耗费在里面. 所以应该一开始就理解, 往未来看一眼(预测短期未来是可行的, 预测长期未来是不靠谱的), 再进行设计, 再进行代码.
变化定律: 程序存在的时间越久, 它的某个部分需要变化的可能性就越高.
一切都是变化的, 你自己, 还有这个世界.
所以需求变更是必然的:)
之前学到一个很重要的观点: 拥抱变化.
软件设计三大误区: 1.编写不必要的代码 2.代码难以修改 3.过分追求通用
YAGIN, 不要编写不是必须的代码, 并且要删除没有用到的代码. 版本库干嘛用的? 提交, 然后删除那些没用的, 然后再提交:)
僵化设计的原因: 1.对未来做了太多假设(……) 2.不仔细设计就编写代码(新手需注意). 设计程序时, 应当根据你现在确切知道的需求, 而不是你认为未来会出现的需求
避免过度设计: 仅仅根据目前确知的需求来考虑通用.
缺陷概率定律: 在程序中新增缺陷的可能性与代码修改量成正比
好的设计, 代码少(很大可能), 代码变更少, 而糟糕的设计, 反之. 从而, bug出现的概率显而易见
最好的设计, 就是能够适应外界尽可能多的变化. 而软件自身的变化要尽可能少.
不变应万变, 追求之
永远不要
修正任何东西, 除非它真的可能有问题, 而且有证据表明问题确实存在.
例如: “过早优化”!
当问题成为问题的时候, 才是问题, 才需要去处理!
理想情况下, 任何系统里的任何信息, 都应当只存在一次.
避免重复. 变更时代价最小.
简洁定律: 软件任何一部分的维护难度, 反比于该部分的简洁程度.
简洁是相对的.
保持一致/可读性(代码被阅读的次数远远多于编写和修改的次数)/命名/注释(代码的意图通常不应该用注释来说明, 直接阅读代码就应当能够理解)
复杂性是会叠加的, 而不是简单的线性叠加
问题复杂, 解法不一定复杂.
解决复杂性: 把它分解成独立的小部分, 并进行重新设计.
测试法则: 你对软件行为的了解程度, 等于你真正测试它的程度……除非亲自测试过, 否则你不知道软件是否能正常运行.
about test.
编写可读代码的艺术
关于如何编写高质量可读的代码的方法论:)
«The Art of Readable Code>>, 这本书就不细写了, 因为不到两百页, 几乎每一页都是干货.
强烈推荐.
代码大全太厚, «Clean Code>>太晦涩, 建议来读这本. 每次总能得到一些感悟.