阅读构建之法第13、14、15、16、17章与《一个程序员的生命周期》读后感

第十三章   软件测试

这一章介绍了很多关于测试的方法&＃xff0c;比如说单元测试&＃xff0c;代码覆盖率测试&＃xff0c;构建验证测试&＃xff0c;验收测试等&＃xff0c;我有一个很纠结的问题&＃xff0c;如果我开发软件&＃xff0c;是把这么多测试全做完&＃xff0c;还是挑一些测试来进行呢&＃xff1f;如果挑一些测试进行&＃xff0c;又很怕这个软件存在未知的缺陷&＃xff0c;如果全部测试都做的话那需要庞大的人力物力。

第十四章   质量保障

这章为了介绍了保障软件质量的方法&＃xff0c;包括分工&＃xff0c;每个角色的职责等&＃xff01;我总结出来&＃xff0c;软件的质量好坏取决于团队的水平。那么如果从一开始&＃xff0c;就知道团队的水平不行&＃xff0c;最终开发出来的软件质量很大可能得不到保证。我们这支团队还需要冒风险去开发软件吗&＃xff1f;

第十五章   稳定和发布阶段

我看到15.1.1节里有一个问题说&＃xff1a;“优秀的软件团队会发布有已知缺陷的软件么&＃xff1f;”这个问题&＃xff0c;我思考了很久。如果一个软件核心功能没有太大问题&＃xff0c;但是就有很多那些小bug&＃xff0c;会对这个软件的口碑产生很大的影响&＃xff0c;那么还能发布吗&＃xff1f;是不是为保障口碑而延期发布&＃xff0c;回去修复bug呢&＃xff1f;

第十六章  IT行业的创新

看完IT行业的创新之后&＃xff0c;里面提到&＃xff0c;为什么领域的专家有时候没有领域外的创新者那么有创意&＃xff1f;如果我是决策者&＃xff0c;我是应该听从专家的还是听从领域外的创新者呢&＃xff1f;

第十七章 人&＃xff0c;职效和职业道德

绩效管理&＃xff0c;一个团队的绩效管理是很重要的&＃xff0c;如评比也是绩效管理的一种&＃xff0c;但是如果真正的评比的话会不会影响整个团队的稳定呢&＃xff1f;

《一个程序员的生命周期》读后感

    启发&＃xff1a; 读完《一个程序员的生命周期》之后&＃xff0c;我感到作者的真情实感。其实&＃xff0c;一个程序员要经历很多事情&＃xff0c;包括来自工作的的挫折&＃xff0c;人际关系的处理&＃xff0c;以及生活中的各种困难。原来&＃xff0c;作为一个程序员并不是整天写代码就行了&＃xff0c;除了写代码之外&＃xff0c;处理人际关系是非常重要的。人生的多变在《一个程序员的生命周期》这本书里体现得淋漓尽致&＃xff0c;一个程序员的环境&＃xff0c;其实很多都不是个人能够操控的&＃xff0c;我们能做的就是适应环境&＃xff0c;并尽可能把自己的才华施展开来&＃xff0c;同时要不断的做总结&＃xff0c;比如作者在7年工作感悟中&＃xff0c;做的总结。最后&＃xff0c;无论遇到什么&＃xff0c;都要迎难而上。

    如果我处于这样的位置&＃xff1a;如果我处于这样的位置我会不断的调整自己&＃xff0c;就算遇到什么困难&＃xff0c;什么挫折&＃xff0c;我也要用积极的心态去面对&＃xff0c;去解决。