开发探索的一些update:
将结果做为开发的基础和终极目标
开发者从过程的追求到最后结果的追求是一个质变的过程,相当于NBA中得分王和总冠军的区别:
- 一个是完成一个局部的本职工作(有时候会和项目的结果冲突),寻求局部最优解,是贪心算法
- 一个是面向把项目做好的各种因素,以项目结果为最终目标(有时候会和本职工作有冲突),寻求全局最优解,是动态规划算法
如果以追求结果的表现为标准的话,那么反观追求过程的表现,其中会充满了不足,甚至南辕北辙,并且以各种方式表现出来,而且很多表现的非常的隐晦,有大量的借口可以搪塞。
负面例子可以说在任何一个项目里都可以找出很多,就不负能量了。
实践中一个可行的方法可以是,在做事和回顾的时候,想象一个超级老道的开发者,他能以最小的代价(时间,人力。。。)把事情搞定(短期品质和长期品质),自己和他有什么样的差别。这样不停的做,可以说会让自己各方面更加老练。
在经验技巧到心态上都会有挑战,且行且积累吧。
全栈开发者
开始一看就非常喜欢这个概念,跨界能力的开发者在逐渐演化过程中始终是强大的存在,到这一波可以说是被更加显示的提出和认可。
就在前天还看见一波持反对意见的文章,里面举例常常是执行不对的结果,任何一个方法道理执行不对都要跪,不能做数。
全栈开发者的完备性解决方案:一起写到这个文章里也是和第一部分“结果导向”一致的,实际做项目时候一个好的结果源自各个因素的良好设计计划和执行。
各个方面专业的人放到一起,把问题拆分,各自想出方法,放到一起形成最终解决方法,听起来很美,但是各个局部的负责人如果没有一个全局眼光,则无法给出全局最优解。
所以开发者(无论是策划,程序还是美术)一旦开始了解其他领域,并一次为依据来思考开发并且执行的话,都会大大提升解决方案的质量。
退一步说,就是做自己的一块,那么如果能从更大的范围看自己的一块,也会有全新的认识。
一般来说全栈开发者是指有实践能力的,并不是说考虑问题能考虑到这一块就行了,实践会让认识有质的不同,如果能够如此,当然更给力了。
完美与借贷
上一篇blog(http://blog.csdn.net/toughbro/article/details/22776277)里面提到了借贷式开发,自己也实践了一个task,也做一个小结:
这个任务做下来质量不变的前提下,团队完成时间跨度大约是会提速%20-%30吧,但是长时间看来的团队输出没有什么变化,但是对于这个对于开发时间很敏感的task来说是颇有意义的。
按照原来的思路是设计好,实现一个不错的版本,然后相关人员开始进行,我再逐渐补全其他。
那么后来就是设计好,提交一个半成品(可用但是距离高质量有一段距离),然后更早的进入到大家并行的状态,然后我在同步的去其他事情,最后同样可以提交出高质量的实现。
- 完备基础上的统筹和临时折衷:早期设计和计划仍旧是不能打折扣的,必须清楚高质量的实现是什么样子的,然后去在什么阶段什么部分去折衷(借贷),然后什么时候什么方式来还贷,这才是一次良好的运作。
- 实现过程中始终保持清晰,把折衷掉的东西放到todo list中,不应该折衷的东西坚持做下来
- 保持完备:最后代码质量,效率,注释,文档一个都不能少
- 如果上来不想就冲进去做了再说,这个是乱投资,只能看运气,和我这里倡导的根本是两码事
- 感觉开发过程更有意思了,做了时间久了,考虑的东西也多了,虽然写出来的东西更高质量,但是其实有点怀念刚入行的时候,没心没肺的在vc狂写
- 借贷时候有一部分就是追求速度,这个过程堪称coding storm真的很畅快
- 朋友圈里pm回了个话说这不就是敏捷思路么?嗯,这么说也对,但是对于实践者本人来说却很不同,开发功力练到第n+1级这种感觉吧,历数说来经历了
- 刚工作:没设计好(其实早期是有这个意愿没这个能力),开始编程(时间略长),终于尽快捣出了个能用的,大家用,然后尽量完善下(常常是时间紧,来不及完善了)
- 后来几年:追求编程能力,尽量好好设计,好好提升代码质量和速度,逐渐可以好好设计了,编程速度和质量在提升,但常常有任何时候都追求代码实现完美的倾向(当然实际中还是会写出不够好的代码)
- 再后来:可以好好设计和实现,进一步可以在大的节奏上做的更好更灵活,比如写得更快则有空间写得更好,一段时间内降低代码质量要求则可以进一步提速,然后后面补回,则可以让同样代码质量的前提下,团队开发效率更好。
- 或许再后来,可以一气呵成的写出好的代码,也不用借贷了,哥兜里够钱,不用借,利息都省了。。。
- 有借贷需求时候才应该借贷,不应成为懒惰的借口:
- 如果一开始就没有借贷需求,时间没那么紧迫,那还是力求直接完成比较好
- 有的时候coding时候会使用分而治之,一小块一小块的做,更适合大脑工作机制,这个和借贷方式没有完全本质的区别