|
|
本帖最后由 wb7570 于 2015-11-19 23:34 编辑
入职一年的小兄弟总结经验时说了句话：“写案子就是你替程序去思考，他只负责动手写代码“。
我就问问各位前辈，这句话对么？
==================================
交流了一下，那就说说我的看法吧。
我来告诉你们，不要为程序思考。提到新手程序的不少，但是帮助新手程序的是老程序。
而且大家为程序思考时，有个前提就是自己思考的内容是没错的。但是你能保证正确么？
以转盘宝箱为例。
策划需求的是什么:点击开始按钮，转盘转动，转动速度越来越慢，转盘停止箭头指向奖品，玩家获得奖品。 抽奖内容、奖品几率等等。
程序的实现逻辑是什么:击开始按钮，请求服务端获取奖品，转盘转动，转动速度越来越慢，转盘停止箭头指向奖品，玩家获得奖品。
或者是：击开始按钮，转盘转动，请求服务端获取奖品，转动速度越来越慢，转盘停止箭头指向奖品，玩家获得奖品。
可见策划的思维方式和程序是不同的，这是一个不牵扯其他任何内容、很简单的功能，如果稍微复杂一点呢？复杂一点一个程序都很难懂另一个程序，更何况策划。
策划首先要做好自己的职责，写清楚需求，操作流程，体验效果等。在职责内策划是有决定权的，其他人对需求的修改需要和策划商量，决定权在策划手上。程序是有否决权，表示无法实现，同时提供原因和可行的替代方案给策划，策划重新确定需求。程序不能私自该需求。
同样程序怎么写代码是程序的职责，你可以帮助他(不建议，程序内部解决)，但决定权在程序。
而且替程序思考也很可能想当然的局限住自己，以为程序会这么做，所以这个需求被自己pass掉。当然最基础的逻辑感要有，不能天马行空。
总之不要替程序去思考。做好自己的职责，可以帮忙，但不要越权。
==================================
从软件工程角度考虑。大的方面分为需求、设计、实现、策划、维护几个阶段。
对于游戏来说，需求就是策划工作的重点内容。
而设计，注意是软件的设计而不是游戏的设计， 已经是程序的工作内容，设计阶段已经牵扯到软件的系统结构，数据结构，处理流程等。而且程序很少将这些内容落实到文档上，都是内部协商定下准则。那么在这个整体设计下，策划替程序思考是不够全面的。尤其是复杂的功能，程序之间都很难互相理解，更何况策划。策划做不到所有需求都替程序思考。 而且处理流程并不是有固定答案的，遍历算法不同程序员都有不同写法，程序不需要非要按策划的思路来写代码。如果你能做到，那么恭喜你可以胜任程序了，只差敲个代码。
这些都是程序的职责，策划不全能，也没有必要替程序思考。反而会因此限制住自己的思维。
在实际项目中，每个人的水平，项目经验不同，多沟通都是好的。但是搞清每个职位的职责范围，对项目进度、管理都是有益无害。在有争论时，应该尊重各职位的职责、权利，做好份内的事，这个产业链才能运转起来。
|
|
[复制链接]
发表于 2015-11-18 09:23:53
楼主
发表于 2015-11-18 10:12:04