为了年终奖，我还委屈自己留一个月

sdfffffffffffff

评论

124 楼 wan_2004 2010-12-28  

lz这公司在武汉算是还行了  

123 楼 skyHuang 2010-12-28  

hatedance 写道

项目经理无能，项目做了三个多月，推倒重新整理需求文档；技术选型变了又变，从ext到jquery等；传说这人还是在广电行业做了八年的。技术我不说了吧，业务总该会点吧，可是上面提到的需求文档翻新，可想而知业务水到什么地步。
--需求推倒重来很正常，不一定是项目经理个人的原因。更糟的是不推倒，做完项目，结果发现没人要用。你们的需求是项目经理一个人分析的吗？

详细设计是这样写的：实现对运营商的增加，修改，删除，查询功能。
--这个的确是不需要更详细了，尤其适合一些所谓基础信息的增删改。但如果都是这样描述需求，我感觉缺少业务知识，是在闭门造车。

异常处理，所有异常封装，一层层的往上抛，知道最上层(当然不是jsp啊)。然后统一处理，写日志等。调试的时候想要看看是那个地方报错，无法查看，不能得到最原始的异常信息和位置。要从con开始一个方法一个方法的跟进。
--异常处理，本该如此。如果要看最详细的信息，可以嵌套/包含原始异常。

问题就在控制层和业务层之间的调用；各位看官，请注意了，这是重点，这边的高人是每个模块新建一个class，用来发布远程接口，里面方法少则几十多则几百，平均每个模块的这个大接口(他们是这么叫的)拥有最少100个方法。
--业务层暴露给展现层的接口，本来就很多，这也是没办法，只要名字取的好理解一些就可以了。可以考虑引入facade模式。如果是远程调用，就要注意接口的粒度，大一些效率高一些。

组织机构从理论上来说是无限级别的树结构，我开发的时候做了这样一个方法，不管数据库加多少级别，都能够随心所欲的在界面展示，很简单嘛，一个递归搞定了，然后“架构师”级别的那个人队我说，我这有效率问题，他是怎么做的呢，判断嘛，客户需要几级就是几级吗，if***=1，if***=2，如此如此。我有点惊愕，暂时没想到更好的形容词，大家可以尽情的发挥想象力来模拟我当时的表情。人家毕竟是个副PM，你说咋的就咋的吧。神马都是浮云，这算什么，是吧！
--如果组织结构够大，一次读取上万条数据也够慢。但用if的确有点hard code了，但按需读取数据的确能提高了效率,即展开一个节点就读取所需的数据。

异步获得数据我觉得是最好的方法了，，
可是Y的不那么做啊  非要一次拿光。。


送上PM的一些经典话语：

1.客户不可能有这样的需求的，我们没必要这么做。
2.广电的人都是SB，不懂这些东西，我们按我们的方式做就行了。
3.你提的建议很好，但是我们现在不需要这么做，今后在完善！
4.你们周末都来加班啊，我有事不来了。

122 楼 hbdzhm 2010-12-28  

似乎这种类型的公司很多。。。

121 楼 hatedance 2010-12-28  

项目经理无能，项目做了三个多月，推倒重新整理需求文档；技术选型变了又变，从ext到jquery等；传说这人还是在广电行业做了八年的。技术我不说了吧，业务总该会点吧，可是上面提到的需求文档翻新，可想而知业务水到什么地步。
--需求推倒重来很正常，不一定是项目经理个人的原因。更糟的是不推倒，做完项目，结果发现没人要用。你们的需求是项目经理一个人分析的吗？

详细设计是这样写的：实现对运营商的增加，修改，删除，查询功能。
--这个的确是不需要更详细了，尤其适合一些所谓基础信息的增删改。但如果都是这样描述需求，我感觉缺少业务知识，是在闭门造车。

异常处理，所有异常封装，一层层的往上抛，知道最上层(当然不是jsp啊)。然后统一处理，写日志等。调试的时候想要看看是那个地方报错，无法查看，不能得到最原始的异常信息和位置。要从con开始一个方法一个方法的跟进。
--异常处理，本该如此。如果要看最详细的信息，可以嵌套/包含原始异常。

问题就在控制层和业务层之间的调用；各位看官，请注意了，这是重点，这边的高人是每个模块新建一个class，用来发布远程接口，里面方法少则几十多则几百，平均每个模块的这个大接口(他们是这么叫的)拥有最少100个方法。
--业务层暴露给展现层的接口，本来就很多，这也是没办法，只要名字取的好理解一些就可以了。可以考虑引入facade模式。如果是远程调用，就要注意接口的粒度，大一些效率高一些。

