导师遭遇gigix——怒了

本文讨论了敏捷开发文化中关于包容与和谐的重要性,并针对技术与管理之间的冲突进行了分析。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

其实导师早就对作者的做法有了疑问
[quote] 看完整篇故事,总体上我赞成作者和 B 的作法,A 的工作态度有问题,不适合留在项目组里。

但我同时也看到了一种可能不太好的情绪,作者为什么连自己的上司 D 也讨厌?牛到不把自己的上司甚至老板都放在眼里,恐怕不是一个好苗头。


[quote] D 只是个经理,他不做技术性的工作,是无法了解下属的真实情况。这是一个典型的例子,不懂技术也不懂下属能力的经理会误判下属的真实情况。或多或少的蛮横安排资源,不接受团队回馈也是 D 所犯的错误。敏捷开发的一个重要手段是团队自我管理,也就是在阵地上的士兵比在指挥所的军官更了解战场战况,有时将在外,必须拥有“君命有所不受”的权利。上司 D 经常如此蛮横地瞎指挥,下属一般都以自己最好的判断来尽力实施他的要求,但是做不到的时候也只有和他汇报,获得他的理解,我想这是很多技术人员经常碰到的问题。[/quote]


软件研发的敏捷文化其实更强调一种包容与和谐的文化。敏捷并不是要把不参与技术工作的人,不能立马增值、兑现和提升生产率的东西,统统都看成自己的对立面和敌人。眼里只有“代码”,而没有“人”,我想这是很多一些技术人员经常容易犯的错误。

太极敏捷派掌门 张恂
www.zhangxun.com[/quote]
你看导师就是导师写的多好,不过gigix却不买账。[quote]
有扯淡的趋势,建议打住
> 软件研发的敏捷文化其实更强调一种包容与和谐的文化。敏捷并不是要把不参与技术工作的人,不能立马增值、兑现和提升生产率的东西,统统都看成自己的对立面和敌人。

不能立即兑现不等于没有未来的预期收益,消除浪费不等于不做远期投资。远期投资是否值得做,往简单了说,用财务技术就可以算出来。这都纯粹是技术活,别动不动的就扯什么文化的淡。首先把“把浪费看成对立面和敌人”曲解为“把不能立马兑现的东西统统看成对立面和敌人”,然后拿这个自己立起来的靶子来炮轰“很多一些技术人员”,最后说自己掌握了“包容与和谐的文化”,整就是一个扯淡的套路。打住吧。[/quote]
于是导师怒了,给了个链接,并且随后称小刀为凉粉(大概是说gigix得凉粉)。于是就此不在这个主题上发挥。而我却想,导师究竟是接受了gigix的建议了呢,还是觉得gigix太扯淡,没有必要在这里纠缠呢?总之最后的结果是打住了。

我这个人比较不喜欢议论人的是非,更不想在大庭广众下议论。比如非议作者其实就是看A下台了,还自以为是领导;看领导D居然能不顾及自己的想法,硬塞人进来。这些事情,显然都是人家公司里面的人事争端,背后的原因会很复杂,而且有些原因也是说不出口的。这样的家长里短,我是不想公开参与。
不过到底是导师,居然说敏捷开发的文化如何如何,因此这些事情马上就可以堂而皇之的放在台面上谈了。导师很认真的教育我们,敏捷文化强调包容与和谐,你看和我们党的政策多靠拢,谁敢再否认敏捷一个试试。
而进一步到时语重心长的说:“敏捷并不是要把不参与技术工作的人,不能立马增值、兑现和提升生产率的东西,统统都看成自己的对立面和敌人。眼里只有“代码”,而没有“人”,我想这是很多一些技术人员经常容易犯的错误。”所谓要团结,要包容,要和谐。
可惜gigix这斯就是不买帐,居然认为估算是否可以增值,是否值得投资是个财务计算的活,是个技术活。这还了得,敏捷文化就这么容易的被gigix三下两下给否定了。联股市上都说,技术分析在中国行不通,要听消息,要看报纸,要找内部渠道。gigix这斯居然敢否认敏捷文化,太不和谐了。
不过似乎作者强调的是,造成进度停滞的应该被清除,而没有说别的啊。显然这里我们不能不佩服导师已经十分擅长使用读心术,能够秀才不出门便知天下事,能够一叶知秋,看出作者就是在只认识“代码”,不知道“人”。你看导师多伟大,你说出来的他知道,你不说出来的他也知道。我想以导师这个方法,自然能很简单的理解敏捷的前因后果,能知道最初创建敏捷方法的人的目的。厉害呀,厉害。
一个小gigix怎么敢跳出来和导师叫板呢?gigix有这个能力知道别人没有说的吗?他熊杰是啥东西,才有3年编程经验,导师都有14年了啊。你看你看,水平就是这么体现的。导师怎么能不怒呢?
### 自动生成单元测试用例的工具和方法 在软件开发中,单元测试是确保代码质量的重要环节。为了提高效率并减少手动编写测试的工作量,可以使用一些自动化工具来生成单元测试用例。以下是几种常见的工具及其特点: #### 1. testMe 插件 testMe 是一款用于自动生成单元测试用例的插件,特别适用于需要快速提升单元测试覆盖率的场景[^3]。它能够分析现有代码结构,并根据代码逻辑生成基础的单元测试用例。对于历史项目或未添加单元测试的代码,testMe 提供了一种高效的解决方案。 #### 2. Diffblue Cover Diffblue Cover 是一种基于人工智能的单元测试生成工具,支持 Java 和 C# 等语言[^4]。它通过分析代码的功能和逻辑,自动生成高质量的单元测试用例。虽然 Diffblue Cover 并未在引用中提及,但它在市场上广受好评,尤其是在处理复杂代码逻辑时表现突出。 #### 3. SquareTest SquareTest 是另一款用于生成单元测试用例的工具。与 testMe 类似,SquareTest 可以帮助开发者快速生成测试代码,但它的主要优势在于对 Android 应用的支持[^5]。如果项目涉及 Android 开发,SquareTest 可能是一个更好的选择。 #### 4. Fluorida Fluorida 是由 gigix 和 dreamhead 开发的一款针对 Flex/Flash 的单元测试工具[^1]。尽管它的应用场景较为特定,但对于需要测试 Flex/Flash 程序的开发者来说,Fluorida 提供了简单易用的 DSL 来实现自动化的功能测试。 #### 5. JUnit 和 xUnit 框架 JUnit 是一个经典的单元测试框架,广泛应用于 Java 开发中[^2]。虽然 JUnit 本身不提供自动化的测试用例生成功能,但它为开发者提供了强大的断言和测试组织能力。结合其他自动化工具(如 testMe 或 Diffblue),JUnit 可以成为构建完整测试体系的基础。 #### 示例代码:使用 testMe 自动生成单元测试 以下是一个简单的示例,展示如何使用 testMe 插件生成单元测试用例: ```java public class Calculator { public int add(int a, int b) { return a + b; } } ``` 运行 testMe 插件后,生成的单元测试代码可能如下所示: ```java import org.junit.Test; import static org.junit.Assert.*; public class CalculatorTest { @Test public void testAdd() { Calculator calculator = new Calculator(); assertEquals(5, calculator.add(2, 3)); } } ``` ### 注意事项 - 自动化工具生成的单元测试用例通常仅覆盖基本逻辑,可能无法完全满足复杂业务需求。 - 对于高覆盖率要求的项目,建议结合手动测试优化生成的用例。 - 在选择工具时,需考虑项目的编程语言、框架和技术栈。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值