【此篇文章是由自动发信系统所张贴】

发信人: wuzhiqiu1 (疯狂555), 信区: CPlusPlus
标  题: 请教两个小问题（及吐槽）
发信站: 水木社区 (Tue Apr  7 00:28:58 2026), 站内

问题1：

在依赖QT的C/S项目中（同一个pro下），c端和s端的不同类中定义了相同的结构体定义，用于C/S传输和解析socket数据。我review时，认为此法不妥，应该唯一定义，以此理由要求同事修改是否妥当？


问题2：
如何使用jira工具做好项目工作管理？

我简单说一下我当前面临的情况，团队之前在jira记录主要功能需求和问题记录，会预设完成时间，但非强制，根据实际完成情况提前结束或延期。
最近，leader要求团队成员必须围绕jira的任务管理功能展开项目工作，同时固话角色分工和责任，以后季度绩效考评就看每个人完成和剩余的任务数量，用量化数据明确考核标准。
对此，我持怀疑态度和抵触情绪，原因如下：

1.任务的时间分配不均衡。如果要求完成和剩余任务数量作为考核标准，则前提条件是不同开发人员开发任务涵盖的工作量应该大致相同，否则无法得出相对公平的评价。但是，实际工作中很难实现，因为不同人员维护的功能模块不同，开发需求不同，所以不同任务的工作量往往不一样，小任务一天可以完成好几个，一般任务需要1-3天，偶尔会有一些难改的问题超过一周，但由于任务整体性强很难继续拆分，且存在工作估计不准确的情况，所以很难保证所有任务的工作量相等；

2.任务记录跟随效果不充分。jira可以记录预先计划的任务，但是对于突发问题，往往只能事后补齐，但是现阶段工作中插队需求和线上突发问题常常发生，所以这部分工作量不小。

3.加剧了工作中的机械化。如果只为jira任务论，我担心开发人员发现不在jira上记录的程序问题时会比以前更倾向于忽视该问题，而将时间花费于jira中的任务，哪怕被忽视的问题可能更严重。

4.评价维度单一。我认为这是机械的评价他人工作成果，反而应该从代码质量、解决共性问题的贡献程度、任务的难度和数量等多维度考量，并且工作成果是依靠自驱力的，这种机械式的量化方法看似公平，但仅是局部公平，可能会伤害团队成员主动性。（还有一个原因，我不想投入更多时间在记录别人任务上，有更需要我做的事情）
--
修改:wuzhiqiu1 FROM 1.202.113.*
FROM 1.202.113.*