首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 开发语言 > C++ >

这样的项目,是不是即将面临危机了?解决思路

2013-10-21 
这样的项目,是不是即将面临危机了?一个大的项目,现已经含有将近 80 个 c++ 模块(每个模块都是一个dll) 已

这样的项目,是不是即将面临危机了?
一个大的项目,现已经含有将近 80 个 c++ 模块(每个模块都是一个dll) 已经进行了将近2年了。
在我来这个公司之初,他们已经干了 1年了,那时候,无知者无畏的我,充满信心。 现在,渐渐觉得工作已经渐渐变得棘手和艰难。说说现在项目上的几个问题
1. 不重视项目构建。比如降低 c++ 头文件依赖关系,来加快编译速度。 如果我们要测试一个 bug是否存在,很多时候要浪费在编译整个项目上。 之前这个问题被提出过,但除了包括本人在内的几个新人,大部分人没有认真配合执行。
2. 责任划分混乱。 常常出现这样的情况,明明运行良好的模块,却因为别人在他自己的模块中修改了代码之后,导致你的模块出现运行时错误。问题是,这里所指的别人不是一个人,常常是多个人。 有时候出了问题根本不知道找谁,只好放着不管,也许下一个版本这个错误又不存在了。 这不是挺好吗,正说明这不是你的错。 但部门经理会 时不时来找你的茬儿,搞得好像你就是罪人,甚至问你这些模块究竟有没有被验证过!。
3. 查bug像打地鼠,没完没了。 项目越来越大,不稳定的底层中的问题渐渐浮出水面。 有一个bug我们查了两个月,最后发现是数据库引擎驱动的问题。 面对有些bug,我所能做的就是,不去管,因为我不敢动别人的代码。
许多bug 在被捕获了之后, 测试人员从来不给我们提供足够的信息如 错误码,堆栈之类的数据,导致bug 难以重现。 
4. 任务在时间空间上的分配严重不平衡。 有的人忙,有的人闲(我现在就是其中一个) , 闲的时候不少,一忙就要加班。 
5. 最大的问题是:每次开会结束之后,都是由部门经理拍板。几乎没人提出意见。就算年轻气盛的新人可能提出些问题,但不会被重视。所以,有些事情根本无法发起。 

工作 项目 c++ bug
[解决办法]
这样搞出来的软件能稳定运行表示怀疑
[解决办法]
的确 修改别人的程序是一种很痛苦的事情,
我也刚工作半年多,有很多事情不是自己的问题,你去问 很少把你当回事,无奈。。
[解决办法]
一个头两个大
[解决办法]
这程序也能用。。汗
[解决办法]
没有SVN??只有要版本管理软件, 就很明确责任了吧, 谁动了哪里都非常清楚.

建议你们软件弄一个版本管理.

