标签：android 使用 java sp 问题 代码 工作 时间 bs
一、 如何避免在产品开发后期不断有重大修改，导致其他模块的连锁反应？
我认为首先前期的需求分析要尽可能完善并确定，需求变更是程序员所不能承受生命之重。另外题目中谈到的设计模式变更方法，是个很好的控制策略。项目早期采用Tell-mode，可以先行设计并编码，有较高的自由度；到了项目稳定阶段，采用Ask-mode，默认不同意变更设计，需要等待肯定答复，有效避免了修改的频繁，避免其他模块的连锁反应。
二、 每周进度报告
报表可以帮助我们掌控项目进度，把握项目目标。如果你看到每个人每天花费的时间在不断增加，但是真正需要解决的Task和Bug都没有变化，甚至缓慢增加，则意味着团队离目标越来越远。
三、 如何避免诧异反应
1.解决客户对功能诧异问题：PM的分析和说明能力要可靠，甚至敢于拒绝。需求说明中要从用户的角度去描述和解决方案，鼓励用户经常参与设计和计划。
2.解决各模块功能不配合问题：利用“场景驱动”方法，首先保证典型的用户场景能够实现；从场景出发，各模块更容易相互集成。
3.解决新手无法开发问题：任务估计值乘以4，或者分配其他工作比如测试，这也是很好的贡献。
四、 团队成员不给力
软件工程其实就是“人”的问题，在软件开发过程中要恰当得处理人与人之间的关系。实际中各个角色不一定能各司其职。一方面因为个人利益拖三拖四，从编码到测试都落后于原来的计划，更何况当初的需求定义的本就不合理；另一方面，有人的能力不够，比如语言不通，或者没有开发过完整的大程序，势必会拖全组后腿。前一点大家都容易克服，也依赖PM的领导能力；而技术水平与经验不可一蹴而就，大家既然在这专业混，如果技术让人唏嘘的话，脸上也无光啊！
五、 解决问题OR搭架构
文章吐槽了Java程序员出现的一些问题，Java的使用方式影响了人们对它的好感。每个人都把自己想象成架构师，淋漓尽致的发挥面向对象特性，这不是在解决问题，而是计划问题，导致有非常多的层次和大量的抽象概念以及样本化代码，别人很难理解这些代码在做什么。可能我们在荒野中看到的大部分Java代码，很多是非常差的开发者写出来的。Java已经最大程度的被OO束缚，从代码到整个Java生态系统。即使越来越多的开发者意识到这些问题，并重返编程本质，也难以挣脱现在的局面，Android工程师依旧被使用Java困扰。
标签：android 使用 java sp 问题 代码 工作 时间 bs
原文地址：http://www.cnblogs.com/volcano1015/p/4021876.html
