回答自己的问题

第一章：

                   在阅读完第一章只有一个困惑那就是：1.怎样才算是一名合格的工程师？

                        回答：对于这个问题，更多的是要有个人能力的体现和个人品德结合，有才有德，而不是有才无德的危险品。

 第二章：

                    1.单元测试要快，既然要快，那同时单元测试要测试API中每个方法以及每个参数，而且同时还要覆盖所有代码路径，那无疑会增加大量程序代码，如何做到快？（章节2.1.2)

                        回答：代码多，并不一定会慢，构架也很重要

                    2.学生毕业到走向社会成为职业程序员，这过程需要时间，而且国内的程序员又有一个35岁危机，那我们该如何对待？提前转行向管理或者其他方面？（2.3）

                        回答：在前面的时间过程中，要一边积累更多的编程经验，一边利用时间去学习其他扩展知识，往构架师方向看。

 第三章：

                    1.  一个能力出众的程序员要如何融入到团队中去？而不是会被团队排外，不积极就会被看轻，而积极又会被误会抢风头，完全是因为国内环境导致吗？(章节3.2)

                    2.在3.2节的软件工程师的职业发展中，提到考级，而在社会工作中，实践经验比证书更重要，要是在大学期间就接受这种固定性思维成长，在将来工作中岂不是会影响到以后的工作模式的创新吗？

                       回答：考级证书不仅仅是国内的，国际是也有，它是一个程序员很基本的实力认证，而且证书也能同时证明你有最新知识的积累，考级试题都是会按照社会的新知识来设计

 第五章：

                 在5.3节的开发流程中，个人或者是小组中，大多都是使用写了再改模式，这也可以更快完成，在前面也提到要降低任务交付时间的标准差，这也能更符合，为何不提倡，而只说对实际用户，解决实际

                 需求来说缺点太大？ 在团队中，写实际软件过程中，更多的也是分模块来写，并想不出有何缺点。

                 

第六章：

                 敏捷流程在我们的学习过程中就是我们常用的想到什么写什么吗？

                  回答：还不是很清楚敏捷流程要干嘛

第七章： 

                 在7.2.2中提到：如果发现你做的事情对项目的远景没有帮助，你应该跟老板提出来。对于这种精神，可以应用到其他工作上，而前提却是老板给你安排的工作，是不是应该先想一想老板为什么这么安排，

                 自己是不是还没发挥出来，是自己原因而没有做到正确的事。 “我的责任是把事情做出来，而不是讨好所有人，让他们知道我按照他们的意见做了”我更赞同前半段话，但“我按照他们的意见做了”是不是最

                 终还是要按照别人的建议来做？

第八章：

           在8.7中的分而治之里说需要一个角色出来，领导大家，PM的重要性在我们实验的团队中却显得没什么用处，

           并没有体现出他的价值存在，然而也无法解决队员的一些人没事干的问题，我觉得一个团队中应该是有一个

           实力够强的人物，不要队员实力偏差太大会比这个PM更有帮助。

           回答：自己无法胜任的角色，不一定就是说别人来扮演就没有用处，PM微妙的协调最终或许会带来意想不到的结局

 

第十章：

         在前期花费时间做好的spec却说不能过于依靠，那为何不把时间直接用来开发新代码？

          对于个别用户的要求超出团队能力，那要改如何做出决定？

          回答：对于故意***难的用户，换一个角度来说，他们真是我们产品改进的促进者，也是团队整体实力提示的功劳者，那我们团队就更应该努力完成

第十章：

               在10.2的规格说明书中，要认真做好，但现在的人（年轻用户群体）有问题都是网上百度，而不是自己看说明书，且以前的有

              些功能变成现在很多人都有使用，却不加入说明书，那不就是说明员工没有很好的和用户沟通以及后期的跟踪调差咯？很明显的

              一个列子：现在的android手机都有一个很经常使用的就是设置里的开发者选项，但是在所有的android手机的说明书中却一直没有加入，也没有介绍这个

             回答：以后自己做产品，要更加注重细节，不将就，尽量做到极致，真心真意为用户着想。

 

第十一章：

               在这一章中说到每日构建，但每日构建具体是什么？我还没有弄明白，是每日总结？小会议，工作啥的总结？or提纲？

               回答：最终还是不知道，而不了了之丢弃。

 

第十四章：

             团队中角色越界要如何处理？团队的不相互体谅如何解决？

              回答：前期的磨合很重要，有问题说问题，有意见说意见，不要憋心里担心影响团队关系而一直压抑着，这种最好要在前期就要建立好团队的默契

第十五章：

            对于我们团队实验来说，在测试没有什么bug之后，完成打包apk，就没有继续去加入新功能，顶多就是改改界面而已，

            完全无法做到像书上讲的那些。

             回答：这一直都是一个问题，在书上前面也说过我们做出一个产品雏形，后面要花时间去维护，我们要的是一个可以长久可用的产品，而不是只拿出

             来上交作业，在想法上我们就已经和前面不一样了

 

第十六章：

            没有一定的专业基础知识而想出来的创新几乎是比较少的，就算他们说都是在他们拿手领域之外发现的创新，也是因

            为他成为一个专家，想要成为应该专家，不可能只是单单涉及一个领域知识，你让你一个没有接触过计算机的人来创

            新计算机方面的一个技术是几乎不可能的。

             回答：在知乎上，有类似的专业回答。

 

第十七章：

           在团队中，最难搞清的就是自己在团队中的投入级别，以及别人对自己的期望，而且现实中他人都会错估队员的实力，有

            没有更好更快的方法找到自己的地位，以及其他队员对自己的认识？

             回答：只能通过自己慢慢摸索，不可能一次见效，就好比自己做web后端，不可能一次见效且完美无误