百度飞桨学习——七日打卡作业(二)选手信息爬取
638
2022-05-30
目录
一、写在前面
二、注重实效
1. 负责
2.破窗/图景/质量
3.管理你的知识资产
4.交流
5.不要重复自己/正交性/可撤销性
6.快速实现(曳光弹)/原型/估算
7.领域语言
三、小结
一、写在前面
首先,这是我在2022年写的第一篇博客,我把他献给读书。
套用最近比较流行的一句话『读书破万卷』,可见书籍的力量还是足够强大。
这本《程序员修炼之道—从小工到专家》是一本修炼内功的书,常读常新。
我通过文字记录和分享个人对于这本书的理解,希望能够持续成长。
二、注重实效
本书的前两章都在聊"注重实效",分别是哲学和途径,即分别对应了理论和实践。
1. 负责
本节标题为《我的源码让猫吃了》,引出了开发者在项目中对于责任的认定和要求。
为结果负责,就要承担起责任
犯错就要承认
要提供选择,而不是找借口
这和我们的认知中"不要只提出问题,而是要给出解决方案"的理念是一致的,强调了负责的重要性。
2.破窗/图景/质量
我把这三点放在一起,他们都是为了维护软件质量做出的努力。
不要去一点一点降低编码质量,这样会让你的团队成员效仿,这会导致项目的质量越来越差。(破窗效应)
通过对大图景的描述,能提升士气,并达到最终希望的结果。
质量要成为需求的一部分,也要适可而止。
3.管理你的知识资产
知识资产就是你的全部知识和经验,需要经营,包括
定期投资
多元化
管理风险
低买高卖
重新评价和平衡
为了达成目标,建议有
每年至少学习一种新语言
每季度阅读一本技术书籍
也要阅读非技术书籍
上课
参加本地用户组织
实验不同的环境
跟上潮流
上网
还有批判的思考,你看到的读到的和听到的,不一定是真实的,很可能是商业推给你的。
4.交流
作为一个开发者,交流是需要并且必须的,本节给出了需要注意的点
知道你想要说什么
了解你的听众
选择时机
选择风格
让文档美观
让听众参与
做倾听者
回复他人
5.不要重复自己/正交性/可撤销性
第二章的重点在于途径,也就是方法论。前三节的目的在教会我们如何让自己的代码更好。
DRY原则,为的是更简洁的代码。
产生重复的原因分为这几种,分别需要采取不同的应对策略。
强加的重复。使用代码生成器。
无意的重复。设计不规范。
无耐性的重复。预先优化。
开发者之间的重复。互利互惠。
正交性,对应到计算机领域是解耦,即不相互依赖。一个没有做到解耦的系统是很难后期维护的。
可撤销性则对应的是灵活的架构,在一个软件的开发周期中,合同的供应商可能发生重大变化,我们的架构需要支持这种不确定性。
6.快速实现(曳光弹)/原型/估算
书中的曳光弹没有直接白话的解释,我的理解是快速实现,并且跳过原型设计环节。
可能是为了防止读者过于信任曳光弹模式,紧接着后面一节讲的就是原型和便签。但是这里的原型和产品经理给的原型的定义是不同的,这里指的是能被看懂业务的Demo。先做起来检查业务对不对,而不是像上一节那样先做完再去调整细节。
不管采用什么样的开发模式,我们都会在项目进行中估算进度。本书给出的思路也基本和项目管理中的工作分解结构估算工期的流程一致。
7.领域语言
领域语言解决的问题是项目的业务来决定使用什么样的编程语言。
我用一个现代化一些的例子来说,就是我要在本地批量处理文件并生成报表,那首选当然是Python,而不是Java。
三、小结
正确地认识开发者自己和项目流程,在这之间需要认知的细节,就是前两章的内容。
专家 开发者
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。