程序员修炼之道读书笔记
2020-02-26 15:19:22 4 举报AI智能生成
程序员修炼之道-从小工到专家
作者其他创作
大纲/内容
以书找书，好书推荐
UNIX编程艺术
卓有成效的程序员
代码大全
人月神话
读后感
缺点
书本文字密度较大，读起来比较费神
部分语句较长，导致逻辑复杂，读起来不够顺畅，比较难以阅读
优点
经验总结，值的领悟
高效程序员的特征
对新技术新事物保持敏感，勇于尝试新的挑战
好奇心
批判的思考者，有独立的思维，不要随风飘扬
批判的分析你读到的和听到的
批判的分析你读到的和听到的
有现实感，看清问题的本质，不要浮于表面
多才多艺，不局限与单项技能
关心你的技艺
思考！思考你的工作
如何成为高效程序员
高效的基本准则
负责，对你担负的东西负责，
如有意外尽量提供多的选择，不要找借口
如有意外尽量提供多的选择，不要找借口
不要容忍破窗户
要有大局观，观察周围发生的事情，
避免被煮青蛙
避免被煮青蛙
做变化的催化剂
没有完美的软件，做足够好的软件
让用户参与权衡
让用户参与权衡
定期为你的知识资产投资
持续学习
多元化
交流
知道你想要说什么（列大纲）
了解你的听众
选择时机
选择风格
让文档美观
做倾听者
如果你不听他们说话，
他们也不会听你说话
他们也不会听你说话
回复他人
高效程序开发
高效编码法则
DRY-不要重复自己
重复是万恶之源
重复是万恶之源
正交性
消除无关事务的影响
不要依赖你无法控制的事务
检查每一个可能的错误是一种良好的实践
将异常用于异常的情况
有始有终
无论是谁分配的资源，
它都应该负责解除该资源的分配
它都应该负责解除该资源的分配
如果他不可能发生，用断言确保他不可能发生
提高代码灵活性
使代码间的耦合减至最少
他自身
传入的任何参数
它创建的对象
组件对象
元程序设计
要配置，不要集成
将抽象放进代码，细节放进元数据
时间耦合
用服务进行设计
总是为并发进行设计
MVC 将视图和模型分离
优良习惯
曳光弹，最小功能集合，方向正确后持续集成
原型，方便用于不同角色沟通，减少沟通和开发成本
估算
估算工作时间成本
估算算法速率
早崩溃
重构，早重构，常重构
不要靠巧合编程，深思熟虑的编程
总是意识到在做什么
不要盲目编程
按计划行事
为工作划分优先级
不要被旧代码影响，该重写就重写，该重构就重构
不可依靠运气和偶然的成功
要充分理解你使用的代码，不管是别人的还是自动生成的
提效工具
善于利用纯文本
shell脚本
用好一种编辑器（精通）
总是使用源码控制
这个工具可以助你实现时光倒流
这个工具可以助你实现时光倒流
学习一种文本操作语言
代码生成器
开源工具
自己编写代码生成器
高效代码调试法则
调式思维
调式就是修改问题，而不是发出指责
不管这个问题是谁导致的
不管这个问题是谁导致的
遇到问题不要恐慌，设法找出问题的根源
“那不可能”，这种反应是错误的
“那不可能”，这种反应是错误的
在团队中分享Bug,让其不在出现
调式方法
使数据可视化
跟踪
按步骤向他人解释你的代码
你可能会获得对问题的新洞见
你可能会获得对问题的新洞见
使用二分法缩小问题范围
高效测试
测试思维
要到通过全部测试，编码才算完成
好的项目，测试代码可能比产品代码都要多
早测试、常测试、自动测试
预先的测试可以大大降低维护成本
从局部到全面，尽可能多的测试你的代码
否则你的客户将测试你的代码
否则你的客户将测试你的代码
测试与编码并行
一个bug只抓一次
测试要尽可能100%覆盖程序的状态
测试类型
单元测试
集成测试
验证和校验
资源耗尽、错误以及恢复
性能测试
可用性测试
高效项目管理
需求
不要搜集需求而是挖掘需求
建立需求文档，但不要局限于形式或者表示方法
只要是能与听众有效交流的方法都是好方法
只要是能与听众有效交流的方法都是好方法
好的需求文档要保持抽象，具体的细节可以在需求用例中体现
有利于抽象程序逻辑
开阔全局视野，防止需求蔓延
采用领域词汇
倾听反复出现的疑虑--等你准备好再开始
通过构建原型来决定是否开始
原型构建顺利
项目开始的很多前提条件不满足
不要做形式方法的奴隶
不断从各种方法学中提取精华，改善你的项目建设过程
高效团队
交流
对外部：团队用一个声音说话，文档新鲜、准确、一致
对内部：可进行活跃、热烈的辩论，对工作有很大的热情
围绕功能，清晰的划分团队人员职责
其他（同高效的基本准则）
在项目中尽快能的构建自动化
定时任务
自动化脚本
自动化工具
客户对项目的期望
交流期望
理解期望
管理期望
0 条评论
下一页
