SegmentFault 代码之外最新的文章
2019-12-28T10:51:40+08:00
https://segmentfault.com/feeds/blogs
https://creativecommons.org/licenses/by-nc-nd/4.0/
我的2019读书小结
https://segmentfault.com/a/1190000021427249
2019-12-28T10:51:40+08:00
2019-12-28T10:51:40+08:00
何一涛
https://segmentfault.com/u/heyitao
0
<p>今年读了86本书,写了30篇笔记。技术相关的书只读了 10 本,占比 12%。</p>
<p>从今年阅读的书中挑选出7本技术相关的书作简要介绍,供参考。</p>
<ol>
<li>《编写可读代码的艺术》。以提升代码可读性为主题的一本简洁的书,强烈推荐。可配合《重构》和《代码整洁之道》阅读。</li>
<li>《架构整洁之道》。架构入门必备,马丁大叔清晰地讲述了编程范式、设计模式、组件构建原则、简洁架构和实现细节等主题。</li>
<li>《软件随想录》。Stack Overflow 创始人的博客文集,主题关于软件技术、人才、创业和企业管理,观点新颖,翻译得很好。</li>
<li>《冒号课堂:编程范式与OOP思想》。书中主流编程范式讲解得很到位,理清了语言、编程范式、架构、设计模式等常见概念,适合有一定编程基础的工程师阅读。</li>
<li>《函数式编程思维》。程序员进阶的好书。讲述如何通过函数式语言解决各种问题,适合函数式编程入门。</li>
<li>《Java 8函数式编程》。讲述Java 8中的 Lambada 表达式和流的使用,以及它们对并行、测试和设计原则和并发的影响。</li>
<li>《软件框架设计的艺术》。教你怎么设计 API,开发 SDK 的程序员可以看看。书中隐喻较多,翻译一般,举的例子也多与 Netbean 相关,但不失为一本好书。</li>
</ol>
<p>读书方法论方面收获了一些体会:</p>
<ol>
<li>读书的形式。优先电子书,可随时阅读,记笔记方便。不值得再读的纸质书记好笔记后卖掉或送掉,以免浪费空间。把时间花在看书上而不是屯书屯券。</li>
<li>什么时候读。多利用碎片时间,地铁上,排队时,无聊时。利用集中的时间,下班回家后读一个小时,周末集中一个时间段一气呵成。</li>
<li>读什么书。豆瓣7分以上,多学科入门书,短小精悍的书,知乎推荐书单,各种读书会和大佬列的书单,做交叉比对筛选列入自己的读书池。</li>
<li>怎么读。看目录和前言,选择感兴趣的重点读,不感兴趣的略读,读时记录所思所想后面汇总。</li>
<li>输出为导向。记笔记,画思维导图,写书评,用自己的话把书中内容讲给别人听,制作ppt分享,立即去实践。</li>
<li>改变了什么。视野拓宽了,焦虑减少了。</li>
<li>深刻影响自己的书可能就三五本,但找到那三五本可能要阅读个三五百本。</li>
</ol>
<p>非技术类的书也挑选出了10本,供参考。</p>
<ol>
<li>《人类群星闪耀时》。比小说还精彩的10个历史瞬间,酣畅淋漓,一个字爽。</li>
<li>《反脆弱》。《黑天鹅》的升级版,教你如何从不确定性中获益。</li>
<li>《现实不似你所见》。量子物理科普大作,了解世界是由什么组成的,时空是否真的存在。</li>
<li>《约翰·克利斯朵夫》。史诗一般的恢弘人生,找到个人成长中的共鸣。</li>
<li>《鞋狗》。耐克上市前的创业史,很精彩。可搭配村上春树的《当我谈跑步时我谈些什么》,从中找到跑步的意义。</li>
<li>《树上的男爵》。很有想象力的小说。生活在树上,始终热爱大地。</li>
<li>《激荡十年,水大鱼大》。2008-2018国内企业经济史,通俗易懂,近距离回顾你失去的赚钱机会。</li>
<li>《精要主义》。生之智慧,在于摒弃不必要之事。</li>
<li>《佛教常识答问》。佛教协会会长普及佛教常识。可搭配《悉达多》一起看。</li>
<li>《我的应许之地》。以色列版文化苦旅,一窥以色列建国史,了解巴勒斯坦冲突的背后。</li>
</ol>
<p>更多的阅读清单可参考<a href="https://link.segmentfault.com/?enc=aIHvdbWe%2B5Vxg4XhCVL1ow%3D%3D.r7V1Dgcyahytv2k%2Bt876LcuX70Yib0cpPp4%2BVrNvfojc9tMJlHRzDaQGMILto0%2FW" rel="nofollow">我在豆瓣上标记的2019阅读清单</a>。</p>
如何编写可读性高的代码
https://segmentfault.com/a/1190000020038851
2019-08-11T23:27:23+08:00
2019-08-11T23:27:23+08:00
何一涛
https://segmentfault.com/u/heyitao
0
<p>写代码不要只顾自己爽,也要兼顾代码的可读性。程序员之间的相互尊重体现在他们所写的代码中,他们对工作和职业的尊重也体现在代码上。</p>
<p>代码即架构。代码写的烂,不注重可读性,队友看了会问候你,估计也没人愿意接手你的烂摊子,隔一段时间后再看你也会骂娘。</p>
<p>从成本角度看,软件成本由开发成本和维护成本组成,而往往维护成本要远高于开发成本,这其中耗费的主要成本就是由于理解代码和修改代码造成的。</p>
<p><a href="https://link.segmentfault.com/?enc=fa9lcxOzJakMtS1A77eRxA%3D%3D.uFaRwkthQwHPwAu34QHMjUMmNtYtw8YiHkpu0qRWaHDOvxHeCa9yZ0xMrMr3qldj" rel="nofollow">《编写可读代码的艺术》</a>这本书主题是让代码变得更容易理解,确切的说,使别人用最短的时间理解你的代码。</p>
<p>对代码有追求的工程师都应该翻翻这本书。</p>
<h2>摘录</h2>
<h3>一、表面层次的改进</h3>
<ol>
<li>
<p>把信息装到名字里。一个变量名就像是一个小小的注释,读者只通过名字就可以获得大量信息</p>
<ul>
<li>选择专业的单词。比如 get 不如 fetch 具体(由上下文决定)</li>
<li>避免空泛的名字。比如 temp 和 i,除非有特殊的理由</li>
<li>使用具体的名字代替抽象的名字</li>
<li>给变量名带上重要的细节。比如在值为秒的变量后加上 second</li>
<li>为作用域大的名字采用更长的名字。在小的作用域可以使用短名字,不要使用项目特有的缩写</li>
<li>利用名字的格式来传递含义。比如有目的地使用大小写、下划线等区分变量,视团队规范而定</li>
</ul>
</li>
<li>
<p>不会误解的名字是最好的名字。多审视名字是否会造成误解</p>
<ul>
<li>很多英语单词在用来编程时是多义的,例如 filter、length、limit</li>
<li>当要定义一个值的上限和下限时,max 和 min 是很好的前缀</li>
<li>对于包含的范围,first 和 last 是好的选择</li>
<li>对于包含或排除范围,begin 和 end 很常用</li>
<li>为布尔值命名时,使用 is 或 has 这样的词来明确表示它是个布尔值,避免使用反义的词(例如 disable_ssl)</li>
<li>要小心读者对特定词的期望。例如,读者会期望 get 或 size 是轻量的方法</li>
</ul>
</li>
<li>
<p>整洁的代码格式</p>
<ul>
<li>使用一致的风格</li>
<li>把代码按列对齐可以让代码更容易浏览</li>
<li>选择一个有意义的顺序,并始终用这样的顺序。比如按字母顺序</li>
<li>用空行把大块代码分成逻辑上的段落</li>
<li>与团队保持一致的风格比“正确”的风格更重要</li>
</ul>
</li>
<li>
<p>该写什么样的注释。注释的目的是尽量帮助读者了解得和作者一样多</p>
<ul>
<li>
<p>什么时候不需要写注释。阅读注释会占用阅读真实代码的时间,注释也会占用屏幕上的空间,所以不要写没价值的注释</p>
<ul>
<li>能从代码本身迅速推断的事实</li>
<li>不要给不好的名字加注释,而是应该把名字改好。好名字比好注释更重要</li>
</ul>
</li>
<li>
<p>用代码记录你的想法</p>
<ul>
<li>为什么代码要写成这样而不是那样的内在理由</li>
<li>代码中的缺陷,使用类似 TODO 这样的标记</li>
<li>常量为什么要用这个值</li>
</ul>
</li>
<li>
<p>站在读者角度,去想象他们需要知道什么</p>
<ul>
<li>为普通读者意料之外的行为加上注释</li>
<li>在文件或类级别上使用“全局观”注释来解释所有部分是如何一起工作的</li>
<li>用注释来总结代码块,使读者不致迷失在细节中</li>
</ul>
</li>
</ul>
</li>
<li>
<p>写出言简意赅的注释。注释应当精确而紧凑</p>
<ul>
<li>避免使用 it 和 this 这种可能指代多个事物的词</li>
<li>尽量精确描述函数的行为</li>
<li>在注释中用精心挑选的输入输出例子进行说明</li>
<li>声明代码的高层次意图,而非明显的细节</li>
<li>用嵌入的注释来解释难以理解的函数参数</li>
<li>用含义丰富的词来使注释简洁</li>
</ul>
</li>
</ol>
<h3>二、简化循环与逻辑</h3>
<ol>
<li>
<p>把控制流变得易读。越自然越好</p>
<ul>
<li>写比较语句时,改变的值写在左边,更稳定的值写在右边</li>
<li>重新排列条件判断语句中的语句块,优先处理正确的、简单的和有趣的情况</li>
<li>避免使用复杂的三目运算符、do while循环和 goto 这种会让代码可读性变差的编程结构</li>
<li>避免深嵌套的代码。应该改成更加线性的代码</li>
<li>使用保护语句提早返回可以减少嵌套</li>
</ul>
</li>
<li>
<p>拆分超长的表达式。大多数人只能同时考虑 3-4 件事情</p>
<ul>
<li>引入解释变量</li>
<li>使用德摩根定理优化逻辑表达式</li>
</ul>
</li>
<li>
<p>变量和可读性</p>
<ul>
<li>减少变量。尤其是不能改进可读性的临时变量</li>
<li>缩小变量的作用域。尽量避免全局变量</li>
<li>只写一次的变量更好。final类型、常量使得代码更容易理解。操作一个变量的地方越多,越难确定它的当前值</li>
</ul>
</li>
</ol>
<h3>三、重新组织你的代码</h3>
<ol>
<li>主动抽取不相关的子问题。把一般代码和项目专有的代码分开。这样可以使你关注小而定义良好的问题</li>
<li>一次只做一件事。尝试把难读的代码的所有任务列出来,部分任务可拆成单独的函数或类,或者成为函数中的逻辑段落</li>
<li>采用橡皮鸭调试法,把想法变成代码。用自然语言描述程序然后用这个描述来帮助写出更自然的代码</li>
<li>
<p>少写代码。代码需要开发、测试、写文档和维护,代码越多,债务越多,维护越麻烦</p>
<ul>
<li>从项目中清除不必要功能,不要过度设计</li>
<li>重新考虑需求,解决当前版本最简单的问题,只要能完成工作即可</li>
<li>经常性通读标准库的 API ,保持对它们的熟悉程度,多重用它们</li>
</ul>
</li>
</ol>
<h3>四、可读代码与测试</h3>
<ol>
<li>最好每个测试的输入和输出可以用一行代码来描述</li>
<li>如果测试失败了,它所发出的错误信息能让你容易跟踪并修复这个问题</li>
<li>使用最简单的并且能够完整运用代码的测试输入</li>
<li>给测试函数取一个有完整描述性的文字,以使每个测试所测到东西很明确</li>
<li>要易于改动和增加新的测试</li>
<li>不要对测试关注过度,它应该是项目的一个方面而不是主导。比如不要追求 100% 的测试覆盖率</li>
</ol>