软件工程
关于软件工程理论、实践、感想
摘要: 在我现在的项目中出现了这么两个问题，大家可以来探讨下这样的两个问题的解决方法，:)
1、从开发环境到正式环境的部署/校验非常麻烦；
2、数据库的频繁移植/校验非常麻烦。
我的解决方法：
对于上面两个问题，我自己想到的解决方法是：
1、建立持续集成机制，编写环境部署脚本和文档，采用这两种方法可保证从开发环境到正式环境的部署是非常简单的；
编写自动验收测试脚本，可以基于selenium进行编写，这样每次在升级版本的时候就不需要再人工的进行回归测试了，这里面的问题是如何在测试完毕完毕后清除这些测试数据，因为这些测试数据是不能和正式数据共存的。
2、建立数据库升级移植机制，每次升级时做增量的升级，不过这需要建立在对原库建立版本记录，这个方法对于我们的项目而言不太可行；
第二种方案就只能每次进行全面的重新移植了，但这个带来的一个巨大问题就是存储过程的重复修改，目前我还没想到什么解决方法，而且；
至于如何校验数据库移植是否成功，我觉得可以建立数据库移植校验的checkpoint，除了保证数据库结构、数据量等的
摘要: 最近用了下在php业界中非常出名的wordpress和mambo，使用下来的感觉就是这两个东西易用性真的太好了，功能方面同样非常的强大，实在想不出java界的cms哪个能和它们进行对比的，引发自己的一些思考，java界的技术人员特别容易以技术观点去评价一个东西的好坏，觉得这就是为什么java界的论坛、cms这种东西总是无法和其他语言体系的相比的原因，并不是说java界就真的做不出象mambo这样易用的cms。
摘要: 之前公司招高程，估计面试了不下30个人，觉得面试别人其实也是一种乐趣，和各种不同的人聊天会让自己也学到很多，而且由于还是面试阶段，会更容易进行没有隔阂的技术交流，每次面试其实我都觉得是一次很好的技术交流机会，所以我很乐意面试，同时我也希望被我面试的人能够享受着这种感觉.....
摘要: 以前的自己一直认为做技术化性质的框架、产品是自己的职业发展之路，逐渐的慢慢而改变，发现以前的自己很陷入技术，不断的追求技术，而忽略了软件的本质，软件的本质是为了提高在某种工作上的效率，其实就是让业务能够更高效的完成，而要做到这一点，依赖的重点并不是技术，而是对业务的理解以及将业务转化为电脑化操作的能力，而这点是非技术能解决的，在业界可以看到很多公司，象浪潮，它在烟草行业的成功让人叹服，从技术人员的角度去看它的系统可能会觉得不过尔尔，技术人员往往会认为自己要做出一套这样的系统来不过是小菜而已，但事实是如果让你现在进入烟草行业，也许你做出来的系统从技术上是超越了浪潮，但从业务的理解上以及转化为电脑化操作的能力上能超越浪潮吗？这个不是一两年的业务积累就够的，^_^，从现在国内的软件业界的情况来看，我觉得大部分技术人员的最佳发展方式还是深入理解业务，这才是自己的优势，同时掌握将业务转化为技术的能力，这样的技术人员必将是强势的，这样做出来的东西才是有足够的竞争力的，软件是面向服务的，^_^，不要忘记了这一本质。
技术只是一种辅助而已，切勿反客为主.......
摘要: 每个团队都有它更为适合的软件工程，因此不可一概而论，谈谈自己对于xp以及重型软件工程象cmm这种更为适合的团队。
摘要: 想改良一个烂设计为好设计吗？想增加或维护代码功能时更加简单吗？重构无疑是其中最好的方法之一，既然它是好的，我们就要把它发挥到极限，把重构发挥到极限的方法就像kent beck说的，采用两顶帽子的原则，工作中不断的交换帽子，^_^
摘要: 既然测试是好的，那就把它发挥到极限。
测试是好的，这一点无可厚非，几乎做软件的人都是认可的，本篇只是谈谈测试中的单元测试部分，单元测试的目的是为了保证类中的方法是符合设计时的需求的，需求驱动似的类实现，^_^
摘要: 既然认为它是好的，就要发挥到极限，这是xp的思想。
持续集成无疑是一种非常好的方法，那么在实际的软件开发过程中就应该把它的好发挥到极限，但就我自己经历过的项目以来，只在一个项目中真正的较好的实现了持续集成，不知道大家的情况是怎么样？持续集成的最出名的代表还是ms的daily build和冒烟测试了。
摘要: 如何保证软件的质量一直就是令人头疼的事，这里列了一个自己实际运作的一套用于保证软件质量的方法，还望大家多加指点。
摘要: 昨晚看切尔西的比赛的时候突然联想到了软件开发，呵呵，来看足球赛：
1、根据比赛双方的实力、主客场、天气等等各方面因素来比赛双方都会制定自己的目标，战平、胜或别的目标。
2、需要在有限的时间内(90分钟)达成目标。
3、多种角色构成。(守门员、后卫、中场、前锋)
4、一定的阵型(4-3-3、4-4-2)和战术(防守反击、短传渗透、长传冲吊)。
5、多变的形式以及多种不定因素(裁判、球员状态等)。
摘要: 对目前一个项目的分析。
摘要: 项目的第一迭代结束，在此对整个过程中team的表现做的一个总结和分析。
摘要: 在项目中正式的执行xp中的过程，除了pp由于暂时没实施，其他的都在实施中，虽然这点会被很多xper说，^_^，其实我也知道pp非常好，毕竟以前经历过，但由于某些原因，在现在的team中我还不好去执行，以后找到机会，呵呵.....
自己接触xp说起来也有两年多了，而且在以前的团队中也是采用这样的过程，但现在自己带team真的执行的时候却发现碰到一些问题，一方面可能是因为自己太久没温习xp，^_^，有些过程都不是那么记得了，另一方面是在执行的时候有些步骤确实不好走，在这样的情况下，回顾了手头的几篇xp的文档，从xp中对于整个软件过程的推行来看自己实施过程中的问题。
摘要: 本来作为客户而言，它需要关心的是自己想基于系统做什么，实现什么样的功能，而不会关心到技术层面，但如果碰到了关心技术的客户怎么办呢，客户关心到你用的是什么平台、什么框架、为什么要用以及它如果要基于平台做自主开发要怎么做，感觉在这种情况下挺棘手的，客户往往就变成了对于你实现需求的技术进行干预，而很多时候又没法向用户解释清楚，而且在这种情况下往往是客户根据你的介绍和讲解来做出基于这样的平台是否能实现他们需求的评估，这就挺难搞了，也许是自己的技术不过关，不过觉得最缺乏的是沟通的方法，大家觉得在这种情况下会有什么比较好的方法呢？求教.......
摘要: 从公司级来讲，自己的资格是远远的不够，在这里主要也是根据自己的项目经验阐述下自己对中小型企业技术团队的一种观点，个人觉得对于中小型企业来讲三级团队的构成是比较理想的，就是支撑平台团队 应用系统开发团队 实施团队，从三级团队的构成来讲切忌企业的面铺的太广，那这三级团队就很难形成了，但在国内大部分中小型企业仍然处于盈利为上的策略，这也是没办法的，毕竟求生才是最重要的，在这种情况下，我觉得在这样的公司不如干脆由应用系统开发团队 实施团队来组成，而支撑平台则选用开源的或进行采购，当然，选用开源的概念是某个可直接用的或者不需要进行太多集成工作的，这样在公司发展到一定程度的情况下，在适当的时机下再进行升级到三级团队的建设。
"));