不知不觉已经在公司上班一个月了，在这一个月里每一天发生的事情是我平凡而普通的生活。作为一名有节操的程序员，当我大学的同学开始称我为程序员的时候，我知道我即将在这条路上踏下一个属于开始的足迹。和我大学的同学相比，可能我会显得幸运而孤独吧！我不用像他们一样到各种工厂里采样、监测，可是与此同时我会因为离大家越来越远而感到孤独。每天下班做公交车回到住处，简单地料理着我一个人的生活，不紧不慢却永远是一个人在摸黑赶路，这是我自己选择的路，我从来不曾后悔，即使在这段时间和美术各种闹别扭，我相信这些都会是暂时的，以后总会变得越来越好。
第一份工作没有想象中的高大上，这是一个融合了 3D 漫游、Web 和电子商务的综合项目，可我想说我在努力地做好这件事情。当互联网+的概念被人们所熟知以后，传统行业和互联网的结合让人们对未来的生活充满了遐想，因为在这个过程中不断涌现出想要迫切进入互联网+时代的传统行业。可是当传统行业试图进入互联网行业的时候，我不知道传统行业经营者心中到底对互联网行业了解多少。我的第一份工作在家人的口中被演绎出了三个不同的版本，我想这就是传统行业对互联网行业认识的一种缩影吧，那就是传统行业并不了解互联网行业，当他们想要做互联网+的时候可能更多的是脑海中一闪而过的热情吧！
我的一位朋友告诉我，当你处在传统行业和互联网行业的十字路口的时候，你首先要虚心地了解和掌握传统行业的运作模式，然后再尝试将其和互联网结合起来。可是更为实际的情况是当这些传统行业的经营者有了进入互联网行业的想法以后，可能并不会从互联网的行业来看待这个想法，甚至片面的认为这个项目已然成竹在胸我们需要的仅仅是两三个懂技术的人就好了。这种想法其实是特别可怕的，以公司为例，从我进公司以来，公司从未对即将要做的项目进行过技术上的评估和立项讨论，公司的大部分美术甚至都不知道有这样一个项目存在、更不知道做好的模型要运用到一个怎样的技术上去以及最终会以什么样的方式呈现给用户。我所看到的情况就是公司里没日没夜的做模型。我想这就是领导脑袋一热的结果吧，大概知道要做一个什么样的东西，可是对具体怎么实施这个项目、实施这个项目需要哪些资源却没有详细的思考。我进公司这么长时间，基本没有看到过成文的策划或者是方案，更多的时候是大家在一块儿做，然后做的过程中发现有什么问题再返回去改，领导的态度从来没有准，觉得什么东西可以借鉴过来就要求程序和美术去实现，计划朝令夕改内心深处就不知道自己想做什么。我在公司从法律上来讲应该是一名普通员工，可是在很多时候我不得不担当项目管理者的角色。或许在这样的情况下，我可能会收获比普通员工更为丰富的除技术以外的经验，可是从长远发展的角度来看，只会让我内心更加厌倦目前的生活，希望早一天离开这家公司！
在一个没有策划的团队里，美术和程序就像水火不容的两股势力此消彼长。虽然说作为一名有节操的程序员，我的内心是拒绝让策划来领导程序的。因为在游戏网游化的今天，在国内基本是找不到多少对历史、人文、宗教等领域都有研究的策划的。在过去开发一款游戏，可能在游戏的世界观的构建上都需要花费很长的时间去研究相关的资料，可是在策划办公软件化的今天，策划关注的重点早已不再是游戏的世界观这些深层次的内容了，大家的关注点在什么地方呢？可能都在关注游戏的盈利和各种游戏系统数值的设计上吧，这一点我不想做太多的说明，因为大家都明白是怎么回事啦！好了，那么现在的问题是我们处在一个没有策划的团队里，如果程序按照美术的思路去做，可能程序会在修改了若干次项目以后对美术的要求失去信心，因为相对于程序解决问题而言，作为美术的普通人提出需求的难度显然更低。可是如果按程序的思路去做，可能美术不大会接受程序的审美，因为从我自己的角度来讲，程序更喜欢纯粹而简洁的东西、更看重能否解决问题，好不好看通常都是在考虑了这些问题后再去考虑的。
我进公司以后，基本经历了这样两种做事方式的洗礼，刚开始技术这边和我说了大概思路，然后我做出了第一个原型(1.0 版本),结果这个思路和公司的思路完全是两个东西，因此 1.0 版本就在这样被扼杀在襁褓中。接下来，美术提出了先做 UI,然后我们在等待她们做 UI 的过程中重新审视了这个项目，那段时间天天往隔壁办公室跑，搞得那个办公室里的妹子每次看到我进去都要抬起头看一下。每天跑来跑去做什么呢？答案是沟通，和领导沟通、和美术沟通，目的是在相互沟通的基础上加深对项目需求的理解。等到美术的 UI 做出来以后，我们就准备做 UI 了，结果做到一半的时候，领导说 UI 设计不合格，被打回去重新做，然后我们花了一周时间开会讨论，我从一开始没有资格参与公司会议变成了每次会议都要参加，我不知道这对我是好事还是坏事，说好事吧是因为我终于有发言权了，说坏事吧是因为经常和美术争得面红耳赤，总之每次开完会我都忍不住要吐槽下。
那么好了，各位看官，说到这里我无非是想告诉大家一个简单到不能再简单的道理：凡事预则立，不预则废。这就是说我们在做一件事情前一定要做好规划，游戏开发是一个特别考验团队合作的工作，如果在这个过程中我们没有在项目立项前做好充足的准备，就会很容易出现上面的问题。当我了解到仙剑项目立项就需要三个月的时候，我深深地感受到了这些传统行业经营者们的脑门一拍的决定是多么的不靠谱啊。在知乎上曾经看到过说"项目万事俱备，再差个程序员就好了"的类似言论，其实说这句话的往往就是这些自命不凡的传统行业经营者们，当你觉得一个项目仅仅需要若干个程序员就够了的时候，恰恰说明你还不够懂互联网行业！
我身边许多玩 LOL 的人都在吐槽打匹配的时候遇到的都是猪一样的队友，这种情况在项目开发中则更为常见。我不知道美术出身的领导怎么会认为程序员越多项目进度就越能赶上。做项目不是大家一块儿做模型，每个人分给几个然后用着破解版的 3DsMax 就搞定了。程序在我看来更应该在保证人员配备合理的基础上保证质量。
首先第一条，人员配备合理就是说程序员的数量要合理，其次大家的层次差别应该不会太大。因为人多了的话，对项目代码的影响可能更大，尤其是当大家编程的风格和技术水平存在差异的时候，体现在项目中就是各种未知的 Bug。为什么要求大家的层次差别不大呢，因为层次差别太大，首先团队内沟通就是问题，以我为例，我手下的两个人都是培训班培训出来的，基本上就是老师给一套视频然后照着视频做出一款游戏就结束了，我一直反感用视频的方式来学习游戏开发，因为你是在学习一个游戏引擎而不是在学习一个工具软件，虽然 Unity3D 提供了可视化编辑器，可是在我眼里它始终都是一个游戏引擎，而非一个类似 Office 或者是 3D 软件的东西。那么我想说的是什么呢？我想说的是不要把编程当作一种固定的套路，经常有人直接抄我博客里的代码直接运行项目，然后出了各种问题再来问我怎么回事？碰到这种情况我首先问的第一句话是你能不能明白这个代码是干什么的？如果对方不理解，我一般会先让它搞懂这些代码的意义。
我们公司里的美术都不愿意碰 Unity3D，因为他们觉得这个游戏引擎会增加他们学习软件的各种成本，可是事实是这个游戏引擎比我见过的 Max、Maya、Blender 等软件都简单啊，而且 Unity3D 免费版的就可以开发简单地游戏，比之美术口中各种不择手段的盗版、破解软件不知道要干净了多少？归根到底一句话，美术不愿意尝试新的东西，美术总认为 Max 里的模型导出到 Unity3D 后材质啊、灯光啊会丢，美术总认为 Max 渲染的效果要比 Unity3D 好许多，可是既然你选择了这个引擎来做项目，我觉得美术是有责任来了解这个引擎的，你让程序员帮你拼 UI 我可以接受，可是你让程序员帮你打灯光、修改材质、摆场景，这是程序员该做的事情嘛?我说虚幻四这样的引擎都是由策划来编辑关卡的，为什么你们美术就不能尝试了解下这个引擎呢？得到的答案是我们要做模型，显然当美术的眼睛只盯着手头的那几样工具软件的时候，你和他们间的差距已经拉开，如果有能力、有时间的话，不妨尝试下将编程以外的能力整合到自身的体系中，未来是属于全能型人才的！
我觉得像游戏这样负责的软件工程，在立项之初就应该明确美术、策划、程序各自的责任。我的想法是美术来制作素材、程序来编写相关逻辑和外部工具、策划使用外部工具来编辑关卡。
在我来公司前，曾看过一位前辈写过的关于这个项目的一个 Demo，当初这个 Demo 里只有两个场景，我最初是对这位前辈颇为敬重的，因为感觉这个 Demo 的表现还不错，甚至觉得如果能够得到这个前辈指点一二，实乃三生有幸啊。可是当我和这位前辈聊过以后以及看过他写的代码，我对他的敬重慢慢地变成了鄙夷。这是为什么呢？因为他向领导提议使用硬代码来编写项目，通过研究他写的项目，我发现他的项目确实使用硬代码写成的，你能想象在一个脚本中并列 7 个 if 仅仅是因为它们的 tag 不同嘛，你能想象在一个脚本中的命名都是汉语拼音的变量定义嘛。
抛开他写的项目不说，从规模和负责程度上目前这个项都比他的 Demo 有难度，首先我们大概需要制作 35 个场景涉及到上千种模型和贴图而非 Demo 中的两个场景，其次我们最终的发布平台是 Web 平台而非 Demo 中的 PC 平台。写硬代码意味着放弃复用和扩展性，顾及目前而不考虑以后。可是我们这个项目肯定是需要扩整规模的，难道每次添加一个新的场景都需要把代码重新写一遍，因此这个方案在和他交流的时候我当着他的面就给 Pass 了，然后他说我们先做个 Demo 看看，因为在前面我们已经积累了部分代码，所以在这部分代码的基础上我们迅速地完成了一个较为灵活的框架。整个框架是将模型单独打包后和贴图一起存放在服务器上，因为模型和贴图对不同的户型来说都是通用的，因为使用配置文件设计了一个类似数据库的结构，这样当我们在程序中需要某些模型和贴图的时候只需要下载就可以了，因为模型和贴图都被存放在服务器上，本地仅仅存放相关的户型模型和配置文件，因此项目的体积被大大地压缩，从而可以解决 Web 平台浏览器的压力，因为所有的场景都是使用配置文件来定义，因此当需要更新项目的时候，只需要更新服务器上的模型和贴图以及配置文件即可，提高了项目更新得速度。总体来讲，我对我设计的这个架构表示满意，因为它让硬代码的优越感荡然无存。同时为了减少人工编写配置文件、打包等过程的工作量，通过为 Unity3D 编写插件的方式实现了整个过程的半自动化。为什么是半自动化啊？因为人在做事情的时候没有统一、规范的习惯或者说难以统一和规范。我一直强调统一和规范，可是美术总认为程序的要求过于苛刻，可是事实上懂得编程的人都明白计算机程序不过是对某个过程的一种模拟，而且这个过程是有限状态的，因此当美术说需要 XXX 功能的时候，程序员的内心其实是拒绝的，因为为了这点需求，他可能需要写十几行重复的代码，为了满足用户的懒惰和弱智，领导让我们将户型内的物体尽量全部实现动态化，要给用户最大的自由，结果却是剥夺了程序员的自由写了若干个 if 或者是重复调用相同的方法，这简直是恶魔啊！
好了，写了这么多，大家可能觉得这不符合我作为一个有节操的程序员的风格，说好的每周一篇技术博客呢？其实技术运用的好坏，完全取决于运用技术的人，所以我们不能仅仅关注技术的高低，更要关注怎样让整个团队高效率、高沟通率的执行下去，因为千里之堤，毁于蚁穴啊，虽然团队间沟通这些东西看似都是些政治或者是形式的东西，可是实际上会占到整个项目开发中相当大的一部分，所以希望大家在看了今天的博客后能够有所启发吧，好了，睡觉，哈哈！今天居然写到了这个时候！
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。