项目中的抱怨
做过项目的工友应该都听过程序员在项目中的抱怨，其实这是一种信号，表明项目出问题了，需要解决， 下面列举一下小弟经历的项目抱怨：
1.一个子包项目，global的team， 异地开发， 我们只负责开发其中一个子project，这个子项目的特点就是依赖于其他的部分太多，包括前台的CSS后台的某些service需要从别的数据库里取东西， 开发采用横向分工，domain层和前台分别有人负责。J2EE开发。
抱怨一（QA）： 妈了个逼得，我每次都要把系统打包发布到远程的测试环境才能测试完整的系统，本地根本跑不起来，网络还老是断， 每天都加班到这么晚....., 我说，XXX， 你那个功能在本地自己测试了吗就让我测，回去改去......
抱怨二（dev）：XXX， 你那后台的classs abc的那个方法跑哪里去了？我这里编译都不过，
XXX 说： 哦，我换了一个方法的名字......
抱怨三（dev）：他那个功能我接不了手， 我不知道他具体怎么做的，一堆破代码，太乱了，你找别人接手吧。
抱怨四（dev）：哎呀， 娘的，我刚造的测试数据跑哪里去了，谁给我删了？（dev用一个数据库作为开发数据库）
从这三点看，这个项目出了很大问题，
对于抱怨一， 没有本地的可测试的环境，造成测试->发现bug->修改bug的周期变长。 就算依赖的外部服务多，也可以做一个模拟的提供服务的程序，让系统在本地访问假的外部系统，可已通过平配置spring两个配置文件，不同的环境采用不同的配置文件，在deploy的时候，通过ant选择不同的配置文件。
dev本地测试不够充分，结果造成QA测试失败让dev从做，增加没有必要的测试往复。
所以dev要在本地做好单元测试和selenium测试（如果要由dev来做）。
对于抱怨二， 我认为，一个team理想的size应该10人以下，如果是这个size 的话，分工应该是纵向分工，一个人从view层一直做到DAO层，这样dev之间的dependency应该是最小的。 而且对于一个10人的team，就算domain由不同的人来修改，一般也不会出现乱掉的情况，因为交流方便嘛。
对于抱怨三： 要想避免这种情况，至少保证2个人熟悉同一个功能，agile的做法是pair，通过quick shift，理想的情况下大家知道的东西都是差不多了。
对于抱怨四， dev用共享的数据库进行开发，不好的地方就是测试数据互相干扰。既然
这样，每个人都搞一个本地数据库好了，其实这牵扯到数据库migration script的管理问题，这个先不说了。
2.也是一个J2ee项目，开发团队总共50人吧，基本上10人一个小team，负责一个子project，我们project用敏捷，TDD，CI都用。
抱怨声一，“他妈的～，我们依赖的一个project 的一个class的方法变了，我编译都通不过了.......
实际上随着这母规模的扩大，开发人员之间的协作会出现越来越多的问题，抱怨的很多，但是我只列举了一个有讨论价值的抱怨。
这个问题的出现，就是由于2个team之间有依赖关系，而且team之间远远没有team内部沟通快捷。如果一个team修改了底层代码，上层代码不是他们做的，而且系统规模比较大，也不可能把别的team代码进行修改。这时应该怎么办呢？
如果不管其他的team，强行提交代码，那么SVN上的code就是一个不能运行的版本，这样会因发其他的很多问题，比如QA的测试无法进行。因为一般的QA都是通过操作系统来造数据，然后进行测试，如果造数据功能被block掉，那么测试没办法进行。
所以首先第一个要保证的就是svn上一定是一个可运行的版本。
那么如果保证修改了底层代码，仍然保证其他team的code可以正常运行呢？
我的一个想法，底层team的代码可以以jar的形式提供，jar有版本号，如果做了修改，就commit一个新版本的jar，然后邮件通知其他的team要及时进行jar的更新，其他的team可以等合适的时候进行jar的调整。
如果修改了数据库怎么办？要知道继承测试环境用的是一个数据库，数据库不能像jar包一样分出版本号。新的jar包发布以后，如果数据库有修改，并且新旧jar对数据库的处理不同，那么持续继承的结果在一段时间内仍然是失败的。
大家讨论一下吧，欢迎拍砖啊～ 
顶你!哈哈哈哈哈哈哈
这个是最好用的。
抱怨一（QA）： 妈了个逼得，我每次都要把系统打包发布到远程的测试环境才能测试完整的系统，本地根本跑不起来，网络还老是断， 每天都加班到这么晚....., 我说，XXX， 你那个功能在本地自己测试了吗就让我测，回去改去......
抱怨二（dev）：XXX， 你那后台的classs abc的那个方法跑哪里去了？我这里编译都不过，
XXX 说： 哦，我换了一个方法的名字......
抱怨三（dev）：他那个功能我接不了手， 我不知道他具体怎么做的，一堆破代码，太乱了，你找别人接手吧。
抱怨四（dev）：哎呀， 娘的，我刚造的测试数据跑哪里去了，谁给我删了？（dev用一个数据库作为开发数据库）
从这三点看，这个项目出了很大问题，
对于抱怨一， 没有本地的可测试的环境，造成测试->发现bug->修改bug的周期变长。 就算依赖的外部服务多，也可以做一个模拟的提供服务的程序，让系统在本地访问假的外部系统，可已通过平配置spring两个配置文件，不同的环境采用不同的配置文件，在deploy的时候，通过ant选择不同的配置文件。
dev本地测试不够充分，结果造成QA测试失败让dev从做，增加没有必要的测试往复。
所以dev要在本地做好单元测试和selenium测试（如果要由dev来做）。
对于抱怨二， 我认为，一个team理想的size应该10人以下，如果是这个size 的话，分工应该是纵向分工，一个人从view层一直做到DAO层，这样dev之间的dependency应该是最小的。 而且对于一个10人的team，就算domain由不同的人来修改，一般也不会出现乱掉的情况，因为交流方便嘛。
对于抱怨三： 要想避免这种情况，至少保证2个人熟悉同一个功能，agile的做法是pair，通过quick shift，理想的情况下大家知道的东西都是差不多了。
对于抱怨四， dev用共享的数据库进行开发，不好的地方就是测试数据互相干扰。既然
这样，每个人都搞一个本地数据库好了，其实这牵扯到数据库migration script的管理问题，这个先不说了。
2.也是一个J2ee项目，开发团队总共50人吧，基本上10人一个小team，负责一个子project，我们project用敏捷，TDD，CI都用。
抱怨声一，“他妈的～，我们依赖的一个project 的一个class的方法变了，我编译都通不过了.......
实际上随着这母规模的扩大，开发人员之间的协作会出现越来越多的问题，抱怨的很多，但是我只列举了一个有讨论价值的抱怨。
这个问题的出现，就是由于2个team之间有依赖关系，而且team之间远远没有team内部沟通快捷。如果一个team修改了底层代码，上层代码不是他们做的，而且系统规模比较大，也不可能把别的team代码进行修改。这时应该怎么办呢？
如果不管其他的team，强行提交代码，那么SVN上的code就是一个不能运行的版本，这样会因发其他的很多问题，比如QA的测试无法进行。因为一般的QA都是通过操作系统来造数据，然后进行测试，如果造数据功能被block掉，那么测试没办法进行。
所以首先第一个要保证的就是svn上一定是一个可运行的版本。
那么如果保证修改了底层代码，仍然保证其他team的code可以正常运行呢？
我的一个想法，底层team的代码可以以jar的形式提供，jar有版本号，如果做了修改，就commit一个新版本的jar，然后邮件通知其他的team要及时进行jar的更新，其他的team可以等合适的时候进行jar的调整。
如果修改了数据库怎么办？要知道继承测试环境用的是一个数据库，数据库不能像jar包一样分出版本号。新的jar包发布以后，如果数据库有修改，并且新旧jar对数据库的处理不同，那么持续继承的结果在一段时间内仍然是失败的。
大家讨论一下吧，欢迎拍砖啊～
24 楼 fenghai 2008-12-09 文档规范! 25 楼 starse7en77 2008-12-12 我们这里仅一个人维护底层的东西,其他开发机器使用XML在本机模拟生产数据.
这样整个project就可以运行 .但数据是假的.在本机测试后再上测试环境,最后上生产环境 .
基本上开发机器的底层都被改写.