提出问题
- Question 1:P49
初级软件工程师如何成长呢？
1、积累软件开发相关的知识，提升技术技能（如对具体技术的掌握，动手能力）
2、积累问题领域的知识和经验（例如：对游戏、医疗或金融行业的了解）
3、对通用的软件设计思想和软件工程思想的理解
4、提升职业技能（区别于技术技能）
5、实际成果职务：
问题：初级软件工程师的成长仅仅只需要这些吗？
-- 引用自《[如何在三年内快速成长为一名技术专家](https://www.zhihu.com/question/26572626)》
在过去的二十年里，我不断地被告诉：心态很重要，做人很重要。如果没有良好的心态，什么事都做不好，遇事不够沉着冷静，容易出问题。首先，在学习上，如果没有良好的心态，什么东西都学不好，也学不进去。对待比自己优秀的人，应该用什么样的心态去面对，是嫉妒还是向他人学习。其次，记得初中语文老师跟我们说过：一个人最重要的不是成绩优秀，而是如何做人，如果不会做人，成绩再优秀都会被人看不起。在我的想法里，我觉得一个人要先具备良好的素质和心态，才能把书上说的五点做好。
- Question 2:P346-373
IT行业的创新
16.1创新的迷思
迷思之一：灵光一闪现，伟大的创新就紧随其后
迷思之二：大家都喜欢创新
迷思之三：好的想法会赢
迷思之四：创新者都是一马当先
迷思之五：要成为领域的专家，才能创新
迷思之六：技术的创新是关键
迷思之七：成功的团队更能创新
迷思之八：创新者就是冒险家
16.2创新的时机
16.3创新的招数
问题：说了这么多关于创新的例子，创新者究竟应该具备什么才能谈得上创新？
书上的例子都很鲜明，简单明了，给人一种创新很难又很简单的感觉。有些原本在我印象中觉得是对的，在看了例子之后又觉得不一定是对的。一开始看目录的时候，觉得创新者需要具备这些，但是看了书本之后，书上的例子又否定了标题，这是有对也有错，就看你怎么用的意思嘛？
- Question 3:P16
什么是Bug呢？简单地说，软件的行为和用户的期望值不一样，就叫Bug。是否是Bug，取决于用户，开发者的不同角度。
问题：从书上给的两个例子可以看到，当用户和软件优化有冲突，期望值不一样时，那这时候要怎么选择？是从用户的角度还是从软件优化的角度？
一个软件的开发为的就是服务了用户，如果软件应用达不到用户的期望值，那这算是软件的Bug吧。P17有说到要研发出符合用户需求的软件，在软件开发之前，肯定有做过调查之类的东西，这样才能准确的知道实际用户需要什么样的需求，而不是凭空想象出来的。在优化的时候，也应是在使用过程中发现不足才需要优化，但是如果优化的目标难以实现，这时候应该想办法解决这个冲突，否则这个软件是不是就要gg了。
我从网上找了一个参考链接——以业务目标为基准去推导用户的行为，当这个行为和用户目标相违背时，我们应该想办法把用户不喜欢做的事转化为和用户使用动机相关的事情，引导他完成，就是把用户不喜欢做的事情变成感兴趣的事情
- Question 4:P316
软件质量保障工作：软件团队为了让软件达到事先定义的质量标准而进行的所有活动，包括测试工作。
问题：在P311中有一个公式：软件质量=程序质量+软件工程质量；程序的质量体现在软件外在功能，而软件工程的质量是在功能、成本和时间三个方面要满足利益相关者的需求。软件质量有这么多的保障工作，那么哪些才是最重要的，而哪些又是很容易遗漏的？
- Question 5:P25
单元测试必须由最熟悉代码的人（程序的作者）来写，代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。
问题：单元测试一定要程序的作者亲自来写吗？
程序的作者固然最了解代码的目的、特点和实现的局限性，单元测试由他们自己来写固然了轻松容易，更顺手。但是既然有了测试工作这一环节，固然有专门写测试的测试人员。课本中还说到有团队合作，既然都有团队合作，那么作者和测试人员之间也可以有团队合作，他们也可以做到对代码的熟悉，并且如果在一家大公司里，程序员每天要写的代码很多，在大公司里也都设有测试部门，当然程序员自己应该也要做相应的测试；如果是在一家人员不足的小公司里，那么程序员肯定要自己写单元测试。所以我认为单元测试不一定必须由程序的作者来写。
在P26中的问答中也说到可以考虑让别人来做单元测试
问：如果我很忙，能不能让别人代劳写单元测试？
答：如果忙到连单元测试都没有时间写，那么你也没有时间写好这个功能。在一些极限编程的方法中，是可以考虑让别人来做单元测试的，但是，程序的作者还是要对单元测试负责。