开发者,你是如何做到高效开发的
前两天在坛子里撸了一发帖子并被版主推荐,在此很感谢。浅谈Android优秀App架构,帖子讨论关于开发APP时所用到的一些玩意和架构设计。可能是我的问题提的过于广泛了,以至于让大家一看就磨灭了回复的心情,心中可能会冒然而生一种想法:这TM怎么像是在搞论文似的,来来来,脸挪过来……。好吧,我错了!求不打脸。
其实目的就是想和大家聊聊,聊一聊那些大家在开发App时,用到的一些架构设计,采用的网络架构及目前主流的Android APP开发方式 等,对这个挺感兴趣的。不过帖子也反应了另外一个问题,作为一个研发人员,项目经理也好,技术总监也好,小鸟和老鸟也罢,在开发过程中该如何做到高效的开发呢。
一个成功的产品,倘若没有一个合理的架构,迟早会死掉。如同建造一个房子,若没有合理的打造底部地基架构,建造材料垃圾,敢住吗?比如前段时间公司楼下大面积挖掘,导致上下班拥堵及引起部分交通事故,最后了解到原来是因为地下的通水管太细导致堵塞,所以大面积挖开解决问题,这应该也是建造时设计的问题吧。同样,产品没有合理的架构,随着用户需求的更改和功能的增加,哪里漏了堵哪里,这样行吗?总之,框架的搭建,就是为了更好的管理产品,提高维护和开发效率。达到让所盖的楼更稳健更高,产品更稳定的最终目的。当然提高开发效率由很多因素组成,如团队的配合,项目经理的管理,人员的分配,技术因素等等。
本篇文章主要也是和大家聊聊,聊一聊关于高效编程的经验,关于其他的因素还是不要乱来了,要不然又有大神蹦出来:来来来,脸挪过来……。
我们将从关于文档、开源库的使用、IDE的选择、设计模式的使用、Debug,心态,沟通 等方面和大家聊,这些都是提高开发效率所遇到或考虑的问题,不过,咱话先说好,聊完后不要对我说:放学别跑!--- 放学我还是先走了。
一、关于文档
关于文档有很多,各种各样的文档,这里就简单谈谈需求设计文档和测试文档吧。
① 需求文档
了解文档需求,才能采用相应的技术进行开发。目的很明确,就是要从整体上考虑程序的实现,避免开发出来的东西,有了东却少了西。避免开发过程中,编译通过,但运行起来却出来很多逻辑上的错误。是否真正了解自己要做的东西,理解了设计文档之后,自己琢磨下或者和设计部详细描述一下要做什么东西,做出来是什么样子。
② 测试文档
这个是万分重要的,为了避免在后面编码过程中浪费大量的调试时间。一份测试文档(或测试用例),也就是常说的极限编程,测试方案在写代码之前完成,或者其他有被实践证明简便有效的方法。记得以前在开发中经历过这样的情况:程序员A在编写完某一个功能界面后,哗啦哗啦一套撸下来,数据获取,解析,业务逻辑操作处理,数据显示,调试。哎妈呀~ ,一大堆错误。然后定位到错误,就和程序员B说,那谁谁谁,你给的接口存在问题啊!什么,我给的接口有问题?怎么可能!然后……
③ 题外话
程序员的世界里,总是浮现着:
1)在我这运行没有问题的程序,为什么在你这边就出现问题了,一定是你的电脑配置有问题。反复问清楚你的情况之后,确定这不是你的问题,才承认是自己程序的bug。
2)本来10行能解决的程序,一些程序员一定要把它拆开,一层一层的用设计模式去做,不断的面向对象包装,包装的一层一层又一层,码出来100多行代码,这样他们才感到高兴。虽然不会太影响执行效果,但代码让人无法看,于是下面每一个读代码的程序员都会觉得上一个写代码的是傻13。
二、开源库的使用
使用稳定的开源库或框架提升编码效率,但是在实际需求中,也许不仅仅局限于开源库的功能,也许自己在开源库基础上进行扩展后,操作会更便捷。比如本人之前在分享一篇关于Android洗车项目的博文中对 Andoroid-Async-HttpClient 的网络架构进一步扩展,达到三行代码提交请求获取数据,返回结果直接是已解析完成且可使用的对象。很显然提升了编程效率,每当需要请求数据时,直接使用这三行代码,定义需要携带的请求参数对象,定义一个Parser解析类,OK!
private void login(String name,String pwd){
GenericDataManager mDataManager = GenericDataManager.getInstance();//通用网络管理类
RequestParams mParams = RequestParameterFactory.getInstance().login(name, pwd);//请求参数管理类
mDataManager.dataRequest(0,Constants.REQUEST.GET, RequestURL.URL_LOGIN, mParams,new ResultParser(), this);//执行网络请求
}
这里给大家一个建议,若你刚刚脱离新手,会熟练使用一些第三方的库,其实这个时候你完全有能力去深入的剖析下这个库的内部实现,或许会有更大的收获。
三、IDE的选择
选择一款高效便捷的IED,能大大提高编码效率,如Android开发人员选用 Eclipse 还是 Android Studio ,又如一个Web应用,Ruby的开发效率或许是Java的3倍;使用持续集成,版本管理的工具同样也可以大大提升效率,使用自动化测试的工具可以提升编写测试的效率,增强可维护性 等等。四、设计模式的使用
一段代码经常用到,是否会考虑进行代码的封装复用?在中大型项目中,必然需要使用设计模式,房子建起来了,现在发现窗户样式不太好,想换个样式,结果改造时却拆了一面墙。汗~,这TM还得了!在了解需求的前提下,还需要对需求进行未来可能的改变有相应的预防。应用设计模式对相应的模块进行相关的详细设计,模式级的设计,让系统设计的更加可扩展,稳定。
如代理设计模式,由一个代理主题来操作真实主题,真实主题执行具体的业务操作,而代理主题负责其他相关业务的处理。比如生活中通过代理访问网络,客户通过网络代理连接网络(具体业务),由代理服务器完成用户权限和访问限制等与上网相关的其他相关业务操作。
示例:
interface Network { // 定义Network接口
public void browse(); // 定义浏览方法
}
class Real implements Network { // 真实的上网操作
public void browse() { // 覆写方法
System.out.println("上网浏览信息!");
}
}
class Proxy implements Network { // 代理上网
private Network network;
public Proxy(Network network) {// 设置代理的真实操作
this.network = network; // 设置代理的子类
}
public void check() { // 身份验证操作
System.out.println("检查用户是否合法!");
}
public void browse() {
this.check(); // 调用具体的代理业务操作
this.network.browse(); // 调用真实的上网操作
}
}
public class ProxyDemo {
public static void main(String args[]) {
Network net = null; // 定义接口对象
net = new Proxy(new Real()); // 实例化代理,同时传入代理的真实操作
net.browse(); // 调用代理的上网操作
}
}
五、Debug
一般在程序调试过程中出现错误,会借助一些工具或者插件来快速定位错误,打断点或者输出Log进行调试。这里要切记一点误区,对于初学者,往往会为了避免出错,常常全比写代码的时间超出两倍用于测试,写两行,跑一次程序,再写两行,再跑一遍.....其实这是非常没有不要的,既浪费时间影响编程效率,也会因为频繁的测试测试,导致内心狂躁。另一方面,应该学习正确的调试方式,在清楚业务的情况下写完模块后,若程序有误,使用正确的Debug方式进行调试,如Eclipse中,简单的调试:
- F5-Step Into:移动到下一步,如果当前的行是一个方法调用,将进入这个方法的第一行。
- F6-Step Over:移动到下一行。如果当前行有方法调用,这个方法将被执行完毕返回,然后到下一行。
- F7-Step Return:继续执行当前方法,当当前方法执行完毕的时候,控制将转到当前方法被调用的行。
- F8:移动到下一个断点处。
六、关于心态
有时候常常会因为一个问题或者错误,用了很长的时间,不知不觉查了很多资料,还是没有解决,却花费了大量的时间。其实就是思路不愿意从这个坎转移开,导致思维固化。这时候,其实在告诉你,你可以离开座位了,去喝杯茶,去阳台看看远处,让思维散发散发,即使人离开了,思路还在这个待解决的问题上,也比闷头闷脑的在哪里苦思好。或许在你重新回到座位的时候,这个问题的解决思路就出来了。记得以前有个很搞笑的同事,每次遇到问题解决不出来,他都会把桌椅转过来,跪在上面,双手按在键盘上:哥,你为什么总是报错呢,我跪着写行吗?哈哈,开个玩笑。
七、关于沟通
沟通,其实是非常重要的一点。合理有效的沟通,学会与他人沟通如非工程师(UI美眉)也能提高编码效率,能让你思路更清晰。且能让你有效的解决业务逻辑上的错误。及时沟通还有一点就是项目经理叫你做东,你做了完全没有必要的西。
构思了很久,发现写些纯文字的文章,真难玩。像屙不出来屎一样。不过回头一看感觉好像还是屙了点东西出来的,见谅见谅 ~
个人觉得以上几点都是提升开发效率,高效编程所必须考虑的。不知道读者读完文章后,是否赞同或者也有自己的一些看法和意见,可否与我分享?
【注:转载注明gao_chun的BLOG http://blog.csdn.net/gao_chun/article/details/47364223】