回答自己的问题

第一章:

                   在阅读完第一章只有一个困惑那就是: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后端,不可能一次见效且完美无误

原文地址:https://www.cnblogs.com/case1/p/4598718.html