随着时间的推移,我越发尽量避免“费”,“不费”这样的描述。
原因就是
- 不客观:每个人有不同的标准,同一个东西你可以随意的描述为很费,很不费。。。
- 不准确
当然,这样的含糊的描述有其存在价值,因为我们的确不可能做到完全的客观准确。
但是,作为engineer,我们应该尽量避免这种不够客观和准确的描述。
而且这样的做法对实际是非常有帮助的,在早期知识和实践都不够的情况下,我会出现过于保守或者过于“大胆”的问题。
其实也就是不准确的问题,随着知识和实践的增加,我发现可以更加准确的去定位技术和规格(format, resolution...)的选择。
说道这里也让我想起最近玩星际2残酷模式的一些感想。
我对自己的要求是残酷模式全成就,也就是常常要在面临这种情况下:
要在xxx分钟内搞定敌人,或者不仅是要完成美女博士交给的任务,还要去打进敌人的老巢。
我惊奇的发现这种情况下是非常有乐趣的,简直就是另外一个游戏。
你需要先经历失败,了解什么情况,然后好好的思考,精确的制定从战术层面到操作细节和流程,才能达到残酷模式全成就。
这里总结的情况是,星际2的基本功很好,那么可以无视任何情况的随意打,维京关:甩枪兵,坦克关:甩枪兵,xxx关还是甩枪兵,但是这个也就能过困难模式。
良好基本功,注意战术,缺少经验和细节,残酷模式可以过。
但如果残酷模式全成就,就得基本功,战术,细节和经验都要好才行。
同样带到开发中来,凭借了解到“费”或者“不费”这个程度就把事情搞定,随便一弄就搞定了,那么其实只是个普通玩家。
需要大局搞定,细节准确,精益求精的程度,才会是残酷模式的玩家。
细节于大局是一个优先级递推的关系,而不是一个对立的关系。
就需要从优先级最高的大局做起,一直搞定到优先级低的细节层面,就需要去做一个残酷模式的玩家。