多的我就尽量不说了，骂人也是很累的。
换个角度，我来说说你犯的很明显的低级错误。凡是仅仅在小作坊里出来的，大体上只知道浑浑噩噩地去拼凑程序，只知道斤斤计较什么“程序员的洁癖”之类的问题，而不是了解工程技术和流程技术。编写软件的目的是什么？就是为了让其能够通过测试。真正重视测试的人才是真正的项目管理者（我不是说测试人员，我说的是管理实践者）。对于程序员来说，假设它花了1小时完成了任务、还是花了1分钟完成了任务，价值往往是一样的。但是这有一个前提，就是你能够
事先测试。
着就好像一个小工头组织一般人砌墙，你应该先拉一根基线，并且每当砌一层之后就要立刻移动到下一个基线。如果你没有预先拉起基线，如果你只是事后对工人说三道四，我认为这种工头也是很烂的。
如果你有初步成熟的工程组织思维，按照基本的工作习惯，其实你不用去太多重复去喊“这种人咱么带”的话，实际上你把他写的多余的代码注释掉、并且过2天之后彻底删除掉就行了。为什么要跟他生气呢？
如果没有成熟的工作方法，如果你自己就是仅仅拼凑代码的，很容易被人说成“你不是也是菜鸟过来的？所以你应该习惯于菜鸟！”这种话。这是因为你自己就算是多写过了一些代码，懂得套用更多的代码模式，可是还是没有掌握如何处理豆腐渣工程和以菜鸟为借口的人的方法。
顺便再在CSDN上（第二次）贴一下我在我们的一个项目中写下的一个简单文档，供参考：
《关于删除代码的要求.txt》
我们采取极限编程方式开发，注重保持“让其他人可以随时修改代码”的趋势，可能与传统的功能分解开发的方式有所区别。因此有以下要求：
1. 尽量注释掉.cs文件中的代码。对于已经提交到svn超过2天的代码文件，任何人都可以随时注释一些代码，只要所有测试程序均可以通过即可。
2. 尽量删除掉代码。每周内一定要删除一次注释了的并且已经超过2天的代码，系统中所有代码页仅剩下必要的那些代码即可。如需要追溯代码修改历史，请使用svn系统来完成。
3. 程序注释应仅写最少和必要的内容，或者不必写注释。如果对代码不理解，请自己写测试程序来研究，并且鼓励同事交流学习（而不是文档化）。在个人所写的测试程序中可以写大段的注释。
4. 每一个开发人员都要以测试驱动方式来写代码。一旦保证当前系统的（至少三天内）测试可以通过，立即提交到svn。例如可以每隔十几分钟即提交一次代码。要养成频繁提交代码的习惯。
5. 在任务分工时所编写的任务工单是主要的非代码文档。请仔细核对是否完成了工单上的接口需求（被其它组件调用、调用其它组件、数据库要求等）。没有完全完成一个任务，请不要转去做其它任务！
6. 如果一个任务被撤销（或者没有意义了），那么与之相关的代码应当在几天之内删除。请不要在最终提交的系统中留下不需要调用的代码！
7. 最重要地一条：鼓励所有人、任何时候均可以修改别人写的共享代码。没有任务时，可以随时重构已有的任何代码，对任何需求都（仅仅）采取“极端简单”的方式实现功能即可。
8. 由于特殊原因，本系统的测试代码写在发布的系统内了，而没有单独建立测试启动工程。这些测试用的代码（不管是谁提交的）应尽量保持不变。如果要修改，请先告诉我:-)
9. 对于由于特殊原因、因为赶进度而忽略了测试驱动开发原则所产生的代码，允许暂时使用“目测”的方式来测试。但是应当尽快补充编写自动测试代码！
说的真棒
想起去年的时候连repeater都不会用，第一个单位的的那个经理很耐心，各种耐心讲解...好感激
