项目开发的一点经验

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：XXX功能的保存方法出错了
我：什么错误？
同学A：是个空？
我：空是什么东西？
(1分钟后)
同学A：这是抓图（抓图中错误信息是null）
我：看看什么异常？
同学A：……NullPointerException
我：堆栈呢？
同学A：java.lang.NullPointerException:null
at com.company.xxxxxxxx……

    上述问题了解问题花了3分钟，解决问题花了1分钟，整理回原来的思路花了5分钟。
    另一次，与测试组讨论中：

引用

同学B：XXXX流程走不通。
我：怎么走不通？
同学B：XX操作的时候出了一个错。
我：我刚刚测试是好的啊，你那边出了什么错？
同学B：那是个什么什么错，一串英文。
我：那串英文是什么？
同学B：你看发给你的错误报告文档，那里面应该有。
（转到错误文档，找了半天发现一句“XXXXXX，上报出错”，汗……）
同学B：（很不好意思地）我机器上有抓图。
我：你机器IP是？
同学B：192.168.0.XXX
我：？远程桌面连不上？
同学B：哦，我远程桌面没开。
我：文件共享呢？
同学B：我也给关了。
我：那我怎么访问到你的机器？
同学B：好像访问不到
（沉默……）
同学B：（更不好意思地）我下楼把图片发给你把
（于是，勤劳的B同学就在19楼和13楼中又跑了一个来回）
PS:公司测试部门在13楼，会议室在19楼

    文字比语言更能够达到有效沟通的目的，我们的客户能够在反馈问题的时候把错误屏幕截图和堆栈异常粘贴出来，我们为什么不能呢？