就协助其他模块定位问题的一点感慨， 总结了下 发给了 我们模块的人，（就事论事，不对人）
没想到引起了以下对话。
我的总结:
前几天 支撑版本发布时
*** 模块xxx业务报错， 我帮着分析错误
搞了N久才发现是很低级的错误
1. 他们是新增的需求，21号到的现场 到出问题时 已经9天，这期间 竟然没有测试人员发现， 这值得思考，
家里和现场脱节？
2. 导致此问题的原因是 前台没有按照 后台给的数据结构进行解析，
不得不怀疑 他们家里的开发人员 是不是 没有联调通过 就提交了？
而且犯得的是转型和数据为空未处理的错误，未免太低级了， 值得思考！
3. 对集合搞来搞去，两三个前台人员 愣是没看懂 这短短几行代码想表达什么意思？
这样的代码 维护成本太高了， 值得反思！
假如 开发人员在开发时 多投入一份责任心，可能紧紧需要 几分钟，
可是正是缺少了这份责任心， 这种代码到现场后 维护工作大大增加，
特别 不是本模块的人进行维护时 业务不熟悉，代码不熟悉，协议不熟悉，再加上所写代码不知所云，
那可能 耗费半天的时间来搞这么一个 很小很小的东西。
----------------------以下是 F君的回复---------------------------------------------------
(表扬的话 就不写出来了)，
越是低级错误，定位完越让人感觉可恨；
不是不让人犯错误，但是不应该无原则的犯错误。
下一步模块合并了，无法分你我了，对于我们的以前好的东西，
可以向这帮兄弟推广一下，和武超你们看看能否也弄过简单版的前台变成规范，
（就像后台一页纸），大家照此执行，90％的代码风格也就一样了。
接着是我的回复：
咱们注意力 也不能光集中在 代码规范上，
功能都没实现，联调都没通过，
这一关都没过! 问题 1
家里开发完后 ，9天的时间里现场竟然 没发现此问题， 问题 2
问题 1 2 才是可怕之处。
毕竟 开发出来的程序 无论烂也好 美也好， 先要能用嘛
------------------------------------------------------------------------------------------------------
以下是W君的回复：
。。。。。。。。。
能够发现问题，思考问题，最好还能解决问题/或者是推动大家一起解决问题。
关于需求/bug的跟踪测试，与沟通 咱们从上到下正在努力，领导们正在推动。
我关注的是：
3. 对集合搞来搞去，两三个人 愣是没看懂 这短短几行代码想表达什么意思？ 这样的代码 维护成本太高了， 值得反思
从这个例子上隐约看到自己的影子，咱们也有一些代码质量低略的实现，导致维护、修改非常困难，耗时多，风险高。
越做问题越多、问题越多时间越紧、时间越紧越容易草率、越草率问题越多，恶性循环。
看不懂的代码 与清晰易懂的代码哪一个更容易出问题？
看不懂的代码 谁敢下手改？
改了谁知道他的正确性？
看不懂的代码如何产生的？
更关键是：
写出清晰易懂的代码需要哪些素质？
你能识别哪些代码比较好吗？
这些代码如何才能变到清晰易懂？有哪些手段？
如果这个变化过程会付出比较高的成本，那这些努力值得吗？
咱们的集团类业务和部分老业务，现在就面临着这些问题，我有点拿不准。
附带的再问个小问题：
参数全部是集合、tagset有什么问题 能总结一下吗？
有什么办法避免、缓解吗？
问题出在项目内，功夫全在项目外。
----------------------------------------------------------------------------------------------------
我的解答：绿色为我的答复，蓝色为原文
从这个例子上隐约看到自己的影子，咱们也有一些代码质量低略的实现，导致维护、修改非常困难，耗时多，风险高。
-----确实咱们有些业务。。
越做问题越多、问题越多时间越紧、时间越紧越容易草率、越草率问题越多，恶性循环。
看不懂的代码 与清晰易懂的代码哪一个更容易出问题？
-------------------------------------------当然是 看不懂的代码容易出问题，
看不懂的代码 谁敢下手改？
--------------------------------本来就看的一知半解 不断的往里塞东西，局部看似实现了需求，
其实从全局来看 问题多多， 也就是 不应该只为了需求而需求
保证正确性，这个问题太大，需要系统的知识，
改了谁知道他的正确性？
------------------------------------ 比如修改前 是否对源代码的逻辑了然于胸，测试用例，
科学的重构方法、方案、步骤等。
看不懂的代码如何产生的？
---------------------恶性循环所致， A写出来后的代码就让人看不懂，B后来维护 似懂非懂，再往里添加东西，长期下去，。。。。
更关键是：
写出清晰易懂的代码需要哪些素质？
---------------1. 责任感，如你所说的 人生观 价值观，
2.开阔的视野 思路 （这些如何提高，是个问题，
这些也是造成代码不易维护的另一个原因，思路不开阔 陷入死胡同 那么越绕越晕，
隐含的问题也会越来越多）
3.系统的扎实的知识
4.能从别人代码中挑出不合理之处供自己引荐
5. 多交流，互相评审 提意见
你能识别哪些代码比较好吗？--------------------代码好不好，没有特定的标准， 但 能让人看得懂的代码 绝对不是差的。
这些代码如何才能变到清晰易懂？有哪些手段？
---------------- 《代码大全》 《pratical in java》 《重构》
如果这些书中所讲的 能明白其思想，相信写出来的代码不会很差
如果这个变化过程会付出比较高的成本，那这些努力值得吗？
-------------权衡与妥协， 有变化肯定会带来问题，如果压力不大可以搞搞，
但顶不住时 那也没办法， 只能妥协罗。 比较领导要的是能运行的东东
附带的再问个小问题：
参数全部是集合、tagset有什么问题 能总结一下吗？
有什么办法避免、缓解吗？
---------------------------既然后台总体趋势是用 集合tagset，那么咱们也只能 另辟蹊径了，
正如你之前所教导，集合参数所带来的问题：顺序的耦合性，不可未知。。
调用者不知道 调用的时候传递什么？
特别是 咱们的帐单查询结构，我的乖乖 到现在我都不能 清晰的看懂他的结构，
甚至 一个数据结构 深度 4、5层，一看就晕
提议： 既然咱们决定不了 前后台这种结构，那么能否 将集合 map等限制在 call层，创建一些更为形象、更具代表意义的 Bean，可能咱们charge中产生大量的bean，不过我觉得很值，这样再配合 集合中的泛型，那么 数据结构会更加清晰。
问题出在项目内，功夫全在项目外。------------------都老矣，很少有 之前的冲劲了，
--------------------------------------------------------------------------------------------
W君的回复：
别的咱不多说。
反正基本功扎实、代码质量上乘、了解重构测试 ，作为程序员生活会轻松一些吧？
或者是 越来越轻松。
相信 绩效也会高一些。
