在项目修改过程中永远要保证可运行版本

刚刚上来写篇博文，看到了《我心中的商用化开发》征文公告。看了肖老师老师的几篇文章，获益匪浅。

其实如果不是这个商用化开发的公告，我也会写这篇博文，来鞭笞自己。提醒自己，随时注意在项目开发中注意，可运行版本这个概念。

昨晚，被我们老大狠狠的教训了一顿。

 我先说下我现在的状况。我们的java team不大，一直在开发自己的商业信息平台的。从平台的开始到现在，陆陆续续来了一些人，也走了一些人。基本上，从框架的搭建到现在二期维护，除了老大做一些架构的调整工作，剩下的细微调整，从架构到业务的需求和代码编写都是由我来调整。

前些日子，我做了个struts2 Convertion和spring annotation的可行性报告后，老大决定将平台原来struts2的xml配置改成convertion。

我嫌一个个功能改太麻烦，要不停的重启服务器做功能测试，先将所有Action改成convention的形式，然后再改jsp页面。导致最后，整个平台的后台管理的很多链接失效。

其实，老大在我改的时候，已经强调了，要一个一个功能的改。任何时候保证有一个可运行版本。。但是我就是没听。他狠狠骂了我一顿后，然后让我想为什么。

我知道，can run version的概念自己没有把握好。商业化开发的概念没在自己心中牢牢巩固。

晚上，做老大的车回家，他说，虽然我们现在不是做项目。但如果真的赶项目的话，如果客户让你明天给他一个版本，那你死活给不了的。因为，你一头扎到了修改Action文件中，你要是跟客户说，现在在修改Action文件？所以影响了进度？那你准备扣钱吧。。客户不会管你这个的。

回去想想，也是。任何时候保证可运行版本，真的很重要。特别是在商业化开发中

1.在修改中如果以功能为单位修改，无论什么时候都能得到一个可运行版本。

2.按功能修改，有利于其他人进入团队，能根据已修改功能作为demo去进行其他模块的修改。

有点儿离题。。呵呵，现在就自己的理解，说说自己在工作中的所谓的商用化开发。

1.在商业化开发中，永远保持可运行版本。

2.商业化开发不是新技术的战场和试验场所。

    有时候，自己很喜欢用新的技术，新的方法注入到现行的项目中。什么都想试试新。如，之前用的Fckeditor(网络文本编辑器)，后来知道出了Ckedtor（fckeditor的升级版），就开始蠢蠢欲动了。和老大沟通后，被他拦了下来。原因很简单，现时的编辑器基本能解决问题没有必要换。我说，没事啊，就2，3天的时间。他最后说的一句话，让我很有感触，他说，你关注的是时间，那么我问你，折合下来的修改成本是多少呢？什么新技术也好，你可以去做。但是做的时候，首先要你能handle它，然后写一份教程，一份可行性报告。因为，你要是提它出了，那别人有什么问题当然找你了。你必须handle它。二，教程是为了让新进的同事能快速的掌握它，三，可行型报告是为了综合下现时的情况，其他同类技术，做个对比才能“动手”的。

3.商业化开发需要每一个程序员要有一个share的习惯

     一个教程，一个想法，一个新技术的触角。。。很多人都喜欢把一些“小窍门”藏起来，作为自己的一个竞争力。这在开发中其实是很不利的。比如，A在开发时，需要学习jquery，他用了3天，那么他将自己的笔记整理了5页笔记，全部藏起来了，下次，B在开发中又要用到jquery，那么难道又要给他3天时间吗？那整个项目期限就都浪费在了学习上了，那么 我们就需要让A也好，自己也好，将自己3天学到的东西写成笔记share出来。这样，帮助别人，利于团队。也减少了项目的学习时间。何乐不为呢？

4.商业化开发需求不是你订的

    有很多时候，有些顾客会按照自己的一些想法提出一些“实体属性”，虽然你认为不合适，但是你千万不要改。虽然一些你看着不符合实际情况的属性也好，关系也好。你做就是了。。没有关系的。我们在开发中，经常会过分的为顾客考虑，总想着，这个需求怎么行，根本没有道理的。什么什么的。。其实，很多时候，需求，特别是我们做商业平台的，都是由业务决定你需求的去向。不要轻易的提问题。即便它有问题。。

好了，就写这么多了。。。呵呵，还有很多想法，但是不能写了因为

5.商业化开发不是你的聊天，看文章了解新技术的过程。 很多人都喜欢不读书，看“聊效”。。我反对这种行为。呵呵

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Beacher_Ma/archive/2009/11/24/4863003.aspx