软件开发思想之我见

软件开发思想之我见

一

　　虽不敢自诩自己的代码量有多大，但是这丝毫不能压制我对于软件开发的理解。写的代码越多，越发觉面向对象相对于面向过程是多么的优越，就比如简单的jdbc编程，为执行一条解决目标业务的sql语句，往往会搭上更多的诸如加载驱动、获取连接、捕获异常、关闭资源等额外操作，对于初学者而言，反正有的是精力，也会觉得理所当然：有多少个方法，就会有多少个这样额外的东西的身影存在。当这样重复写过两三天后，开始有点反思了，考虑是不是应该把这些重复的、不涉及具体业务的固定步骤提取出来？于是有了JDBC操作数据库的util工具类，把那些一成不变的动作按一定的功能封装为不同的静态方法。这种提取公共代码转为工具类的方法的确解决了燃眉之急，而且还似乎提升了自己的编程内功，但是当用过一两个月后又发现自己的包里充斥着各种各样的util工具类，导致包负荷量的臃肿，更麻烦的是这些特定的util工具类仅仅适合特定的应用场合，还不能在各个api、底层产品间平滑过渡。而你就会开始反思之前的封装办法似乎有点具有**特色主义的封装——虽然符合特定场合的“国情”，但是我们要的是以不变应万变！于是，你就开始尝试着将你对重复工作的封装进一步优化和扩展，反正算法和策略或是业务流程是不变的，何不弄一个为Template，设定好房屋的骨骼架构，留给以后的具体开发仅仅是一个萝卜一个坑的往里填就是了。当这样做过之后，又是一段时间编程中的游刃有余，但是后文似乎还没有完，当你对这些重复功能或业务的封装应用于更大更复杂的场合时，加上你的经验的累积，开始站在更高的软件思想角度来思考这是不是应该把这些东西复合成一个特定的领域解决方案？这样想过之后，你开始将之前那些封装再次进行肢解，应用更健壮、更灵活的设计逻辑和各式的设计模式来进行重新设计——于是，你从混沌未开中开辟了一条领域解决方案，甚至于你打算将之进行开源，这便是一个新的框架的诞生。

　　而这样一个过程，或者说是设计思想的转变，需要时间和代码量的积累。的确，当你对现有的代码进行分析、归纳、总结时，你才会发现很多显而易见或者隐形的问题，这个时候你就会逐渐的反思自己的设计方式的合理性。面向对象的三大特征：封装、继承、多态，从字面上或者理论上是多么的容易理解，但是要在自己的代码中体现，对于刚刚踏入程序开发行列的初学者而言又是何其的难，原因可能有经验不足，在没有多个可供选择的设计方案下，只能依据流程式的思维把功能实现就好；也有可能是因为没有面向对象设计的主动意识；还有可能是在时间和开发成本的约束下，显得有些力不从心。

　　但是无论如何，我认为一种科学的设计思想比编码本身更重要，这就相当于理论指导实践，决策高于执行（很好的执行力在错误的决策下只会自食恶果）。不管是Gof的32种设计模式，还是面向对象的四大原则，亦或是基于UML的RUP等等，这些都是一种指导并实现高效编码的理论思想。值得注意的是，这些设计思想和方式，并不能因为一两本书的字面理解中深刻理解。

　　但是，过分讲求这些条条框框而不具体问题具体分析，便会陷入另一个麻烦：教条主义。话说回来，所谓的最佳实践也就是一个经验的累积加上事实求是（具体问题具体分析），面向过程也好，面向对象也罢，都没有绝对的好坏，这要依具体的情况而言。

二

　　对于项目的分析、设计，在后期开发的时候，以严谨的思维面对计算机没错，但是在分析设计阶段，作为一个程序员很容易陷入系统的角度分析和考虑问题，这其实是很麻烦的。容易导致的结果是，你的后期的代码实现依据了你自己的分析，但是你这种分析没有以一个用户的角度、一个业务人的角度来进行分析，很容易到最终你所实现的系统并不是用户想要的甚至是不能被理解的。那么即使再安全、再高效、再优秀的系统也只能落得个返工的下场。“涉众”决定“系统用户”，“用例”决定“系统实现”。足见用例的重要性，我们尤其在对用例分析的时候，要多站在用户的角度去思考用户是想要实现怎样一个系统或者功能，而不应是急促地跳进系统里去，用数据库的CRUD来向用户拍胸口保证这就是完美解决方案。

三

　　以上是关于我对设计思想的重要性的理解，还有一个很重要的就是关于项目管理方面的一个要注意的地方——专注核心功能的实现，把辅助性的功能放在次要位置！

　　对一个项目，为确保该项目正确地体现设计方案的要求，应该提取出项目的核心功能，并进行着重的开发、监督和控制。像一个基于元数据的数据库管理视图系统，其核心功能应该是三个模块：其一，数据查询；其二，数据编辑；其三，数据库导入导出。虽然系统定义了用户管理、角色分配、日志管理、修改密码等功能，但是它们不是系统的核心，所以在核心功能没有完成或者无法保证其按时、顺利地完成的情况下，应该要减轻对这些次要功能的开发成本的投入。让“核心”的人做核心的事，让大的成本投入于核心的工作。除此之外，对于核心的模块，也应该警惕开发人员一个与生俱来的癖好——遇到哪个问题往往纠结哪个问题，技术人员最喜欢死扣一个心眼儿，纠缠于一个死问题。问题当然是要解决的，而且应该制定专门的问题、bug汇总日志；只是如果站在全局的角度看，我们完全应该暂时“跳过”这个问题，把其他的东西先做着走，之后才回过头来解决它。只有这样，我们的才能够保证项目有序地进行下去。