读《StarCraft开发的荆棘之路》
http://www.csdn.net/article/2012-09-13/2809882-tough-times-on-the-road-to-starcraft/3?bsh_bid=138115479
英文原文：
http://www.codeofhonor.com/blog/tough-times-on-the-road-to-starcraft
切实的记录starcraft这款经典游戏的开发文章，而且里面不是一味的吹嘘，我们多么多么牛，多么有追求，多么奋斗，真实的展现了项目的情况，一些反思，是一些能够切切实实能够帮助我们在项目里面做的更好的游戏。
追求本源
starcraft原来不用开发的这么费劲的，但是源于早期高层糟糕的决策，导致开发团队一开始就做了开发一个普普通通的游戏，赚点钱的决定，在这样的指导思想下，是不可能做出好东西的。追求盈利等等这些都是不可厚非的，也是高层应该做的事情，但是不能舍本逐末。
这些大道理谁都知道，关键是在实操层面能做到多好。
“新人”
这里一个是没有足够经验和培训的编程方面的新人，这个太多文章讲这个事情了，就是没有足够限制和帮助的情况下，是带来进展还是倒退不好说。
还有就是里面的lead programmer，之前工作经验很多，但是没有原创性的发售一个作品的经验，做一些移植性质的，或者在现有的engine上做一些feature，这个不能证明此时此刻lead programmer的最重要的能力---架构设计能力。
我自己以前也做过一些移植和现有引擎上的提升工作，的确感觉到这样的工作有这样的特点：
- 早期时候，会让你学习进步非常快，仿佛立刻和顶尖球员一个球队，你可以非常好的看别人是如何做的
- 中期的时候，你实现一个个feature的能力已经非常好了，在一个局部的战斗力非常强，在基本功如此扎实之后，你需要去在大规模设计架构方面成长，但是如果还是移植和在现有引擎里面工作，你会发现没有这样的成长机会。
- 而且这里面的“功力”的关键就是对问题的认识，预测，然后在一整个大模块的高度和范围去做一系列设计来解决这些问题
- 没有问题的话，你如何去解决和磨练？
我之前的一个经验就是拿一个现有的引擎，然后在代码管理server上开一个branch，进行大规模的升级，这个过程中的确触发了非常多的思考。
重写
“永远记住：当你打算重头开始时，你并没有理由保证能做得比之前更好。首先，你的团队不一定还是当时的团队，所以你们并不一定更有经验。大多数情况，你们只是再一次重蹈覆辙，甚至还可能会带来一些新的问题。”----joel
同样是一个老生常谈，但是每次看到，我对其中应该怎么做还是倍感纠结，或许没有切肤之痛的人对此没什么感觉，尤其是项目管理者，那就不要重写，这很好。
但是作为一线的开发者，在面对一个乱的毫无头绪的代码，如何去工作，真的不知道如何去工作，那个感觉只能用吃屎来形容，然后做出一坨恶心东西。
解决方案只能是在平时多多的积累，提高自己的coding能力，每一个模块和提交的实现都更加小心，不要让自己做的东西面临这样的窘境，同样面临一些恶心的代码，保证自己能够按时的写出好的多的，那么起码在技术段有足够的理由和底气去重写。
猎奇
“历史告诉我们，程序员总是试图在第一个项目去使用新语言的所有新的特性”。
加班
游戏开发这个行业，最不缺乏的就是有热情，肯奋斗的人，想在竞争中保持强力，需要”有效加班“。
文中说了，加班之后会写出不少不好的代码。
嗯，是的，盲目的追求加班时间完全不可取，这个在应试教育的中国已经是”公理“了。
“有效加班”需要良好的时间和精力管理，保证自己在充足的体力和意志力的情况下，尽可能长的工作。
死局
这个是最恶心的一个情况，就是明明知道这样做的是错的，但是因为项目发布等等原因，只能如此。
里面提到一个技术决策就是这样，带来了海量的bug，但是项目快上了，只能认了。
那个没做过架构的lead programmer对此也应该负有责任。