再有, 你说的项目整个编译, 那是你自己要全部编译. 实际上你只需要编译你当前需要调试的模块工程即可.
[解决办法]
我也处于这样类似的环境 有时候真是很无语的
[解决办法]
这样的项目,项目经理的架构设计关乎整个项目的成败
[解决办法]
1小事。
2你们有天天运行的测试吗?
3测试的老板不在乎开发人员的反馈吗?
4开发老板(ry
5要具体情况具体分析。你光说个想法,不被重视是正常的。
[解决办法]
很正常,很多项目都是如此,要想避免有几条建议。

1, 分工明确,角色清晰,责任落实。
按模块或功能,把每个类落实责任人,可以写在注释上,一个项目内要设立某些非编程角色,
例如代码质量检查,配置管理等。各司其职。不留死角。

2,严明开发纪律,不越雷池一步。
按统一的开发规范进行开发,不允许项目内随便修改其他人负责的代码,及时发现问题,可
反馈有关人但绝对不允许任意修改非负责的代码。

3,加强内测,代码复核。
每一个类出安排一个负责人意外,还有一个复核人,负责审查代码是否符合规范,是否可看懂,符合功能和性能要求等,对代码进行内测。

4,对于bug要分门别类。
区分最严重,严重的和轻微的,一定时间得不到解决的bug,统一发送管理, 不断了解bug情况,分析产生bug原因。

5,加强内部沟通。
程序猿团队沟通很重要,靠每日例会或者阶段会,或者项目网站、即时消息等手段加强沟通,
集思广益,听取意见。不断改进沟通效果。

6,善用工具,
工具很重要,国际大型软件公司都有内部项目管理工具,用工具控制一些关键点,通过工具
的流程设置,把工作量化。

随便说上面几点,做好都不容易,但做不好就一定有LZ说的这些问题。
[解决办法]

引用:
一个大的项目,现已经含有将近 80 个 c++ 模块(每个模块都是一个dll) 已经进行了将近2年了。
在我来这个公司之初,他们已经干了 1年了,那时候,无知者无畏的我,充满信心。 现在,渐渐觉得工作已经渐渐变得棘手和艰难。说说现在项目上的几个问题
1. 不重视项目构建。比如降低 c++ 头文件依赖关系,来加快编译速度。 如果我们要测试一个 bug是否存在,很多时候要浪费在编译整个项目上。 之前这个问题被提出过,但除了包括本人在内的几个新人,大部分人没有认真配合执行。
2. 责任划分混乱。 常常出现这样的情况,明明运行良好的模块,却因为别人在他自己的模块中修改了代码之后,导致你的模块出现运行时错误。问题是,这里所指的别人不是一个人,常常是多个人。 有时候出了问题根本不知道找谁,只好放着不管,也许下一个版本这个错误又不存在了。 这不是挺好吗,正说明这不是你的错。 但部门经理会 时不时来找你的茬儿,搞得好像你就是罪人,甚至问你这些模块究竟有没有被验证过!。
3. 查bug像打地鼠,没完没了。 项目越来越大,不稳定的底层中的问题渐渐浮出水面。 有一个bug我们查了两个月,最后发现是数据库引擎驱动的问题。 面对有些bug,我所能做的就是,不去管,因为我不敢动别人的代码。
许多bug 在被捕获了之后, 测试人员从来不给我们提供足够的信息如 错误码,堆栈之类的数据,导致bug 难以重现。 
4. 任务在时间空间上的分配严重不平衡。 有的人忙,有的人闲(我现在就是其中一个) , 闲的时候不少,一忙就要加班。 
5. 最大的问题是:每次开会结束之后,都是由部门经理拍板。几乎没人提出意见。就算年轻气盛的新人可能提出些问题,但不会被重视。所以,有些事情根本无法发起。 


你的担忧是有道理的,综合上面提出的几个问题,这个项目存在以下管理不善的地方:

1、项目配置管理没做好;
2、项目管理计划没有得到有效执行;
3、项目的监控、绩效评审与变更控制问题很大;
4、沟通没做好。

以上几点都说明一个问题,项目经理能力不够,建议更换项目经理。
[解决办法]
1关系不大,
2没看懂,别人改他自己的模块,导致出了bug?先不追究责任,但是这种bug不是很好查么?怎么可能出问题不知道找谁?
3既然知道那里有bug,直接反馈上去就可以了,不能随便改别人的代码
至于45,基本正常
[解决办法]
不单单是项目本身的问题了,你的团队已经政治化了,真是相当危险!

引用:
一个大的项目,现已经含有将近 80 个 c++ 模块(每个模块都是一个dll) 已经进行了将近2年了。
在我来这个公司之初,他们已经干了 1年了,那时候,无知者无畏的我,充满信心。 现在,渐渐觉得工作已经渐渐变得棘手和艰难。说说现在项目上的几个问题
1. 不重视项目构建。比如降低 c++ 头文件依赖关系,来加快编译速度。 如果我们要测试一个 bug是否存在,很多时候要浪费在编译整个项目上。 之前这个问题被提出过,但除了包括本人在内的几个新人,大部分人没有认真配合执行。
2. 责任划分混乱。 常常出现这样的情况,明明运行良好的模块,却因为别人在他自己的模块中修改了代码之后,导致你的模块出现运行时错误。问题是,这里所指的别人不是一个人,常常是多个人。 有时候出了问题根本不知道找谁,只好放着不管,也许下一个版本这个错误又不存在了。 这不是挺好吗,正说明这不是你的错。 但部门经理会 时不时来找你的茬儿,搞得好像你就是罪人,甚至问你这些模块究竟有没有被验证过!。
3. 查bug像打地鼠,没完没了。 项目越来越大,不稳定的底层中的问题渐渐浮出水面。 有一个bug我们查了两个月,最后发现是数据库引擎驱动的问题。 面对有些bug,我所能做的就是,不去管,因为我不敢动别人的代码。
许多bug 在被捕获了之后, 测试人员从来不给我们提供足够的信息如 错误码,堆栈之类的数据,导致bug 难以重现。 
4. 任务在时间空间上的分配严重不平衡。 有的人忙,有的人闲(我现在就是其中一个) , 闲的时候不少,一忙就要加班。 
5. 最大的问题是:每次开会结束之后,都是由部门经理拍板。几乎没人提出意见。就算年轻气盛的新人可能提出些问题,但不会被重视。所以,有些事情根本无法发起。 

[解决办法]
在系统各层写详细的不能再详细的运行日志。
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#ifdef WIN32
    #include <windows.h>


    #include <io.h>
#else
    #include <unistd.h>
    #include <sys/time.h>
    #include <pthread.h>
    #define  CRITICAL_SECTION   pthread_mutex_t
    #define  _vsnprintf         vsnprintf
#endif
//Log{
#define MAXLOGSIZE 20000000
#define MAXLINSIZE 16000
#include <time.h>
#include <sys/timeb.h>
#include <stdarg.h>
char logfilename1[]="MyLog1.log";
char logfilename2[]="MyLog2.log";
static char logstr[MAXLINSIZE+1];
char datestr[16];
char timestr[16];
char mss[4];
CRITICAL_SECTION cs_log;
FILE *flog;
#ifdef WIN32
void Lock(CRITICAL_SECTION *l) {
    EnterCriticalSection(l);
}
void Unlock(CRITICAL_SECTION *l) {
    LeaveCriticalSection(l);
}
#else
void Lock(CRITICAL_SECTION *l) {
    pthread_mutex_lock(l);
}
void Unlock(CRITICAL_SECTION *l) {
    pthread_mutex_unlock(l);
}
#endif
void LogV(const char *pszFmt,va_list argp) {
    struct tm *now;
    struct timeb tb;

    if (NULL==pszFmt
[解决办法]
0==pszFmt[0]) return;
    _vsnprintf(logstr,MAXLINSIZE,pszFmt,argp);
    ftime(&tb);
    now=localtime(&tb.time);
    sprintf(datestr,"%04d-%02d-%02d",now->tm_year+1900,now->tm_mon+1,now->tm_mday);
    sprintf(timestr,"%02d:%02d:%02d",now->tm_hour     ,now->tm_min  ,now->tm_sec );
    sprintf(mss,"%03d",tb.millitm);
    printf("%s %s.%s %s",datestr,timestr,mss,logstr);
    flog=fopen(logfilename1,"a");
    if (NULL!=flog) {
        fprintf(flog,"%s %s.%s %s",datestr,timestr,mss,logstr);
        if (ftell(flog)>MAXLOGSIZE) {
            fclose(flog);
            if (rename(logfilename1,logfilename2)) {
                remove(logfilename2);
                rename(logfilename1,logfilename2);
            }
        } else {
            fclose(flog);
        }
    }
}
void Log(const char *pszFmt,...) {
    va_list argp;

    Lock(&cs_log);
    va_start(argp,pszFmt);
    LogV(pszFmt,argp);
    va_end(argp);
    Unlock(&cs_log);
}
//Log}
int main(int argc,char * argv[]) {
    int i;
#ifdef WIN32
    InitializeCriticalSection(&cs_log);
#else
    pthread_mutex_init(&cs_log,NULL);
#endif
    for (i=0;i<10000;i++) {
        Log("This is a Log %04d from FILE:%s LINE:%d\n",i, __FILE__, __LINE__);
    }
#ifdef WIN32
    DeleteCriticalSection(&cs_log);
#else
    pthread_mutex_destroy(&cs_log);
#endif
    return 0;
}
//1-78行添加到你带main的.c或.cpp的那个文件的最前面
//81-85行添加到你的main函数开头
//89-93行添加到你的main函数结束前
//在要写LOG的地方仿照第87行的写法写LOG到文件MyLog1.log中


[解决办法]
国情就是这样的,
你没法改变,
正确的做法都知道个1234,
就是做不好,
没用的.
[解决办法]
嘿嘿, 楼主不用想太多, 自己学学技术就得了, 这种事我这边也是这样哦, 几十G的代码, 人员更迭太快, 代码全是烂尾, 开发的主要工作就是修BUG.
[解决办法]
看来项目管理很重要啊
[解决办法]

[解决办法]
分dll的好处就是避免重编,如果你们所有这些dll的依赖关系没有搞明白,那还有必要搞这么多dll么?


如果对别人的代码不是很信任,调用时的输出,做严格校验,发现有问题,则将输入参数和输出都打日志,有日志说明问题。
目前很多时候问题难定位,日志写的不好是很大的原因。
[解决办法]
碰上不懂技术不懂业务的项目经理就更杯具了,淡定吧。
[解决办法]
路过  高深的问题  表示不懂呢  码奴
[解决办法]



不是没人管理执行,而是应该监督执行的人没有负起该负的责任。对执行进行监督和指导是团队管理层的任务。
[解决办法]
在这种模块划分较明确的项目里面,各个模块交互的接口一定要定义好,如果接口定义是明确的,完全可以使用模拟来验证自己模块的正确性,这样就能直接验证其他模块的问题并肯定地提出来,程序员都是靠事实说话的,事实摆在眼见通常都会立马找自己代码问题。

项目经理在这样多的模块开发情况下,如果不将职责划分清楚,不将接口定义(哪怕是找人定义)清楚,那就等着完蛋好了。
[解决办法]
看来是个宏大的项目。
[解决办法]
LZ是个有心人,说实话像LZ这样能发现问题,还能主动思考解决方案真的是难能可贵。
从你的描述上看,你的项目应该在技术和管理两个维度都存在问题。
1)在技术上,当前主要的问题集中在模块耦合严重、架构腐化、维测手段缺乏上。
2)在管理上,主要存在的问题是工作任务分配不合理、管理者风险管控能力比较欠缺,无法从技术的角度对产品的整体风险作出评估,并提出彻底的改进措施,同时团队缺乏平等的沟通环境,家长式管理。

