企业网站维护外包,wordpress自动采集插件最好,新媒体 网站建设 管理规范,做网站要要多少钱对Java开发者来说#xff0c;有许多的标准和最佳实践。本文列举了每一个开发人员必须遵从的十大基本法则#xff1b;如果有了可以遵从的规则而不遵从#xff0c;那么将导致的是十分悲惨的结局。1#xff0e; 在你的代码里加入注释每个人都知道这点#xff0c;但不知何故…对Java开发者来说有许多的标准和最佳实践。本文列举了每一个开发人员必须遵从的十大基本法则如果有了可以遵从的规则而不遵从那么将导致的是十分悲惨的结局。 1 在你的代码里加入注释 每个人都知道这点但不知何故忘记了遵守。算一算有多少次你“忘记”了添加注释这是事实注释对程序在功能上没有实质的贡献。但是你需要一次又一次的回到你两个礼拜之前写的代码上来可能一辈子都是这样你一定记不住这些代码为什么会这样。如果这些代码是你的你还比较的幸运。因为它有可能让你回忆起。但是不幸的是很多时间这些代码是别人的而且很有可能他已经离开了公司。 2 不要让事情复杂化 我以前就这么干过而且我相信所有的人都这么干过。开发人员常常为一个简单的问题而提出一个解决方案。我们为仅仅只有5个用户的应用而引入EJBs。我们为一个应用使用框架而它根本不需要。我们加入属性文件面向对象的解决方案和线程到应用中但是它根本不需要这些。为什么我们这样做我们中的一些人是因为不知道怎么做更好但是还有一些人这样做的目的是为了学习新的知识从而使得这个应用对于我们自己来说做得比较有趣。 3 牢牢记住——“少即是多less is more”并不永远是好的 代码的效率是一伟大的事情但是在很多情况下写更少的代码行并不能提高该代码的效率。请让我向你展示一个简单的例子。 if(newStatusCode.equals(SD) (sellOffDate null || todayDate.compareTo(sellOffDate)0 || (lastUsedDate ! null todayDate.compareTo(lastUsedDate)0)) || (newStatusCode.equals(OBS) (OBSDate null || todayDate.compareTo(OBSDate)0))){ newStatusCode NYP; } 我想问一句说出上面的那段代码的if条件想干什么容易吗现在我们再来假设无论是谁写出这段代码而没有遵从第一条规则——在你的代码里加入注释。 如果我们把这个条件分到两个独立的if陈述句中难道不是更简单一些吗现在考虑下面的修正代码 if(newStatusCode.equals(SD) (sellOffDate null || todayDate.compareTo(sellOffDate)0 || (lastUsedDate ! null todayDate.compareTo(lastUsedDate)0))){ newStatusCode NYP; }else if(newStatusCode.equals(OBS) (OBSDate null || todayDate.compareTo(OBSDate)0)) { newStatusCode NYP; } 难道它不是有了更好的可读性是的我们重复了陈述条件。是的我们多出了一个多余的“IF”和两对多余的括弧。但是代码有了更好的可读性和可理解性。 4 请不要有硬代码 开发人员常常有意识的忘记或者忽视这条规则原因是我们和一般时候一样在赶时间。如果我们遵从这条规则我们可能会赶不上进度。我们可能不能结束我们的当前状态。但是写一条额外的定义静态常量的代码行又能花费我们多少时间呢 这里有一个例子。 public class A { public static final String S_CONSTANT_ABC ABC; public boolean methodA(String sParam1){ if(A.S_CONSTANT_ABC.equalsIgnoreCase(sParam1)){ return true; } return false; } } 现在每一次我们需要和某一些变量比较字符串“ABC”的时候我们只需要引用S_CONSTANT_ABC而不是记住实际的代码是什么。它还有一个好处是更加容易在一个地方修改常量而不是在所有的代码中寻找这个代码。 5 不要发明你自己的frameworks 已经推出了几千种frameworks而且它们中的大多数是开源的。这些frameworks中间有很多是极好的解决方案被应用到成千上万的应用中。你们需要跟上这些新frameworks的步伐最起码是肤浅的。在这些极好的、应用广泛的frameworks中间一个最好的、最直接的例子是Struts。在你所能想象到的frameworks中这个开源的web frameworks对于基于web的应用是一个完美的候选者。但是你必须记住第二条规则——不要让事情复杂化。如果你开发的应用只有三个页面—请不要使用Struts对于这样一个应用没有什么“控制”请求的。 6 不要打印行和字符串相加 我知道为了调试的目的开发人员喜欢在每一个我们认为适合的地方添加System.out.println而且我们会对我们自己说会在以后删掉这些代码的。但是我们常常忘掉删去这些代码行或者我们根本就不想删掉它们。我们使用System.out.println来测试当我们测试完成以后为什么我们还能接触到它们呢我们可能删掉一行我们实际需要的代码仅仅是因为你低估了System.out.println所带来的伤害考虑下面的代码 public class BadCode { public static void calculationWithPrint(){ double someValue 0D; for (int i 0; i 10000; i) { System.out.println(someValue someValue i); } } public static void calculationWithOutPrint(){ double someValue 0D; for (int i 0; i 10000; i) { someValue someValue i; } } public static void main(String [] n) { BadCode.calculationWithPrint(); BadCode.calculationWithOutPrint(); } } 在下面的表格中你能够看到calculationWithOutPrint()方法的运行花了0.001204秒。相比较而言运行calculationWithPrint()方法花了令人惊讶的10.52秒。 如果你不知道怎么得到一个像这样的表格请参阅我的文章“Java Profiling with WSAD” Java Profiling with WSAD 避免这样一个CPU浪费的最好方法是引入一个包装器方法就象下面这样 public class BadCode { public static final int DEBUG_MODE 1; public static final int PRODUCTION_MODE 2; public static void calculationWithPrint(int logMode){ double someValue 0D; for (int i 0; i 10000; i) { someValue someValue i; myPrintMethod(logMode, someValue); } } public static void myPrintMethod(int logMode, double value) { if (logMode BadCode.DEBUG_MODE) { return; } System.out.println(value); } public static void main(String [] n) { BadCode.calculationWithPrint(BadCode.PRODUCTION_MODE); } } 在下面的图中你将看到使用了StringBuffer的那个方法只花了0.01秒来执行而那个使用了字符串相加的方法却花了0.08秒来运行。选择是显而易见的。 7 关注GUI 不管这听起来有多么可笑我都要再三地说明GUI对于商业客户来说和功能和性能一样重要。GUI是一个成功的系统的必要的一部分。但是IT杂志常常倾向于忽视GUI的重要性。很多机构为了省钱而不雇用那些在设计“用户友好”GUI方面有丰富经验的设计人员。Java开发人员不得不依赖他们自己的HTML知识但是他们在这方面的知识十分有限。我看到过很多这样的应用它们是“计算机友好”而不是“用户友好”我很少很少能看到有开发人员既精通软件开发又精通GUI开发。如果你是那个不幸的开发人员被分配去开发用户接口你应该遵从以下的三条原则 一、不要重复发明轮子。寻找有相似用户接口需求的已经存在的系统。 二、首先创建一个原型。这是非常重要的步骤。客户喜欢看看他们将要得到什么。这对你来说也是很好的因为在你全力以赴而做出一个将要使用户生气的用户接口之前你就得到了它们的反馈。 三、戴用户的帽子。换一句话说站在用户的视角检查应用的需求。例如一个总结页面到底要不要分页。作为一个软件开发者你倾向于在一个系统中忽视分页因为这样使得你有比较少的开发复杂性。但是这对于从一个用户的视角来说却不是最好的解决方案因为小结的数据将会有成百上千个数据行。 8 永远准备文档化的需求 每一个业务需求都必须文档化。这可能在一些童话故事里才能成真但是在现实世界却不可能。不管时间对于你的开发来说是多么紧迫也不管交付日期马上就要到来你永远都必须清楚每一个业务需求是文档化的。 9 单元测试、单元测试、单元测试 我将不会深入地讨论哪些什么是把你的代码进行单元测试的最佳方法的细节问题。我将要说的是单元测试必须要做。这是编程的最基本的法则。这是上面所有法则中最不能被忽略的一个。如果你的同事能为你的代码创建和测试单元测试这是最好不过的事。但是如果没有人为你做这些事那么你就必须自己做。在创建你的单元测试计划的时候遵从下面的这些规则 一、在写代码之前就写单元测试用例。 二、在单元测试里写注释。 三、测试一切执行“interesting”功能的公有方法“interesting”的意思是非setters或getters方法除非它们通过一种特殊的方式执行set和get方法。 10 记住—质量而不是数量。 不要在办公室里呆得太晚当你不必呆的太晚的时候。我理解有时产品的问题、紧迫的最终期限、意想不到的事件都会阻止我们按时下班。但是在正常情况下经理是不会赏识和奖赏那些下班太晚的员工的他赏识他们是因为他们所做产品的质量。如果你遵从了我上面给出的那些规则你将会发现你的代码更加少的bug更加多的可维护性。而这才是你的工作的最重要的部分。 总结 在这篇文章里我给出了针对Java开发人员的十个重要的规则。重要的不仅仅是知道这些规则在编码的过程中遵从这些规则更为重要。希望这些规则能够帮助我们成为更好的编程人员和专业人员。 关于作者 Aleksey Shevchenko在面向对象方面的编程有着七年以上的经验。他现在在从事华尔街、制造和出版工业方面的IT解决方案的工作。 转载于:https://www.cnblogs.com/springMVC/archive/2007/05/14/2204690.html
