项目成功了，会是什么样子？ （不爽放分贴）
写这篇文章，带有很明显的情绪。
我的头儿人还行，博士一个。说话时说着说着就不知道说什么了，属于那种跳跃式思维，我现在负责这个项目的界面，用MFC(VS2005)。
开发中的几个例子：
需求：
程序需要在场景中播放视频，场景由许多小的贴图构成，每个小贴图上可以播放不确定个数的视频文件，不同小贴图上的视频文件可以被播放、停止、暂停等，如果小贴图有多个视频文件时，播完第一个则顺序播放下一个。播放在同时需要将视频文件的数据（从一个独立的解码线程中获得）发送到主窗口以便实时渲染。
鼠标点到那个小贴图时，如果该小贴图上已经有视频文件，则需要在一个特定的对话框中显示出来，没有则在对话框中显示为空。当然视频是被拖拉到对话框中的，也就是说必须根据选择的小贴图来维护视频文件的状态。有，或者没有，以及个数，显示等。在对话框中播放了视频后，
实现：
我思考了1个多小时，决定采用“树”来描述这种结构。从设计到编码用了6个多小时，后来我将我写好的两个类，拷贝到服务器上，做了简单的修改，已经达到了要求，即使一次性同时播放10几个视频文件也不会出现卡的情况。
头儿：
我的头儿有个毛病，只要程序有点BUG，他只会说：管理的不好。
后来他看了一下我的那个类文件（注意是文件，不是类的内容），就说（因为有点长，共两个CPP文件，每个也就500多行，由于其中用到了CArray模板类，所以看起来有点乱），写的太复杂了，有这么复杂么。你会不会编程。
他的改进：
在我的思想基础上，把我的线程同步完完全全拿了过去（我在这个上面花费的调试时间较多），改成了一个小贴图仅支持一个视频文件（好处就是用了一个引用计数方法）多加了五六个视频状态变量，以后测试经常不正常的类。
其实他让我改进也可以，不过我最不喜欢他说：你会不会编程。
看过《火影》的都知道：李的那种：燃烧的青春。
在这个项目之前，我曾规划了一个整个项目用的的对象的构成，派生，虚函数，基类设计已经成竹在胸，结果没这样做，后果就是项目已经做了一半多了，他才发觉那样不合理，没办法，大改，改了我设想的那样，我的同事抱怨说这会改很多，他说；你有没有编过程，这还叫改的多。我无语。这样的大改几乎一周多一次，原因很简单：燃烧的青春。他做事情时不多大考虑，或许是没时间的原因，一般是想到了什么功能，就要大家马上添加这项功能，说实话，我第一次呆这样的单位。
C++的效率：
他常说：看我写的效率多高。
Class C3DPoint
{
Public:
C3DPoint();
C3DPoint( float x, float y, float z, float w );
Void SetXYZ(float x, float y, float z)
Void SetAll(float x, float y, float z, float w)
};
程序中经常在一个类中包含该类的实例，m_c3DPoint;
他时常这样赋值
m_c3DPoint = C3DPoint( x, y, z, w )；
这能比
m_c3DPoint.SetXYZ(x,y,z)更有效？
动不动就说，你封装的不好，你要学会虚函数，重载。
我有这么菜？
说实话，我真不想说话。
项目成功了，会是什么样子？连续加班两个多月了，项目如果完成了，我也累了。
他人还不错，就是做事。
[解决办法]
可能是每个人的编程思路不一样，他看你的程序时，并不知道你是怎样构思的，就会觉得你写的程序有点乱。
[解决办法]
忍忍吧，厚积薄发
[解决办法]
连续加班两个多月，光凭这个就是不正常的。
[解决办法]
你头是自信的表现，不免会去点错，在这过程中，都没见你顶过，搞不懂
[解决办法]
在这过程中，都没见你顶过，搞不懂
[解决办法]
自己也总结总结，代码要写好，注释也要写好。还有代码排版。这样，别人看你的代码就回赏心悦目了。
[解决办法]
代码没有什么注释
[解决办法]
代码要写好，注释也要写好。注释比代码多也不怕.....还有代码排版。
[解决办法]
楼主你管理得不好啊。你会不会编程。
嘿嘿
[解决办法]
/* */
[解决办法]
呵呵~忍一时，风平浪静；退一步，海阔天空。
[解决办法]
几度声低语软，
道是寒轻夜犹浅；
早些归去早些眠，
宁静以致远
[解决办法]
呵呵，理解楼主，和你差不多的经历。
不过，技术还没你好。
[解决办法]
忍
[解决办法]
那就等有机会自己负责一个项目呗，就可以把自己的抱负和想法实现了。
[解决办法]
呵呵，有次我和头，争辩一个技术问题。
头最后一句是：“告诉你这么做，你就这么做，明白没？”
我的最后一句：“明白了。”
[解决办法]
呵呵我觉得这个头儿有问题啊，具体的说就是”管理的不好“，微观管理，最后不是他累死了，就是手底下人都跑了，或者两者皆有。做管理最重要的是让手底下的人变强。
找个机会和他沟通沟通，比如中午出去一起吃个饭，告诉他给些大方向的反馈就可以了，其他的给你些自主权。这样你才能进步。他要是不听，你赶紧令谋高就，要不早晚和他一起掉沟里。
[解决办法]
先忍,以此激发自己,并提高自己
[解决办法]
找个机会和他沟通沟通，比如中午出去一起吃个饭，告诉他给些大方向的反馈就可以了，其他的给你些自主权。这样你才能进步。他要是不听，你赶紧令谋高就，要不早晚和他一起掉沟里。
[解决办法]
大胆的说出自己的想法，说不定哪天你会成为他的头儿！
[解决办法]
对于一些无关紧要的风格问题，可以迁就下。但原则问题上，该多找机会和他讨论。
[解决办法]
哎，，忍忍就好， 个人看了你代码和他的，，个人感觉肯定是偏向你。。
1。
另外说怎样什么效率之类的， 这样的问题实在是累人，偶尔知道下，平常用用就可以了。简单几句的代码效率是并不值得研究的。 大家都知道聪明的编译器都帮我们实现大多数的这样的优化。比如c*2 写成c <2 要求 这样编程 的人这个属于自以为是的人，能左右移的VC肯定会帮你实现。不需要你来。
2。500行还好。。有时候只不过是浪费型缩进风格 的原因，更何况这是大多数人喜爱的风格，个人比较讨厌 吝啬空白的代码风格。。 看不清。
3。如果他是个能说话的人 就好好和他说说吧，，也许是他小看除他以外的人 了。。。
做一两件 让他理解你能力的事情吧。。
[解决办法]
楼主技术不错！
[解决办法]
你们头的代码一塌糊涂，我欣赏你的编程风格
[解决办法]
呵呵我觉得这个头儿有问题啊，具体的说就是”管理的不好“，微观管理，最后不是他累死了，就是手底下人都跑了，或者两者皆有。做管理最重要的是让手底下的人变强。
找个机会和他沟通沟通，比如中午出去一起吃个饭，告诉他给些大方向的反馈就可以了，其他的给你些自主权。这样你才能进步。他要是不听，你赶紧令谋高就，要不早晚和他一起掉沟里
---------------
up
[解决办法]
人家毕竟博士，看问题的角度可能和一般人不一样吧，你尝试着跟他学学，应该会有收获、
[解决办法]
感觉头儿的代码是要舒服点，因为短。至于注释，先不说了。
例如你的：
CArray < CKeyFrameData*, CKeyFrameData* > m_arrFrameData;
这样的代码出现很多次，看起来是很不舒服
这样不久很简洁了？
typedef CArray < CKeyFrameData*, CKeyFrameData* > KeyFrameArray;
KeyFrameArray m_arrFrameData;
KeyFrameArray x;
KeyFrameArray y;
KeyFrameArray z;
[解决办法]
哈哈，风格问题
[解决办法]
我头也一样...哎...完全个人主义,不合他意思,完全照他的来改..关键是他也不咱滴...
哎..最主要的是他脾气不好,我建议一下,他就大声语气,骂得我狗血喷头...