组织机构从理论上来说是无限级别的树结构，我开发的时候做了这样一个方法，不管数据库加多少级别，都能够随心所欲的在界面展示，很简单嘛，一个递归搞定了，然后“架构师”级别的那个人队我说，我这有效率问题，他是怎么做的呢，判断嘛，客户需要几级就是几级吗，if***=1，if***=2，如此如此。我有点惊愕，暂时没想到更好的形容词，大家可以尽情的发挥想象力来模拟我当时的表情。人家毕竟是个副PM，你说咋的就咋的吧。神马都是浮云，这算什么，是吧！
--如果组织结构够大，一次读取上万条数据也够慢。但用if的确有点hard code了，但按需读取数据的确能提高了效率,即展开一个节点就读取所需的数据。

120 楼 skyHuang 2010-12-28  

zhxing 写道

引用

原始异常被包装后传到最顶层。。

问题是

能处理的不处理

日志记录也到处理为之才做

能恢复的异常，当然可以在方法中处理，不用向上抛了。。但能处理的异常在开发中都不多吧。。不能处理的异常，必须向上通知。。然后再顶层，一般在控制层做同一处理。。

说个很简单的例子

在使用对象之前我们一般都会判断是否为null，现在是怎么样的呢


他们直接使用，不做判断，然后由异常就抛出去！


这就是我最郁闷的地方！

119 楼 zhxing 2010-12-28  

引用

原始异常被包装后传到最顶层。。

问题是

能处理的不处理

日志记录也到处理为之才做

能恢复的异常，当然可以在方法中处理，不用向上抛了。。但能处理的异常在开发中都不多吧。。不能处理的异常，必须向上通知。。然后再顶层，一般在控制层做同一处理。。

118 楼 skyHuang 2010-12-28  

zhxing 写道

cheer1l1lg 写道

aws 写道

sunrisetg 写道

代码：异常处理，所有异常封装，一层层的往上抛，知道最上层(当然不是jsp啊)。然后统一处理，写日志等。调试的时候想要看看是那个地方报错，无法查看，不能得到最原始的异常信息和位置。要从con开始一个方法一个方法的跟进。

楼主，我觉得这个模式很好，毕竟是给客户看的，不是给开发调试的。
以前就是这种异常处理模式，现在接手的项目，事务控制都没加进去。。。。
所以我是非常怀念当时那种规范异常处理，统一跳到指定页面，展示你定义的错误。

这个设计是是对的，但是在最顶层应该区分出开发模式生产模式，开发模式还是需要打印堆栈以方便程序员定位，生产模式只写日志或者调用统一的界面就行了，隐藏具体的错误信息

不对吧，先不说异常控制流程了，光是堆栈信息很多都是无用的。感觉应该是在出错的地方记日志，返回值对象，值对象里面包含一个object返回对象和异常信息(资源文件对应)或者其它一些信息

在出错的地方记日志，返回值对象。。这样搞和异常没多少区别，而且还更麻烦。。如果方法本身有返回值。那就更麻烦。。这个异常本身就不应该很多。。所以没必要另外搞一套。。

异常这东西怎么去处理也没有一定之规

每个项目处理方式不同可以理解

但总的来说应该合理

117 楼 zhxing 2010-12-28  

cheer1l1lg 写道

aws 写道

sunrisetg 写道

代码：异常处理，所有异常封装，一层层的往上抛，知道最上层(当然不是jsp啊)。然后统一处理，写日志等。调试的时候想要看看是那个地方报错，无法查看，不能得到最原始的异常信息和位置。要从con开始一个方法一个方法的跟进。

楼主，我觉得这个模式很好，毕竟是给客户看的，不是给开发调试的。
以前就是这种异常处理模式，现在接手的项目，事务控制都没加进去。。。。
所以我是非常怀念当时那种规范异常处理，统一跳到指定页面，展示你定义的错误。

这个设计是是对的，但是在最顶层应该区分出开发模式生产模式，开发模式还是需要打印堆栈以方便程序员定位，生产模式只写日志或者调用统一的界面就行了，隐藏具体的错误信息

不对吧，先不说异常控制流程了，光是堆栈信息很多都是无用的。感觉应该是在出错的地方记日志，返回值对象，值对象里面包含一个object返回对象和异常信息(资源文件对应)或者其它一些信息

在出错的地方记日志，返回值对象。。这样搞和异常没多少区别，而且还更麻烦。。如果方法本身有返回值。那就更麻烦。。这个异常本身就不应该很多。。所以没必要另外搞一套。。

116 楼 skyHuang 2010-12-28  

zhxing 写道

引用

异常处理，所有异常封装，一层层的往上抛，知道最上层(当然不是jsp啊)。然后统一处理，写日志等。调试的时候想要看看是那个地方报错，无法查看，不能得到最原始的异常信息和位置。要从con开始一个方法一个方法的跟进。

