预见项目失败

1、没有版本控制机制，各人分头写代码，再copy给一个人去合并。这是最原始的个人式编程方式，怎么还能在这种团队型的中型项目中这样子做呢？要是变更比较频繁，如何控制合并中出现差错的几率？并且还很费力。（某人原来放过话，一天哪有那么多版本？以后一天只给合一次。要想有新版本，你等明天吧）

2、没有使用代码管理工具。虽然工具只是工具，但是如果使用cvs/svn这样的版本集中控制工具，会大大减少人工代码合并的工作量，并且会强迫开发人员在写代码时注意大局观，模块的独立性，自己的改动是明确的，有史可查，并且可回滚的。再加上自动编译，随时都可以checkout代码出新版本做测试。用得着你费老鼻子劲去人工合吗？

3、没有使用名字空间，解决多个人命令冲突的办法是：改名！做了6 、7的C＋＋程序员了，说白了只停留在一个熟练代码堆砌工人的水平上。操O。你和他去说，居然僵着说那些名字一下子就替换完了。他有没有脑子啊，改一次很快，版本一天变动个5次，你还会改得很快吗？不会出错吗？这些简单的道理，他就是不去想。

4、 数据库的命名规则还没有统一。由于是Oracle/Linux环境，大小写敏感，数据库名／字段名／SQL语句中的命令，是全大写，还是全小写，已经吵了几次了。程序经理太软了，这点小事都搞不定，一个手下的牛B程序员就是不听非要全小写。解决办法是什么？程序经理自己费点事把数据库接口改了一下，自动把传入的Sql语句全变成大写。你说这叫什么事儿？

5、文件名大小写也是没定下来。linux对文件名分大小写，有些代码里面写了错误的文件名。说了几次了，让程序员在写代码的时候注意点，文件名全部改小写了。 牛B程序员又说了，这点小事，在合代码的时候“替换”一下不就行了，不用定得那么死。

6、这个项目是在分公司已有的成熟框架上开发，所依据的编程风格／接口类型与自个儿的格格不入。一个字，改！看着不爽的，不合老农习惯的，改。大爷啊，只有两个月时间啊，不是两年也！

7、 数据库的连接配置写死了，这样做的前提是数据库与apache装在同一台机子上。老大，有没有过过脑子？如果不在一台机子上呢？为什么不用配置文件呢？半个月的php/asp程序员都知道啊。

8、apache的附加模块代码没有写configure，只有make，你就怎么就知道别人装的是GCC4.03，你怎么就知道别人一定有gnulib？不用编译我都知道你的代码换到别人的机子上就是死路一条。别人的服务器环境，有时不是我们想动就能动的。我知道你想说什么，不就是想给它装个最新的GCC吗？让你装也行，没有联到外网怎么办？没有光驱怎么办？

不想说了，问题还有。都不是挑得上筷子的问题，是根本不重视，不愿意去解决的问题。却还在那里装着个6/7年C/C++经验的牛B程序员样！

项目的成功有很多定义，但再怎么定义，这个项目一定不会是个成功的项目。注定是个泥沼，在一堆无谓的低级低级错误里面挣扎。

看来这堆人要在同一类问题上陷入同一个泥沼两次了。上次陷了5年。