标签：style os ar sp 问题 on 代码 工作 ad
《移山之道》读后感
老师布置的阅读任务虽然是附加的作业，但是对我来说是个很好的学习机会。软件工程主要是对工程的开发进行学习，毕竟在学校老师教了那么多的知识，我们课下做了那么多的练习并没有提高我们做一个工程的能力。一个项目一个工程不仅仅是编写代码，调试，简单的测试，通过阅读《移山之道》这本书我对开发项目有了一个全面的了解。
平时对教科书那种语言方式不是很接受，这本书一直用一些故事和真实的例子来激发读者对于书本内容的兴趣，引导读者继续阅读。
虽然平时接触了一些编程类书籍，但是接触软件工程相关书籍还是第一次，读了这本书以后有很多的收获。也是通过这本书我才了解到开发一个软工项目的团队中原来需要这么多人员的协调，并不简单的是有人写代码有人测试就行了。对于一个产品，团队需要有PM建立一个用户和开发者之间的桥梁进行沟通，用户说出自己的需求，开发团队才能根据需求完成相应的任务。团队的每个人之间的联系也是PM或者说是Leader建立起来的，没有一个好的管理者一个团队是无法完成任务的。而开发团队中的编程能力强的人不少，但是他们之间的合作是能否高效完成任务的关键，遇到问题时是否能冷静下来处理问题而不是坚持自己的意见不退让，对于合作项目中的代码，是否有share的思想，可以客观的分析出自己代码中的问题。
我产生的疑问：
1.PM不熟悉现阶段项目用到的技术，无法准确控制开发的时间和进度，Dev Leader懂技术懂代码但是队员的水平参差不齐，有些事情只有Leader能解决，这时候该怎么办？
答：我认为这时候解决问题的最好方法是Leader在对项目工程进行一些问题修复的时候让全队旁观，相当于每次的工作都是一次教学，毕竟大家的磨合才能使团队进步。如果水平的不足是既定的事实了，那么只好寻找方法去弥补。
2.如果团队里遇到了技术很牛但是合作精神逐渐才发现很糟糕的人该怎么办。如果此时找不到任何能接替他的技术人员了，是放弃他还是放弃项目？
3.复审的意义是什么？对于一些牛人的代码，是否还有必要进行复审？
答：人无完人，再牛的人在编写代码的时候都有可能会犯一些细小的错误，让别人复审不是对于程序编写人员的不信任，而是希望对方能够完善自己的程序，从中发现自己在编写代码时的问题，避免今后错误再犯。
标签：style os ar sp 问题 on 代码 工作 ad
原文地址：http://www.cnblogs.com/yi1994324/p/4020490.html
