Yuan Yijun (bbbush) wrote,
Yuan Yijun
bbbush

  • Mood:
  • Music:

太被动了

组里面十个程序员,有大半反对我写代码时候使用 namespace。这些不可救药的 c++ 程序员!
于是把我的那些文件统统修改一遍,一共是几十个。项目里本来就没有多少文件,于是全部检出,时间间隔 2hrs。
还有挑出来的毛病是使用 std::string。应该统一到 CString。平心而论,CString 直接导出 buffer 的做法很让人喜欢,因为 MFC 整个就是为了方便而设计的,没有数据隐藏,所谓 C 开头的其实都是 struct。这样的 MFC 让 BS 去用,肯定是无法接受的,要是让 OOSC 的作者去用,恐怕他连砸烂机器的心思都有。但是我的代码里 CString 和 string 都太多了。说起维护,我想我从上手编程序到现在也不过这样几天,照样很习惯,他们凭什么不能花几天来适应 namespace 的用法?。。。。
其实有问题的代码都出现在比较新的结构里,但是不能排斥成这个样子啊
要是不允许用 std::vector 的话,我还是去死好了
还有 #define Unicode 还是 #define MBCS,现在要求必须把所有的 L"" 统统变成 _T(""),那样还是不如杀了我吧,痛快一点。要多打多少字符呢。。。。
还有 include 的修改,本来有个 includes 目录(拼写错误!),大家把头文件扔进去,一样互不干涉,并且自己的代码可以干净一点。可是新的规矩出来,不允许设置项目属性。。。。这样的话怎么办才好,把头文件和源代码混起来实在是麻烦死了。项目属性是做什么用的!
最后是 XML 的接口。大家都用着 xiang 的那一份,但是我觉得并不好用,也许是我用错了?xml 里面有那么多内容,而大腕他们的封装也不错,为什么不考虑直接用他们的呢,何必将来重写呢。并且 xiang 的接口必须同时用到 doc 和 node,就算是 CppSQLite3.cpp 也提供了 stmt->execDML 和 stmt->execQuery,真是别扭死了。
数据部分就是被动地接受请求,返回数据。
这程序写得也太被动了。
我提了一万次的意见,自动生成文档和分析的时候可以方便些。但是最后的响应,是“我们的程序直到生命期结束都不会有文档,也不会有人去看文档。直接看目录划分就可以了”。我提目录和文件内部的 namespace 逻辑关系应该一致,像 java 一样,没人用 class view。大家都只操作文件。
还有第三方库的头文件以及库文件位置。一个 linux 那么大的系统都可以有 FHS,为什么我必须把 sqlite3.lib 和 CppSQLite3.cpp 放在自己的工程下面?
好多问题,我想如果我忍耐下去,我会什么都学不到。这里连 cppunit 也少有人知,eclipse 也不了解,我还能从这里学到什么?学习 COM 和 MSMQ 吗?MFC?
这里也没有 Apache 只有 IIS,ActiveX,没有 OOo 只有 word, ppt, xsd, 这里的 ms exchange 经常出故障。
我想去 AWS 组,应该比这里忙一些吧
保川师傅接着我的两小时窗口之后,全部检出。他的习惯比我还差,他喜欢全部检出,然后在 commander 里面移动文件,我总是担心他做这种对文件的操作时候,脑子里有没有在想逻辑关系,也许翔哥说得对,只是因为我们的习惯不一样,我和大家的编码习惯有点不一样,处理习惯有点不一样。。。。在他检出之后,他的机器再次死机了。我想这段时间我既然完全没有办法做事情,不如在这里关税,顺便抱怨一下。
FHS, HIG, 好怀念 linux 中的种种标准。一切皆为标准,世界就会清静许多。std::string 和 std::stringstream 真差。
我快要爱死 cppunit 用 doxygen 生成的文档了。就连 eclipse-cdt 的函数模版也要照顾 doxygen 的面子。我们并不是总是通过看代码来学习的。我有什么办法?
没有 namespace 的时候,私有类和全局类,每个模块的类按照字母顺序排列,一锅粥。一个小程序,用到三种第三方库,包含五六个模块的时候,类的数量已经增长到了两百。对话框可以用 CDlg 这种前缀,看起来好像很整齐,可是我们各种各样的对象。。。。


update20060320
现在在 vss 里面工作有了习惯,本地修改不检出,检出时不覆盖,提交前先做 diff

和以前的想法一样,尽可能减小排他修改的窗口

好吧,也可以说,是忍气吞声地看着别人检出、排他修改,然后自己去做合并。自己吃亏一点,对于整个团队有好处。但是,如果这样做并没有得到他人理解,反而被嘲笑是不懂规矩的傻瓜,那就是进入了纳什均衡的...窝囊的状态。郁闷!
Tags: 噩梦, 软件工程, 项目
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 2 comments