开发探索的一些update:
将结果做为开发的基础和终极目标
开发者从过程的追求到最后结果的追求是一个质变的过程,相当于NBA中得分王和总冠军的区别:
如果以追求结果的表现为标准的话,那么反观追求过程的表现,其中会充满了不足,甚至南辕北辙,并且以各种方式表现出来,而且很多表现的非常的隐晦,有大量的借口可以搪塞。
负面例子可以说在任何一个项目里都可以找出很多,就不负能量了。
实践中一个可行的方法可以是,在做事和回顾的时候,想象一个超级老道的开发者,他能以最小的代价(时间,人力。。。)把事情搞定(短期品质和长期品质),自己和他有什么样的差别。这样不停的做,可以说会让自己各方面更加老练。
在经验技巧到心态上都会有挑战,且行且积累吧。
全栈开发者
开始一看就非常喜欢这个概念,跨界能力的开发者在逐渐演化过程中始终是强大的存在,到这一波可以说是被更加显示的提出和认可。
就在前天还看见一波持反对意见的文章,里面举例常常是执行不对的结果,任何一个方法道理执行不对都要跪,不能做数。
全栈开发者的完备性解决方案:一起写到这个文章里也是和第一部分“结果导向”一致的,实际做项目时候一个好的结果源自各个因素的良好设计计划和执行。
各个方面专业的人放到一起,把问题拆分,各自想出方法,放到一起形成最终解决方法,听起来很美,但是各个局部的负责人如果没有一个全局眼光,则无法给出全局最优解。
所以开发者(无论是策划,程序还是美术)一旦开始了解其他领域,并一次为依据来思考开发并且执行的话,都会大大提升解决方案的质量。
退一步说,就是做自己的一块,那么如果能从更大的范围看自己的一块,也会有全新的认识。
一般来说全栈开发者是指有实践能力的,并不是说考虑问题能考虑到这一块就行了,实践会让认识有质的不同,如果能够如此,当然更给力了。
完美与借贷
上一篇blog(http://blog.csdn.net/toughbro/article/details/22776277)里面提到了借贷式开发,自己也实践了一个task,也做一个小结:
这个任务做下来质量不变的前提下,团队完成时间跨度大约是会提速%20-%30吧,但是长时间看来的团队输出没有什么变化,但是对于这个对于开发时间很敏感的task来说是颇有意义的。
按照原来的思路是设计好,实现一个不错的版本,然后相关人员开始进行,我再逐渐补全其他。
那么后来就是设计好,提交一个半成品(可用但是距离高质量有一段距离),然后更早的进入到大家并行的状态,然后我在同步的去其他事情,最后同样可以提交出高质量的实现。