5,179
社区成员
发帖
与我相关
我的任务
分享如何走出源码管理的阴影？
本是是工作了7个月3天的应届毕业生，主要负责数据库维护，源码开发到测试、正式发布入库的中间环节，由于业务知识的缺乏，编码能力一般，基本是在很原始的管理的模式下做些纯手工的操作.....
虽然从最开始的手工编写SQL同步管理各种数据库，慢慢的学会用OSQL命令行批处理，学会用PowerDeginer跟MSSQL自动生成规范脚本，学会数据库脚本的持续集成，学习的热情不但没好转，随之而来的困难也开始重重。因为我认识到自动化工具的重要性，经理说过数据库不是尽量少错，而是不能错，每次我人工干预数据库持续开发的时候我就总会不停的停下来对比表结构，对比表数据，用PD刷数据库来对比，因为怕错。
允许我前面说的这些看来很罗嗦的话，后面源码管理的正是我在这种心情下写出来的。源码管理对我来说完全是新名词，我看到公司的开发人员从开始的VSS迁移到SVN，工具是先进了，但是方式依然老套，SVN唯一发挥的作用可能就是可以更多的允许开发人员犯错了。简单说下我们源码管理的流程， 因为系统是在MVC+COMMAND模式下开发的，基本框架包含编码的通用功能，数据持久化采取PD生成的DAO对象映射，数据变化采用的DataSet大部分方法也被封装到DAO中，代码看来还是写的非常规范的。
但是事实并非如此，功能点尽量的被分离成简单的单个文件，耦合的地方大都通过二次框架提供接口，或者在BRIN业务逻辑层提供BROUT调用接口，我之所以说这些，是想说出后面的悲剧。我们做的是企业ERP项目，规模还是比较大的，技术上也是过的去，可是让人不忍受的是非常纠结的代码发布。SVN提供开发人员共享彼此的更改，要发布版本时，先是开发人员提供提交的代码清单，也就是文件列表。我就负责按照清单，从SVN服务器获取最新的文件，复制到之前的测试版本中合并，通过装订打包工具，将DLL文件转换成二进制流写入到自定义文件中，每个子系统一个，最终通过部署工具发布到WebSerice应用服务器上，提供给所有的客户端下载。
大家可能觉得这个过程很平常，我列出了以下几点：
1. 首先由于业务需求变动比较大，开发人员流动大，大伙加班加点，频繁的修改代码，如果没事先说清楚，冲掉对方代码很平常
2. 正是这样频繁的修改，需求文档的不完全约束，极其不稳定的开发环境下，我们没有任何的单元测试，只是纯测试人员的界面点击
3. 正是因为开发人员改动频繁，又没有经过自测，我们才想到将开发人员的SVN环境人为的跟测试环境分离，而这个代码管理的中间重要环节就是我通过重复，仔细，小心的查找文件，复制、粘贴完成
4. 再就是那个部署程序，所有的子系统都是一样大，拥有全部的DLL，可以独立运行，为了这个自由、灵活的模式，牺牲的就是一点代码的改动换来的是整个ERP的重新编译、部署、装订，从来没有补丁一说，耗时又没有保障
5. 最后就是产品的基线管理：源码基线，中间产物源码目录压缩包基线，客户端、服务端安装部署文件基线全部都是通过文件备份在SVN里面，这个基线管理的东西又多，每天重复的劳动却没办法简化操作
为什么我拿它跟数据库开发的持续集成一起比较列，因为他们都是影响项目的最重要的2个东西，它们的不稳定换来就是无休止的担心，更是业务频繁变更的绊脚石。作为项目管理，可能我这个拿的小小薪水的人能力实在是有限，这不是我能左右的事情，项目经理忙在数据库设计，业务需求设计，技术组的人忙于ERP系统的消息、通讯、邮件和搜索等的OA整合组件开发，而开发人员早已被淹没在无止境的BUG修改中。
看到这种情形，最让人讽刺就是做企业自动化的人，却在自己项目中看不到半点自动化控制。开发人员每改个东西要写EXCEL文档，他们烦；测试人员总是埋怨版本发不出来的有问题，因为问题总是出现在SVN获取不到最新，有人没签入，装订工具异常，我看太多的文件列表的时候遗落等；经理等一个版本发布出来等的纠结，一个小时，二个小时的过去；实施人员不断重复，在重复的点击相同的功能点，因为随时他们又会出现错误.....................
如果说软件开发时最严谨的工程，那我们太需要软件工程中的质量管理，我也只是想在这种已经极其不规范的情况下，以为自己可能做到的事情去改善质量。我希望看到我这篇文章的大佬们，能提供一些简单、实用，最好有范例和文档的自动化管理工具，能对我起动启发的经验之谈，或者提供比较合适的问题解决路径和书籍之类。
说的比较多，可能有的人都觉得我说的没重心，我只希望一点小东西，一个小经验，一种小工具都能给我带来帮助，如果有跟我一样陷入源码管理阴影的人，能一起走出来。。。本文长期关注，上班期间一有时间就会多尝试，我也会将它们整理出来，给所有跟我一样的人分享。。。。。。。
谢谢~~~
虽然从最开始的手工编写SQL同步管理各种数据库，慢慢的学会用OSQL命令行批处理，学会用PowerDeginer跟MSSQL自动生成规范脚本，学会数据库脚本的持续集成，学习的热情不但没好转，随之而来的困难也开始重重。因为我认识到自动化工具的重要性，经理说过数据库不是尽量少错，而是不能错，每次我人工干预数据库持续开发的时候我就总会不停的停下来对比表结构，对比表数据，用PD刷数据库来对比，因为怕错。
允许我前面说的这些看来很罗嗦的话，后面源码管理的正是我在这种心情下写出来的。源码管理对我来说完全是新名词，我看到公司的开发人员从开始的VSS迁移到SVN，工具是先进了，但是方式依然老套，SVN唯一发挥的作用可能就是可以更多的允许开发人员犯错了。简单说下我们源码管理的流程， 因为系统是在MVC+COMMAND模式下开发的，基本框架包含编码的通用功能，数据持久化采取PD生成的DAO对象映射，数据变化采用的DataSet大部分方法也被封装到DAO中，代码看来还是写的非常规范的。
但是事实并非如此，功能点尽量的被分离成简单的单个文件，耦合的地方大都通过二次框架提供接口，或者在BRIN业务逻辑层提供BROUT调用接口，我之所以说这些，是想说出后面的悲剧。我们做的是企业ERP项目，规模还是比较大的，技术上也是过的去，可是让人不忍受的是非常纠结的代码发布。SVN提供开发人员共享彼此的更改，要发布版本时，先是开发人员提供提交的代码清单，也就是文件列表。我就负责按照清单，从SVN服务器获取最新的文件，复制到之前的测试版本中合并，通过装订打包工具，将DLL文件转换成二进制流写入到自定义文件中，每个子系统一个，最终通过部署工具发布到WebSerice应用服务器上，提供给所有的客户端下载。
大家可能觉得这个过程很平常，我列出了以下几点：
1. 首先由于业务需求变动比较大，开发人员流动大，大伙加班加点，频繁的修改代码，如果没事先说清楚，冲掉对方代码很平常
2. 正是这样频繁的修改，需求文档的不完全约束，极其不稳定的开发环境下，我们没有任何的单元测试，只是纯测试人员的界面点击
3. 正是因为开发人员改动频繁，又没有经过自测，我们才想到将开发人员的SVN环境人为的跟测试环境分离，而这个代码管理的中间重要环节就是我通过重复，仔细，小心的查找文件，复制、粘贴完成
4. 再就是那个部署程序，所有的子系统都是一样大，拥有全部的DLL，可以独立运行，为了这个自由、灵活的模式，牺牲的就是一点代码的改动换来的是整个ERP的重新编译、部署、装订，从来没有补丁一说，耗时又没有保障
5. 最后就是产品的基线管理：源码基线，中间产物源码目录压缩包基线，客户端、服务端安装部署文件基线全部都是通过文件备份在SVN里面，这个基线管理的东西又多，每天重复的劳动却没办法简化操作
为什么我拿它跟数据库开发的持续集成一起比较列，因为他们都是影响项目的最重要的2个东西，它们的不稳定换来就是无休止的担心，更是业务频繁变更的绊脚石。作为项目管理，可能我这个拿的小小薪水的人能力实在是有限，这不是我能左右的事情，项目经理忙在数据库设计，业务需求设计，技术组的人忙于ERP系统的消息、通讯、邮件和搜索等的OA整合组件开发，而开发人员早已被淹没在无止境的BUG修改中。
看到这种情形，最让人讽刺就是做企业自动化的人，却在自己项目中看不到半点自动化控制。开发人员每改个东西要写EXCEL文档，他们烦；测试人员总是埋怨版本发不出来的有问题，因为问题总是出现在SVN获取不到最新，有人没签入，装订工具异常，我看太多的文件列表的时候遗落等；经理等一个版本发布出来等的纠结，一个小时，二个小时的过去；实施人员不断重复，在重复的点击相同的功能点，因为随时他们又会出现错误.....................
如果说软件开发时最严谨的工程，那我们太需要软件工程中的质量管理，我也只是想在这种已经极其不规范的情况下，以为自己可能做到的事情去改善质量。我希望看到我这篇文章的大佬们，能提供一些简单、实用，最好有范例和文档的自动化管理工具，能对我起动启发的经验之谈，或者提供比较合适的问题解决路径和书籍之类。
说的比较多，可能有的人都觉得我说的没重心，我只希望一点小东西，一个小经验，一种小工具都能给我带来帮助，如果有跟我一样陷入源码管理阴影的人，能一起走出来。。。本文长期关注，上班期间一有时间就会多尝试，我也会将它们整理出来，给所有跟我一样的人分享。。。。。。。
谢谢~~~
...全文
请发表友善的回复…
发表回复
xiong235 2010-03-10
- 打赏
- 举报
差不多可以结贴了！希望大家以后能多互相交流！ 算认识个朋友吧，这位朋友在论坛还是蛮活跃的，看的到哦！
xiong235 2010-03-10
- 打赏
- 举报
多谢提点......恩！我会做好自己本分的事情！ 有时候真想看看别人公司是怎么做的，可以说下如何获得这方面的信息？ 我会经常关注软件测试跟质量管理的！ 0..0 嘎嘎！
loveisbug 2010-03-10
- 打赏
- 举报
客户那边先不要管他，单元测试也没啥好追究的，也不要去想了，既然项目已几乎完成，每天是在改业务逻辑解bug，我觉得不需要提交清单，不需要通过你check再提交，还是让开发人员自己提交，但是一定要确保自己提交的内容，1编译通过，2自己测试过。这样，开发人员的工作量自然会减少。
改动到别人动过的代码，多喊两声问问，结对，或者至少工作内容接近的同事之间多交流自己改动的原因和做法。
3和4要做，测试跟上。
改动到别人动过的代码，多喊两声问问，结对，或者至少工作内容接近的同事之间多交流自己改动的原因和做法。
3和4要做，测试跟上。
xiong235 2010-03-10
- 打赏
- 举报
恩，你说的对！并不是开发人员存心想这样。我经常问他们，我们这大的项目怎么没有单元测试啊？他们的回答都是，需求、设计都很稀烂，业务需求变更有时候连文档都没，光改业务逻辑、改BUG都忙不过来，根本没人做单元测试。 当事实是不是这样咧，我去过调研的现场，实施人员跟客户沟通的时候发现很多原本一开始就敲定的东西现在还在讨论，客户领导是一任换一任，朝令夕改，有时候领导提出的业务都违背了ERP的精神，趋于过渡，软件不得不委曲求全。
但是现如今，项目开发的基本完全了，虽然软件已经不是那么圆了，但是为了推上去，大家改BUG的动力还是蛮足的。这个节骨眼上，如果是要狠抓开发人员的编码，不仅仅容易呆板教条、打击人员积极性，更怕的是更多的人员流失。
我真的希望委曲求全，虽然不规范，但是希望尽量做好后勤工作，减少开发人员的工作量。可以不单元测试，但是修改了哪些文件，我可以叮嘱他们写全；可以编译不通过，但是我可以根据测试人员需要提交的BUG清单，一个一个的不耐其烦的问清楚他们；可以相同的代码在不同的数据库中出错，但是我必须时刻跟进，充分保证数据库结构的一致，和内置数据的正确性；可以做过的相同的业务数据给他们做备份，我慢慢的问清楚业务表之间的关系，一点一点小心的用SQL或者数据库保存业务数据，从而减少测试数据的准备，及时的沟通，加快BUG修改或者业务整改的速度。
可目前一个更为严重的问题让我很困惑，如果才能做好源码管理，我只是希望如下环节中不能出错：
1.开发人员填写提交文件清单的文档，并提交代码；（我可以通过SNV LOG查看他对文件的修改）
2.我获取提交的文件清单，按照清单获取单个文件，并放入到上个版本的源码中；（为什么要有这样的中间环节，因为开发的SVN源码库中有些他们修改了的，但是提交会报错的文件）
3.我重新编译解决方案，打包装订，部署到服务器，测试员人通过客户端下载最新；（这个过程很难出错）
4.备份每日最后的发布的源码文件；（一旦出错，可以根据文件清单回溯重新发布）
问题就出在这个过程花费时间很长，一般30-40分钟不等，网络上的自动化部署的解决方案完全不适用。
loveisbug 2010-03-10
- 打赏
- 举报
看看《敏捷开发的艺术》也许会有帮助。
快乐老头儿 2010-03-09
- 打赏
- 举报
感觉你们不是缺少工具，而是缺少规则和纪律。
xiong235 2010-03-09
- 打赏
- 举报
沙发自己做！..........
loveisbug 2010-03-09
- 打赏
- 举报
是啊，编译不通过怎么提交了。从切入点，一点点抓起。
xiong235 2010-03-09
- 打赏
- 举报
冲掉代码发生并不是很多，只是在一个人走了，另外一个人面对他遗留的BUG，界面优化等，都改的很棘手，所谓冲掉就是把别人的代码改出BUG。其实之所以会这样，还是测试不过关，一个文件面临修改的几率太高。 最形象的就是测试人员经常埋怨，有的开发人员代码都编译不怎么通过就提交了
loveisbug 2010-03-09
- 打赏
- 举报
问题不在于流动性，也不在于同时改同一个文件。这些情况都不应该出现冲掉代码的情况。你可以从这个问题入手，寻找原因，解决它。
xiong235 2010-03-09
- 打赏
- 举报
我可以说下我个人的思路：软件质量，很多人都比较推崇良性的持续集成，做好每个环节和及时的自检反馈是保证质量的关键。而人这种动物很多时候都不理性，说的清楚点就是哪怕刀架在脖子上也会犯错，而这种低级错误正是项目经理头疼的事情，项目经理也会憋的乱发牢骚，搞的气氛更加激烈！
为什么错误不能被允许列！企业自动化控制很多时候障碍来源于软件的容错性不强，也就是不人性。当我们厌恶错误的时候，很容易找到不人性的方式来处理问题，强大的团队精神默默承受着种种不人性的压力。压抑导致每个当事人都非常紧张，游戏的气氛一旦紧张，就失去了竞技的能力，每次编写代码，每次高强度的、高难度的问题解决都是博弈，为什么气氛就是那么惹人讨厌？
而我更加喜欢在一种容许错误的环境下工作效率更高，错了可以重来，没有必要花费所有的精力在一个地方，如果工具和规则能帮助我们缩短流程时间，使得错误后重来的时间大大缩小，这时候再推崇竞争，每个人都不愿意犯错，这下他们就可以轻松进阶了。
每个人都会有不习惯，或者不熟练的时候，而软件开发要良性发展，真的很需要这些人性的地方，工具可以减少时间，让人更多的去思考。软件质量上来了，开发成本就降低了，工资的期望也上去了，人也过的更加轻松了，何乐而不为列。
真心的希望每个在职的IT人都能 工作在一个人性的，自己喜欢的公司！如果不能选择到自己喜欢的公司的话，我的第一个公司，我更加愿意去慢慢的贡献自己，哪怕走的时候也没有遗憾！
为什么错误不能被允许列！企业自动化控制很多时候障碍来源于软件的容错性不强，也就是不人性。当我们厌恶错误的时候，很容易找到不人性的方式来处理问题，强大的团队精神默默承受着种种不人性的压力。压抑导致每个当事人都非常紧张，游戏的气氛一旦紧张，就失去了竞技的能力，每次编写代码，每次高强度的、高难度的问题解决都是博弈，为什么气氛就是那么惹人讨厌？
而我更加喜欢在一种容许错误的环境下工作效率更高，错了可以重来，没有必要花费所有的精力在一个地方，如果工具和规则能帮助我们缩短流程时间，使得错误后重来的时间大大缩小，这时候再推崇竞争，每个人都不愿意犯错，这下他们就可以轻松进阶了。
每个人都会有不习惯，或者不熟练的时候，而软件开发要良性发展，真的很需要这些人性的地方，工具可以减少时间，让人更多的去思考。软件质量上来了，开发成本就降低了，工资的期望也上去了，人也过的更加轻松了，何乐而不为列。
真心的希望每个在职的IT人都能 工作在一个人性的，自己喜欢的公司！如果不能选择到自己喜欢的公司的话，我的第一个公司，我更加愿意去慢慢的贡献自己，哪怕走的时候也没有遗憾！
xiong235 2010-03-09
- 打赏
- 举报
其实是因为人员的流动大，导致有人经常要去修改别人编写的代码，甚至为了进度2个人参与修改相同的文件，本质上来说这样的情况是无法避免的，你不小心动到别人的代码还是有可能的。
xiong235 2010-03-09
- 打赏
- 举报
如果有人说这样做怎么好，为什么好？大家还是会听从的，因为这已经严重影响到代码的质量。天天的加班有时候仅仅只是为了通过守点式方式，来等待错误被测试人员点击界面来发现。大伙花费的时间跟产生的效果完全不成比例！ 好的工具同时也附带着好的处理思想和方式 目前我只是想借助工具的熟练使用 一点一点的节约重复劳动 或者用自动化的方式来提高代码质量
loveisbug 2010-03-09
- 打赏
- 举报
为什么经常会冲掉对方代码？
