提问回顾与个人总结
提问博客
请尝试对自己曾经提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄清楚的。是否原来的问题还不明白？如果有，请分析。是否产生了新的问题？如果有，请提出。
4.2.6 “命名”中提到了一些命名规则，对此我有一些疑问：
“在变量名中不要提到类型或其他语法方面的描述，如arraylistOfHolidays写成holidays。”
对此我仍然坚持我自己的观点。将适当的变量类型加入变量名中，一定程度上增加了代码的可读性，减少了debug的工作量。在搭建神经网络的实践中，常常会遇到变量类型为LongTensor、FloatTensor、Variable等多种类型的同一变量都被用到时，使用变量类型作为变量名来区分彼此没有什么问题。
4.3.2 “goto”提到了：
"只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。"
我对这个问题的解读换了一个思路。这句话的前提是“有助于程序逻辑的清晰体现”，这也正是不推荐使用goto的理由。因此，只要程序员认为使用goto能简化逻辑，使用goto进行编码也无妨。但大多数情况下，使用goto的代码不会被人轻易读懂，这也正是不推荐goto的理由。在gamma开发中，我的工作涉及到修改alpha部分的代码，面对自己亲手完成的代码，我真的读了很久才知道当时这样写的理由。
16.1.4 “迷信之四：创新者都是一马当先”中，举了iPod、Gmail的例子，来说明创新者不一定是第一个提出创新想法的人。然而，这些后来跟进的人能够打败其他人，想必也是有了一些其他竞品没有的体验或功能。是不是也可以说，这些帮助他们打败对手的特点，也是创新呢？所以创新者应当是在关键功能上第一个提出并实现创新想法的人，他们同样是一马当先，但不一定是开创了一个行业，或许只是开创了行业里最优质的服务和最吸引人的关键特点。
各个方面的创新都是创新，但通常意义上最一马当先的创业者不一定是最成功的。我们和另一组选择了相同题目，功能上也有一定的相互借鉴。但用户体验最好的才是最成功的。
17.1 “领导力”中，强调了团队领导的重要性。联想到即将开始的团队编程，领导该如何确定？很可能出现两种情况：一种是团队里有个大牛，由于他的技术最好，大家都听他的。另一种是大家互相讨论，少数服从多数，实际上没有一个真正的领导。实际上，由于大家都是技术人员，对项目方向上的把控水平可能都差不多，所以我认为没有领导的小团队，应该也是可以的吧？
领导是一定要有的，哪怕没有专门的领导人员，也要由技术骨干主动承担起领导的职责，否则项目无法进行下去。这是团队项目中得到的宝贵经验。
9.3 “PM做开发和测试之外的所有事情”，提到了PM需要的能力和职责。现实中，PM具体如何保证项目进度？如果遇到技术人员普遍落后进度，PM会怎么做？
在一个几个人的小项目中：
- 继续push成员，了解落后原因
- 正当原因，则考虑delay项目
- 非正当原因，直接扣分\扣工资，甚至踢出团队
毕竟在团队工作中，每个人的任务都是团队任务的一部分。毫无理由的不完成就应该接受后果。
软件工程这门学问有很多 “知识点”， 这门课强调 “做中学” - 在实践中学习知识点。请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点就可以。
- 需求：没有完美的需求分析，因为需求是会变化的。一定要给以后的开发留出一定的余地。
- 设计：设计需要集思广益，自己冥思苦想的结果往往不如大家建言献策的结果。
- 实现：积极、主动。
- 测试：测试没有想象中那么简单。除了单元测试、压力测试，更重要的是用户体验的测试。测试人员是软件发布前的最后一道关卡。
- 发布：慎重发布大版本，应先经过足够的测试。否则将会出现发布新版本后追加无数个补丁的情况。
- 维护：费时费力，团队项目中往往做不到“谁写的bug谁来de”，而是“谁最强谁来de”。
结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。
在我看来，结对编程往往不适合在真实的环境中实现。想要把结对编程的效果最大化，就要两个人不仅水平相当，更要思维相悖，这样才能在合作的基础上有效的发现出对方思路的缺陷。而在现实中，人们往往演化成了两个人花费了比个人编程更多的时间，去完成了效果更差的代码。这并不特指哪个结对编程的小组，这是大家普遍遇到的情况，而我们组的实际情况相对会好很多。两个人合作完成了结对作业，最后也拿到了不错的分数。
在团队项目中，我在一个网站项目中担任后端。在数据库课程中写过网站的我，本以为这个项目会是一个得心应手的项目，但在alpha阶段的结尾，我发现了区别：在数据库课程中，我们的目标是“做出来网站”；而在软件工程中，我们却要“做出一个他人能用、不被他人用坏的网站”。无论是测试工作、服务器部署还是安全工作，目的都是把一个个人网站变为真正的网站。这一点，确实改变了我对课程设计的想法。
但在我看来，组队应当在选题之后，不然可能会出现“做pytorch项目却不懂机器学习”，“做安卓项目却因为a卡无法运行代码”，“做网站项目却没学过数据库”的尴尬。不妨先由组长选题或提出自选题目，再各自招兵买马——不按朋友关系的好坏，而是按照对题目的喜好程度来组队。还有一点就是团队开发中的很多时候，程序员喜欢一个人工作，大多是因为太多的时间会花在“和他人沟通却最终收到一份不满意的结果，不得已自己只能重做一遍”的问题上，这一点很多时候并不是布置任务者或被布置任务者任何一方的问题，但也确实让人头疼。
由于我和我们组的两位PM都比较熟悉，在整个项目的过程中都或多或少的了解或者参与了项目管理的工作，着实体会到PM的不易。既要总揽全局，对项目今后的走向首先给出建议，又要完成代码任务。既要提醒成员哪里有不足，在贡献分上又要使出吃奶的劲照顾大家，不能让分数差距过大。我也明白作为管理者多少都会被人诟病，可看着大家感想里都在吃我们组的瓜，确实有点不是滋味。
我对任何developer参加的任何团队开发的想法是：1. 作为PM，应该向其他人员表达出有任何问题随时反馈的观点。如果PM没有表达出，那么PM就应该去和每个人了解情况，否则就不是一个合格的管理人员，毕竟PM管的是人和项目。2. 如果PM已经多次表达出了对感受的询问，其他人有问题或觉得有被不公平对待就应该直言不讳，何必当时抹不开面子不说出，自己认为吃了哑巴亏，最后才说出想法。更不要以最不端的恶意去猜测所谓的真相，这种猜测自己和近亲的朋友聊聊即可，何必摆出来让大家难堪。忘记是头条还是哪家大厂的原则，是“有问题第一时间提出”，着实是个好原则。
说完全不带感情的客观看待问题是不可能的，以上纯属个人感想，不针对任何人。
