依赖是否可以作为一个独立的衡量软件质量的标准？

感情上理解这种心情，但是在实际中，我不否定这种方式，甚至偏向于使用这种方式。毕竟，“做系统”和“种田”是有本质上不同的，“大跃进”也没有什么不可以。

减少依赖是一个很好的原则，只要是用来减少我对别人的依赖，而不是别人的我的依赖：）

其实无论是减少依赖，还是DRY，都是有目的的，减少依赖的目的是增加环境变化的适应性，降低维护负担，DRY是减少出现缺陷的可能性，降低开发负担。当然，它们同时还有一些次要的作用。

如果我们对环境不变充满信心，可以不需要减少依赖，如果我们对程序员大脑充满信心，我们可以不坚持DRY。

看起来你们的差异就是立场不同而已。

减少依赖是一个很好的原则，只要是用来减少我对别人的依赖，而不是别人的我的依赖：）

其实无论是减少依赖，还是DRY，都是有目的的，减少依赖的目的是增加环境变化的适应性，降低维护负担，DRY是减少出现缺陷的可能性，降低开发负担。当然，它们同时还有一些次要的作用。

如果我们对环境不变充满信心，可以不需要减少依赖，如果我们对程序员大脑充满信心，我们可以不坚持DRY。

看起来你们的差异就是立场不同而已。

这几个帖子是集中在一段我的低潮期发的。我当时的最大问题还是和人交往经验不足，始终不知道是不是自己做的不够，还是对方太过分。也不想和别的同事沟通，毕竟人家是在公司干了十年的元老，如果我出去和别人讲我们分歧很大，很有可能是自找没趣。和lp商量，也被指责和人要搞好关系，不要出妖蛾子。所以极度郁闷了好一阵。

后来，终于忍无可忍，一拍两散。然后不再顾忌重重，和老板，同事交流后才发现，此人不仅仅是和我这样，他的权利欲，支配欲和固执，over-defensive居然是公司里面众所周知的（他和大老板，和比他高的头争执起来一样让人头疼，而且又特别能说，不过因为毕竟都是为了工作，老板人也比较好，不愿意摆出老板架子来压人，而且公司的那一摊也还离不开他，所以就一直这么下来了。），只不过大家都比较容忍，也不会象我这样在架构上和他有冲突，他怎么说就怎么做就是了。

anyway，离开了也不赖，毕竟合作这么困难总之是不爽。

做技术的人员，应该多多学习与他人沟通交流，有时最先进的技术并不能在项目里得到应用，为什么？因为从项目最终的结果来看，使用先进技术也许并没有带来多少好处。商业公司不是科研机构，讲究务实。老板可能一点技术也不懂，他只关心这个项目是否可以按时保质的完成。

对于你注入properties值和使用那个内部框架PropertyXXX的争论，我觉得这个要看properties值的是否会发生变化。

如果这个值在系统运行期间不需要变动，注入显然是最好的；不过如果这个配置需要动态调整，好比可以让管理员在系统后台配置，每次读取的时候给propertiesXXX框架要就更加有优势了。

而且property框架可以更容易扩展，例如把配置信息集中存储到数据库中等等，如果有这种需求，注入就不能满足需求了。我们就因为这种情况而开发了一个提供property的框架。

即使值要变动，也可以注入的。不要忘了，java.util.Map只是一个接口而已，真需要用一个超强的property框架，随手写一个adapter好了。注射的好处就在于保持简单，但是又不牺牲灵活性。

property框架容易扩展？误解呀误解，我看它反而是累赘，臃肿。

离开公司了。没办法，不合则去吧。

离开公司了。没办法，不合则去吧。

呵呵 我没实践过敏捷，不过从ajoo兄的经历来看，敏捷对员工的“EQ”要求也是蛮高的，如果buddy是一个很独裁的人，敏捷在某种程度上会伤害组织。