昨天请一个刚工作的同事评价一下某个开发团队的素质，他说很不错，用了很多先进的技术……，我意识到我没有教过他如何判断一个开发团队基本素质。

准确全面地衡量一个开发团队的素质要看很多方面，团队文化、个人能力、各种标准和方法论、是否有够多的技术储备和经验积累等等。但如果5分钟内要做一个大致的判断，可以试试看问技术负责人一个问题：你如何做日志。

最业余的家伙意识不到日志对系统维护的作用，因而在正常运行时不记录日志，仅在debug时打开，那么他的系统是很难维护的，在出现系统故障时无法得到足够的信息去定位问题。

其他一些常见问题还有：

1.日志无法反映处理过程进行到哪一步。需要高可靠性、高可维护性的系统，每个模块或处理环节应在处理过程进入本环节时、本环节完成处理时、本环节提交到下一环节时记录日志，并有足够的信息区分出是哪一笔交易，以便故障时分析问题出在哪一步。

2.日志没有清理机制。运行一段时间后磁盘空间满了，系统宕机。

3.同步方式向数据库里写大量日志。通常的数据库用来写日志效率很低很低，会大量消耗数据库性能和空间，另外数据库故障就写不了日志。

4.没有汇聚机制。假设应用服务器是一个30台机器的集群，现在怀疑昨天9点5分有一笔交易有问题，你需要去30台机器上一一找日志文件去。

5.日志切割策略不实用。比如，每100M切割一个日志文件，还是那个问题，现在怀疑昨天9点5分有一笔交易有问题，碰巧现在你又在外面用×××上的公司网络，你就在那100M的文件里慢慢找吧。如果日志产生速度比较快，每小时产生一个文件名中包含时间的日志文件会方便得多。

6.不能提供足够的信息与接口系统核对交易。例如：A系统调用B系统完成积分扣减。AB系统在日志中应分别记录每笔交易中自己和对方的交易流水号，以便核对。同时，一些关键的调用应该定期（比如每天）核对双方的交易记录，确保双方记录一致。

7.没有方便的日志查看工具。大系统大团队的分工是比较细的，不能要求值班接报障碍、监控系统的人去深刻理解系统的运行机制并开发一个搜集、拼接、展现日志信息的工具，如果你的开发人员不希望整天参与问题分析和障碍处理，最好提供一个方便的日志查看工具。

好了，差不多今天想到的就这些了，在现在这样一个三四流开发团队横行的时代，能找到一个有意识避免上面7个问题或其中大部分的开发团队，是一件非常值得庆祝的事情。