程序员为什么不写单元测试

程序员的素质一个方面，管理是最主要的问题。如果公司本身没有对测试给与重视，要求单元测试并且定期检查，配合奖惩措施，仅仅靠程序员的素质是没办法保证有良好的单元测试

的确是素质问题，因为代码写完正常通过就行了，剩下的维护成本什么的
是公司和维护人员的事。

这样很不好！

并不是主观的不不写, 其实写单元测试也不简单.
比如叫你去测controller, 测dao, 即使有这个想法, 实施起来也比较难, 没有象rails那样方便的环境, 还有学习曲线在内.

对于我这边来说, 多数情况是, 靠巧合编程, 成了, 就跑一边看新闻/泡论坛/聊QQ去了, 如果没有异常反馈, 我可能永远再也不会看到那段代码了.

说到文档，ＪａｖａＤｏｃ并不是什么好的代表吧。
绝大多数ＪａｖａＤｏｃ都没有任何参考价值。里面全是废话。

就连ＪＤＫ的ＪａｖａＤｏｃ也不怎么样。大部分的所谓说明都无意义。
就文档而言我是推崇ＭＳＤＮ的。从原理到ｓｔｅｐ　ｂｙ　ｓｔｅｐ到具体某一典型需求的实现方法。详细的参考文档。无数的代码片断，以及完整的Ｓａｍｐｌｅ程序。
而且ＭＳＤＮ虽然是英语文档，但是充分考虑到非英语母语人群。里面的英语非常易懂。
总之就一个词：专业
不过能做到这个程度的确实是凤毛麟角。

至于说直接读源代码，一方面对程序员要求太高，另一方面效率太低。我读一个５０Ｋ的Ｈｅｒｉｔｒｉｘ的源代码都花了２个月的时间。很多细节都没有读到。要是大家都这么干的话，成本就到天上去了。

而Ｃ＋＋的源代码，比如ＳＴＬ，Ｂｏｏｓｔ，ｃｒｙｐｔｏｐｐ等，只有真正的高手才能读懂他们的源代码了。这样的人一个公司里能有多少？

java有源代码还说那么多干什么？doc只是一个概述。

其实说是成本问题也未尝不可，因为“通常”（注意我说的是通常）不写单元测试的程序员要便宜一些。
唉，不知道又要得罪多少人，我闪了。。。

java有源代码那是很后来的事了。
而且读源代码的效率真是。。。

照我看，狂写注释的人应该好好反审一下。
正常情况下，注释写的太多说明代码中类似i,k,j的变量太多，或者是因为一个方法充斥着太多莫名奇妙的让人费解的循环或者条件判断。这样的代码需要的不是注释而是重构！ 在代码经过多次重构之后，一段段费解的代码被移到适当的方法或类中，程序逻辑变得清晰。此时更无加注释的需要，因为那个时候加的所有注释都只是方法名和类名的中文翻译。。。如果你认为重构后的代码仍然需要注释，那只可能有一个原因。你英语不够好，方法名都用的是拼音，或者是别人用英语写的方法名你看不懂。这种情况下我建议你去花点时间学英语，或是装个金山词霸。

综上推理，写代码狂写注释的人需要去学如何重构。

关于重构，关于文档，关于注释的文章已经讨论很多了，就不要在人家帖子里在重复、重复，再重复了。

习惯了只看不说了。

不过今天看到讨论这么积极的，还是忍不住登陆下。

一个项目的成败，并非绝对以测试代码，注释力度为准则的。

在项目周期内，完成开发范围内的内容，基本就能拿到钱。
不过，提交给客户的产品，和自己开发过程的附属物，完全两码事。

注释，是一个代码的有益补充，如果代码流程写真的写的非常的清晰，那么要注释来做什么？代码本身就是最好的注释。
例如，我用struts来做项目，那么我的action里，每个方法的request，response，mapping等参数，难道都非要写上注释么？没必要吧。懂struts的人不需要注释也能看懂，不懂的给注释也看不懂。
看不懂？那先去看struts去。代码本来就是给懂代码的人看的。

当然如果你写一段复杂的业务逻辑，你能一句注释都没有么？
注释只是陪衬红花的绿叶而已。


至于测试，我倒觉得非常有必要，单元测试更是如此。
不过至于测试方式，倒是没必要规定必须用什么，这个本来就是跟开发环境，方式，周期等项目本身的特点决定的，不能一概而论。