这个我不觉得有问题。。异常不能处理的肯定要向上抛了。。然后统一处理，很正常。。一层层往上抛的异常，异常堆栈有原始堆栈信息吧。。除非重新向上抛出新的异常没传原始异常进去。。

原始异常被包装后传到最顶层。。

问题是

能处理的不处理

日志记录也到处理为之才做

115 楼 zhxing 2010-12-28  

引用

异常处理，所有异常封装，一层层的往上抛，知道最上层(当然不是jsp啊)。然后统一处理，写日志等。调试的时候想要看看是那个地方报错，无法查看，不能得到最原始的异常信息和位置。要从con开始一个方法一个方法的跟进。

这个我不觉得有问题。。异常不能处理的肯定要向上抛了。。然后统一处理，很正常。。一层层往上抛的异常，异常堆栈有原始堆栈信息吧。。除非重新向上抛出新的异常没传原始异常进去。。

114 楼 skyHuang 2010-12-28  

newwpp 写道

感同身受啊

113 楼 newwpp 2010-12-28  

感同身受啊

112 楼 skyHuang 2010-12-28  

umeit 写道

skyHuang 写道

eric860 写道

不就1个月嘛，眨眼就过去了。

恩 我也是这么想的  可有的时候想想话不投机半句都多  我这还有一个月   煎熬ing。。。

熬熬吧，我也在熬。。。

大家一起熬。。

111 楼 umeit 2010-12-28  

skyHuang 写道

eric860 写道

不就1个月嘛，眨眼就过去了。

恩 我也是这么想的  可有的时候想想话不投机半句都多  我这还有一个月   煎熬ing。。。

熬熬吧，我也在熬。。。

110 楼 skyHuang 2010-12-28  

yidao620c 写道

好吧，在武汉读了四年书，我原本还想回武汉的。看了lz的帖子，现在暂时取消这个念头了。^_^

很有觉悟

我从深圳回武汉就是个错误

不过离开深圳是正确的

109 楼 yidao620c 2010-12-28  

好吧，在武汉读了四年书，我原本还想回武汉的。看了lz的帖子，现在暂时取消这个念头了。^_^

108 楼 skyHuang 2010-12-28  

cheer1l1lg 写道

aws 写道

sunrisetg 写道

代码：异常处理，所有异常封装，一层层的往上抛，知道最上层(当然不是jsp啊)。然后统一处理，写日志等。调试的时候想要看看是那个地方报错，无法查看，不能得到最原始的异常信息和位置。要从con开始一个方法一个方法的跟进。

楼主，我觉得这个模式很好，毕竟是给客户看的，不是给开发调试的。
以前就是这种异常处理模式，现在接手的项目，事务控制都没加进去。。。。
所以我是非常怀念当时那种规范异常处理，统一跳到指定页面，展示你定义的错误。

这个设计是是对的，但是在最顶层应该区分出开发模式生产模式，开发模式还是需要打印堆栈以方便程序员定位，生产模式只写日志或者调用统一的界面就行了，隐藏具体的错误信息

不对吧，先不说异常控制流程了，光是堆栈信息很多都是无用的。感觉应该是在出错的地方记日志，返回值对象，值对象里面包含一个object返回对象和异常信息(资源文件对应)或者其它一些信息

正解！我觉得也是这样的！

107 楼 cheer1l1lg 2010-12-28  

aws 写道

sunrisetg 写道

代码：异常处理，所有异常封装，一层层的往上抛，知道最上层(当然不是jsp啊)。然后统一处理，写日志等。调试的时候想要看看是那个地方报错，无法查看，不能得到最原始的异常信息和位置。要从con开始一个方法一个方法的跟进。

楼主，我觉得这个模式很好，毕竟是给客户看的，不是给开发调试的。
以前就是这种异常处理模式，现在接手的项目，事务控制都没加进去。。。。
所以我是非常怀念当时那种规范异常处理，统一跳到指定页面，展示你定义的错误。

这个设计是是对的，但是在最顶层应该区分出开发模式生产模式，开发模式还是需要打印堆栈以方便程序员定位，生产模式只写日志或者调用统一的界面就行了，隐藏具体的错误信息

不对吧，先不说异常控制流程了，光是堆栈信息很多都是无用的。感觉应该是在出错的地方记日志，返回值对象，值对象里面包含一个object返回对象和异常信息(资源文件对应)或者其它一些信息

106 楼 skyHuang 2010-12-28  

weihn 写道

不怕有狼一样的敌人，就怕有猪一样的队友。这句话挺适合现在的楼主。哈哈。

其实我也就一小咯咯


队友水平都一般

差距不大

技术上来说他们可能还厉害些

我就是做的大项目多点

去过的地方多点   见到的人多点而已

105 楼 weihn 2010-12-28  

不怕有狼一样的敌人，就怕有猪一样的队友。这句话挺适合现在的楼主。哈哈。