java方法设计

一、抛出问题

在java中，我们的方法该怎么设计，才能满足如下条件？

a、方法健壮

b、代码易于他人阅读

c、异常易于定位

二、进入讨论

a、为何方法要健壮？

回答这个问题，首先联系我们日常生活去理解“健壮”这个词。顾名思义：健康又强壮，可称之为健壮。健壮有什么好处呢？好处可就多了：不用经历病痛、可以欢快的奔跑在鲜花盛开的乡间小路上。可以一边喝着冰雪碧一边吃着烤生蚝，你说这种生活安逸不？反过来如果不健壮，那么很可能动不动的就感冒、发烧，各种打针吃药，一天天的没精神，需要别人的照顾，这种生活怕是有点糟糕。那么请设想，如果我们写的Controller方法，动不动就调用报错。前端动不动就能得到一串长长的java报错信息。用户使用系统时，动不动的就是：“我怎么点这里怎么又没有反应了？”你说那将是怎样一种体验？是不是心中奔腾而过一万只草泥马。所以，我们的方法一定要合理设计，使其健壮。不管什么时候，对于前端来说，返回给他们的：1、绝对不能是一串长长的java异常信息 ，2、绝对不能是500。即便是我们的代码真的出现异常报错了，返回前端的也一定得是200的状态码，再委婉告诉他：系统异常，请联系管理员！。对于调用者来说，除非数据有问题，否则不应该出现异常报错。而且，假如报错了，一定要把异常信息throw给调用者。让他知道，调用报错的原因，方便他修正问题。spring源码中的方法，就都是这么设计的。你使用spring框架如果报错了，得到的错误信息一定是具体的信息吧，例如说找不到xml文件呀、xml内容不规范、找不到符合的bean进行注入等具体提示信息。而不是什么空指针、数组越界、运行时异常等等这些异常吧。有了具体异常信息，你自然就能知道问题在哪，该怎么解决。所以为什么说spring框架是一个牛b的框架。因此我们的代码，也应该这样设计。

b、代码易于他人阅读

一个系统的代码，绝对不是靠一人之力完成coding的。从编码-->到上线-->到上线后的维护扩展。这个过程中，伴随着开发人员的流动。系统的代码会经历过许多人维护修改。而每个人coding的水平、理念、风格各不相同。有的人写代码，从不注意代码的排版，一个方法八九个参数，一个if判断一个横屏都装不下。有的人写代码，一个方法超级无敌长。读他的方法，读到后边已经不知道前边都干了些什么。有的人写代码从不使用throw关键字，什么情况都是return，catch里永远都是Exception。所以到项目上线以后的维护阶段，极为难受。风格不一的代码、重复的判断、无用的变量、难以理解的逻辑、任谁来接手，都是头大。种种的这些，告诉我们一个深刻的道理。一定要将代码写得规范整洁，一定要有工匠精神，将代码写得像字一样漂亮，像诗一样优雅。不要让后来接手你代码的人上来就是：这垃圾代码，是谁写的？而一个公司，更是需要这样的代码，否则项目将面临失控最后over。往后，我会单独拿出一个章节，通过业务结合代码的方式讲述一个方法，该如何设计会比较好。

c、异常易于定位

代码，在编码阶段，通过开发工具的debug功能。我们很容易发现bug，然后可以迅速对bug做出修改。可是一旦项目发布生产环境上线，生产环境出现了bug，那么我们该怎么办呢？生产环境可没有debug这种操作。这种情况下，我们只有借助日志来迅速定位问题了。所以我们在coding阶段，一定要打好日志。try-catch/throw/throws等关键字，一定要用好了。一个系统，如果日志打得好，那么维护阶段必定是极为舒服的，反之将痛苦不堪、不胜折磨。所以关于打日志这个东西，我也想单独拿出来讲讲，这里不打算深入探讨。