大部分出问题的IT项目,归根到底都是因为管理上的问题造成,因此你们项目目前的问题,如果需要彻底解决,命门还是在于你们的PM身上,如果他这边不拿出解决方案,即使短时间内你们自己从技术角度做了重构和优化,长远还是会有问题。
因此,我的建议如下:
1)先从技术角度深入分析你们产品,按照我刚刚提到的技术上的这几个问题,提出可行的解决方案,记住,一定要是可行,不要跟他说要做架构重构,一定要是要说清楚怎么去重构。
2)找个轻松的时间,比如吃饭,午饭后散步时间等,反正不要在工作时间,诚恳的讲出你看到问题,并抛出你的解决方案,和他沟通,确定一个解决方案出来。

当然,如果你的PM仍然一意孤行,蛮横拒绝一切的沟通和交流,那么趁早离开吧。 
LZ是个有想法的人,我们团队这边正在招人,企业和待遇都还不错,如果有兴趣,可以私信我。
[解决办法]
这样的项目,是不是即将面临危机了?解决思路我做的项目,老板都是要我自己一个人完成。结果我啥也没学会
[解决办法]
很多时候,问题都是出在管理上

[解决办法]
楼主,果断把代码全要过来,你们别改,我来弄。。。。。。。。。。。这样的项目,是不是即将面临危机了?解决思路
[解决办法]
深表,同情。
[解决办法]
完全就是考验你们leader的软件架构设计功力,和你们新人关系不大。

热点排行