BlogJava-robbie-随笔分类-软件设计

如何编写高质量的Java代码

The Matrix — Sun, 15 Jun 2008 14:05:00 GMT

如何编写高质量的Java代码：

1、养成良好的习惯及良好的编码风格，比如当有代码没有彻底完成前，通过TODO、FIXME等方式进行标注，比如良好的命名规则、注释、行间距等

2、秉承设计模式的一个基本原则：单一职责，一个类不应过于庞大，如果过于庞大，则应分解

3、避免Ctrl+C、Ctrl+V，当发生这样的事情后，需要进行重构

4、要敢于重构，敢于重构的一个质量保证手段就是要对代码进行充分的测试

5、注意异常处理、注意事务控制的范围

6、遇到问题不能总是求助于Google、其他同事，要自己能够分析问题，解决问题

7、不能仅仅满足于编码速度快，要时刻牢记需要编写的是高质量的代码，易于维护的代码。一定要深刻理解高质量、易于维护。高质量就是说代码需要在各种情况下都能正常工作，而不仅仅是正常流程no problem，易于维护就是说如果换了一个开发人员来修改代码，是否能够很容易的阅读代码，理解代码，还是他会觉得这段代码无药可救了，重写是最佳选择，如果是后一种状况的话，那么这段代码就是最糟糕的了。

以下为摘自IBM 的一段话：

高质量的软件通常具备了这样一些特性：

满足用户的需求。
合理进度、成本、功能关系。
具备扩展性和灵活性，能够适应一定程度的需求变化。
能够足够的强壮、足够的鲁棒，能够有效的处理例外的情况。
保持成本和性能的平衡。
能够可持续的发展。

The Matrix 2008-06-15 22:05 发表评论

架构设计的思考

The Matrix — Sun, 01 Jun 2008 05:18:00 GMT

    首先需要明白的是，什么是架构设计，看了以前的培训资料，也google了，也自己想了，总结下来：

    架构设计：软件系统是由组件以及它们之间的连接关系组成的，同时架构设计还要满足软件系统的易变性、可扩展性、可维护性等特性。

    搞清楚了什么是架构设计之后，再想想怎么才能做好架构设计呢？

    架构设计可大可小，回顾一下自己做过的项目，细想再小的项目其实也有一个架构设计，只不过这个架构设计可能很小，三言两语就能描述清楚了，比如一个很小的BS系统，可能也要划分一下，功能模块如何划分，哪些是公用的，目录或package如何划分，这个我觉得也是架构设计。

    但是当系统变大时，架构设计就变得复杂了，因为需要考虑的东西就多了，一方面从系统的功能来说，系统功能点已经上百成千个了，光是搞清楚这些功能点就已经不容易了，如何从这些功能点中发掘共性，划分组件，如何设计组件之间的联系，实现分而治之就更复杂了，另一方面，系统变大了，系统的非功能性需求或约束更多了，一个小系统，可能不需要考虑大用户量、并发、大数据量等问题，但一个大系统，即使用户不提这些约束条件，一个好的项目经理或者架构师，必须替用户考虑这些约束条件，有几年的数据以后，系统会不会变慢，采取什么样的方式可以解决这样的问题，用户如果要求5秒内，系统必须有响应，那么目前的架构设计能不能满足这样的要求呢？

    同时从软件系统的架构与建筑设计的类比来看，一个建筑设计，必定是先把建筑结构定下来，然后再按图施工，如果想有创新性的设计，则必须广闻博见，同时还必须功力深厚，否则怎么设计的出鸟巢呢？呵呵

   同样对于一个软件架构的设计者来说，第一个层次，丰富的实践知识，达到这样，至少在一定的范围内可以依葫芦画瓢了，同时还可以有一些局部性的创新设计。
   第二个层次建立在第一个层次的基础上，广闻博见，精通十八般武艺，无论哪种兵器都能使得很趁手，比如BS架构很熟悉，CS架构很熟悉，银行系统的架构设计做过，电信系统的架构见过研究过，嵌入式系统的架构也熟悉，操作系统、数据库等基础知识那更是不用说，至少熟悉多种主流编程语言，还能紧跟潮流趋势，更要有自己的思想，理解能力深厚，这样的大师我想应该能做出创新性的设计了。

    回顾一下自己，只能是第一个层次了，其实第一个层次也不算很好，第二个层次只能算刚刚入门，看来要成为一个大师，很难，@_@

The Matrix 2008-06-01 13:18 发表评论

架构设计

The Matrix — Sat, 31 May 2008 14:54:00 GMT

今天将以前参加的一个架构设计的培训教材拿出来又翻了翻，忽然发现当时培训的教材其实是按照RUP的开发思路来安排的。
首先来看看RUP的核心工作流，分别是：

商业建模（业务建模）
需求
分析与设计
实现
测试
发布
配置与变更管理
项目管理
环境

后面几项与架构设计的关系不大，重点看前面几个：商业建模、需求、分析与设计。
回过头来再看看培训教材的大纲：

架构师必备的全局观
架构设计导论
架构设计过程概览
需求分析 ---- RUP ---- 需求
领域建模 ---- RUP ---- 商业建模
打通软件需求到架构师设计之墙 ---- RUP ---- 需求、分析与设计
概念性架构设计 ---- RUP ---- 分析与设计
细化架构设计 ---- RUP ---- 分析与设计
非功能需求设计方法论 ---- RUP ---- 分析与设计（重点在非功能需求的架构设计）
架构验证 ---- RUP ---- 分析与设计（重点在验证）
UML实践指南
面向对象架构设计
架构模式实践
框架技术实践

除了实践部分与前面概要性的部分之外，其余部分基本可以对应起来。

有时候，会觉得写小说是件容易的事情，设计好大纲，一篇一篇往里填充不就行了么，但是换做真的是自己动笔的话，确万万也写不出来。
架构设计也是如此，简单点说是如此简单：熟悉需求、商业建模、分析与设计。但是真的遇到一个需要实现的系统时，确发现千头万绪，要想做一个好的架构，不是一件容易的事情。

要想做好架构设计，重点还在一个分析，学习架构设计也是如此，那就是得分析开源框架、别人的代码为什么要这么做？要分析我从中可以体会到什么？
架构设计师的知识面一定要广，否则应用面就比较窄了。

说了半天，回头一看，乱七八糟，其实最近在琢磨的一个问题是，如何才能搞好架构设计 ^_^

再想想，这是一个长期工程，需要不断的分析积累。

The Matrix 2008-05-31 22:54 发表评论