2014 December 08

读构建之法

构建之法读书笔记

一直想着阅读一点相关的软件工程领域的书籍,毕竟一直以来通信专业没有相关知识,为自己的码农之路拓开点路。——话说,转行要补充的知识实在是多到没办法看啊。

最近看到知乎里面提到子路有闻,未之能行,唯恐有(又)闻一次一个道理,听完就去施行,没有掌握之前,不再过多摄入。觉得很有道理,在工作过多的时候很容易选择逃避去不工作或许应该是很多人最可能的选择吧。

####2014-12-8 阅读两章:
第一章:主要概论了软件工程相关领域概念问题,弄清了程序、软件、软件企业相关问题。从软件和工程角度解释了软件工程是什么。提了下软件工程和计算机科学的相关性。

相关词汇:质量保障、软件测试、需求分析、软件设计、软件维护、项目管理
一般工作时,节奏如下:

  • Mentor带领维护软件
  • 更新小Bug,,发布小规模更新版本,练习重构,与同事合作
  • 有机会负责重写某一模块,自行实现
  • 有机会接触较大模块,自己写一些文档,参与模块设计
  • Team骨干,参与项目需求分析

####2014-12-9

第二章:核心是单元测试与开发的同步维护,以及相关回归测试,效能分析问题。

2016-6-13 本次阅读主要做一些章节的主题阅读

第二章节核心借鉴关键在于个人开发流程的借鉴与梳理:版本如何迭代,开发人员接受到开发需求如何开展开发工作,也就是核心——开发人员接到开发任务如何完成的问题;

第三章节:

  • 着眼技术实现,而抽离出具体如何实现,也就是不关心语言等细节实现,而着眼于开发实现
  • 团体中个人的工作质量最终决定了软件的质量
  • re-work 率决定了软件的开发质量
  • 如何提高技能? —— 低层次技能经过训练变成自然反应,中等层次技能一定思考给出答案,高层次问题有所涉猎提升层次;
  • 借魔方的实例提出了什么才是真正的精通,给出了具体的技能层次

第四章节: 两人合作

  • 合作就有效率,如何高效的配合开发工作 —— 合适的开发代码规范,能够互相理解阅读对方的代码
  • 代码复审 —— 非常重要,达成一致性才能通过放行 —— more 更深入的复审问题: 其他模块是否有影响?其他类似的修改?是否可维护?其他人需要知道吗?问题根源是什么?
  • 结对编程的一些说明
  • 合作开发过程中如何正确的反馈问题 —— 针对外层行为当面提出具体反馈以及说明,说明问题时利用三明治式说明方式具体说明问题,褒扬——问题——深化——褒扬

第五章核心主要说明一些团队开发模型:主要是瀑布模型以及迭代模型;

  • 单纯的瀑布模型是单向的,故而上一阶段的问题后续无法更改,我们更应该利用瀑布模型变种,采取瀑布模型结合回溯法,利用相邻步骤的回溯解决上一步骤的问题
  • 大型系统的拆分后的 瀑布群模型
  • 渐进交付模型以及迭代模型

第八章节需求分析:

  • 需求分析尽可能的详尽,在需求分析阶段仔细考虑到出功能性需求,开发需求,服务质量需求,综合需求等等
  • 用户的需求分析上用户需要的与用户表达的有偏差,用户表达的和产品理解的再次偏差,产品传达的需求和开发理解的再次有偏差,开发需要站在用户角度真正想清楚需求
  • 需求的分析归类,通过讨论,明晰定义,归类,排序的方式整理需求卡片 以及 小组内部分析用户真正需求等等方式去确定用户需求
  • A/B测试

  • 针对需求切忌 拍脑袋与拍胸脯
  • 功能需求的四象限 : 人无我有的杀手级功能以及外围功能 以及 针对该产品的必要性功能以及辅助性需求

开发时间的估算练习:

  • 事件估算中,既要计算已有模块重用问题,又要估算好探索问题的解决方案,常规情况下探索者高估自己探索解决问题的能力,可能看起来很容易的地方,水却很深,要充分考虑参考前人经验
  • 时间花费公式: X +/- (X /N )
  • ** 整个项目的时间估算方法常用有 自底向上(各自估算自己负责模块)与回溯法(从Deadline往前递推)**

需求的分割:

  • WBS —— 将大型项目分割成树形结构,将叶子节点分割到足够细致,善于构建草图

第十一章节软件的设计与实现:

  • 开发人员标准工作流程:需求——需求分析复审——详细设计——开发实现——自测,中间任意过程发现Bug做回归,重新设计实现
  • 管理自己的时间与空间,为自己创造专注的开发环境,不要为邮件与交流工具所拖累同时也需要注意不能闭门造车
  • 每日构建

其他待补充阅读相关书籍:

  * 软件工程
  * 人月神话
  * 人件   
上一篇
下一篇
Loading Disqus comments...
Table of Contents