20？80？
一直自诩为“打杂的”，简单的说，就是什么都干：项目相关文档、架构实现、自动构建、设计文档、编码，包括现在的项目在内，一直都是这样做的……
人的精力是有限的，即使天天加班也只能抓住那目前致命的20%时，剩下80%谁来做？低年级同学凭借能力和自信只能完成整个任务的50%，并且做的漏洞百出的时候，导致的结果只能是不得不推迟发布期。
结论是，虽然只做了20%，但需要检查验证的是100%。
代码的价值？
有人说代码是不值钱的，又有人说代码是很值钱的。前者说随便找个程序员都能弄出来一堆代码，后者说那些代码都是程序员用血汗写出来的。结论是完美无误的代码才值钱，代码中有一点瑕疵都有可能导致整段代码作废。
曾经看到过青年导报的一篇文章报道公司老员工能够创造不止3倍于新员工的价值，最根本的原因在于老员工懂得把事情做到位，回想很长一段时间来做的事情都不是很到位，忏悔。
文档、约束与时间
阅读文档被很多人当成是浪费时间的事情，因为之前读过了。但是当事情出了问题却在抱怨文档中没有说明。
认真反复阅读软件工程上一级甚至上N级流转下来的文档，只会带来无比巨大的好处，而不会影响任何的进度问题。一个项目经理或者测试人员能够把需求文档熟读到倒背如流的程度，无疑这个项目是成功的。
可怕的测试
曾经有两天出差时间，于是让A同学根据设计做编码，让B同学根据设计写单元测试代码，并且特地对B同学强调“你觉得A会出什么错误你就怎么写测试，但你不 要问A这个错误会不会出现”。出差回来了解到情况是，编码完成，并且所有测试都通过了。打开IDE一看，而测试代码仅仅针对每个接口的每个方法做了相应基 本流的一般测试（测试数据基本上没有代表性）。找到B同学问：“写了这么多对CRUD的测试有没有测试出什么问题？”答曰：“有，比如保存之后没有 flush……”当时拿刀杀人的心都有了。
测试应该从需求出发，按照每个需求中描述的特性进行针对性的测试，针对领域模型的测试应该是对领域层中实现的每个用例进行测试。测试代码也需要 从需求出发，好好设计一番。PS：真的很佩服B同学那么有耐心的写了好多new XX()然后调用了每个setXXXX方法，仅仅为了测试两行代码：
getHibernateTemplete().saveOrUpdate(obj);
getHibernateTemplete().flush();
文档？文档！
某日，正在紧张编码中，突然MSN上A同学找我：
我：什么错误？
同学A：是个空？
我：空是什么东西？
(1分钟后)
同学A：这是抓图（抓图中错误信息是null）
我：看看什么异常？
同学A：……NullPointerException
我：堆栈呢？
同学A：java.lang.NullPointerException:null
at com.company.xxxxxxxx……
上述问题了解问题花了3分钟，解决问题花了1分钟，整理回原来的思路花了5分钟。
另一次，与测试组讨论中：
我：怎么走不通？
同学B：XX操作的时候出了一个错。
我：我刚刚测试是好的啊，你那边出了什么错？
同学B：那是个什么什么错，一串英文。
我：那串英文是什么？
同学B：你看发给你的错误报告文档，那里面应该有。
（转到错误文档，找了半天发现一句“XXXXXX，上报出错”，汗……）
同学B：（很不好意思地）我机器上有抓图。
我：你机器IP是？
同学B：192.168.0.XXX
我：？远程桌面连不上？
同学B：哦，我远程桌面没开。
我：文件共享呢？
同学B：我也给关了。
我：那我怎么访问到你的机器？
同学B：好像访问不到
（沉默……）
同学B：（更不好意思地）我下楼把图片发给你把
（于是，勤劳的B同学就在19楼和13楼中又跑了一个来回）
PS:公司测试部门在13楼，会议室在19楼
文字比语言更能够达到有效沟通的目的，我们的客户能够在反馈问题的时候把错误屏幕截图和堆栈异常粘贴出来，我们为什么不能呢？
我才郁闷，公司几个员工辞职了，扔下了的代码没人维护，结果交给我了，我操，里面全是JDBC写的，到处System.out输出东西，try。。。catch代码嵌套的层数太多太多，业务我也不清楚，也没文档。想重写，公司又不让重写。。。改起来是动一发而牵全身，目前还在郁闷中。。。
据了解，项目一般都是领导口头对coder交代下，然后就风风火火干起来了，然而公司喜欢用哪些所谓的刚毕业的本科生、研究生。这帮人也没见过啥项目，就对着书本写代码，结果写出来的代码就像一碗面条。你想理出个头绪，还不如你自己重写了算了。
最后连他们自己都不愿意去维护自己代码了，逃避，实在逃避不过就是辞职。
哈哈哈哈。。。。。。
今天改这个老项目，乱七八糟的jdbc代码，改就改吧，可怜的项目连个build xml都没有，改完后，测试人员还找我编译呢。够郁闷吧。
管理人员本身的水平和素质不过硬，加上技术人员的逃避责任是国内大部分开发团队面临的共同问题：）
我的态度是宁愿让他们在工作期间好好学习也不想让他们在项目中乱堆代码。当然从公司利益的角度上考虑，让他们通过某种标准化的考试不失是一种不错的策略。当然国内软件开发行业重要的问题不是技术比人家落后而是管理上的问题太多。
公司从来都不重视代码，领导层从来都不需要编码，也不需要看编码。只凭感觉，某某某，两天时间把这个干完。
然后两天后，干完了，开始找测试组测试，结果测出一堆一堆的bug，紧接着加班改，结果改了一个月，还是有bug。哈哈哈哈哈。。。。这就是现状。