|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (1) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2013-03-29
Surmounting 写道 yongjie_2008_java 写道 不知道楼主做过管理没有，我个人感觉现在软件行业最大的危机不是系统效率的快慢而是人员流动造成的项目不能按时交付，项目后期维护困难等问题，尤其是中小型公司人员流动非常频繁，一个软件做下来有可能只剩一两个老人，后期维护更是问题，像楼主所说的不使用框架效率确实提高了，但是开发周期恐怕会更长，新人对项目的熟悉时间会更慢，后期维护成本会更高，项目成本可能会成倍增加。而ssh尤其是spring框架正好可以很好的缓解这个问题，spring对bean的工程化管理让项目更加易于管理，而且这个规范可以让很多没有楼主强大的新人能快速适应到项目中来。不是每个人都像楼主这么强大，更多的程序员尤其是现在的程序员都是速成的，没有很深的造诣和扎实的基础，正是软件的工程化管理让软件行业在现在尤其是中国这个国度能快速发展。正如一位高人曾言，软件工程的终极目标就是消灭程序员。所以我个人感觉ssh框架的使用对效率的考虑少一点，更多的是在软件项目工程化管理方面所带来的巨大优势。
本人也是程序员，如果哪些地方说的有问题请轻拍... 之前经历一些项目，对人员流失对软件产品发展的影响确实有不少感触。不过我现在团队的成员，全部都是通过价值观一致判定招聘来的，都是一些在技术上有不少追求的人，相对稳定一些。我觉得，人员流动不可避免，代代口口相传的普遍现象非常可怕。我这边非常重视分析文档和概要设计文档，事实上维护文档的成本确实很高。算下来大概能有 1/3 在这二种文档上。不过我觉得值，这造成几乎没有翻工，也督促了需求提出者的思考，使得需求变更变少了很多。每次改动，程序都是后改的，文档一定先行。所有改动都得经过二个不同的人审批，大家互相审批，既加强了对别人所做内容的了解，也保证了软件质量。事实上在大家都适应分层工作之后，分工也可以打散，并不太影响工作效率的。 而且您说得对，程序员大都是速成的。所以我的工作就是天天给大家上课做培训。针对一些具体的问题。毕竟是企业，用不到的内容只能先不管了。我这边的规范非常细致，从代码文本格式，到类名、方法名、变量名的起名原则、定则，到提取方法的粒度以及原因。因为都有比较充分的道理，所以我这边新人来了接受起来并不慢。当然也和他们都很上进有关吧……我觉得工程学最主要的意义，是让过程可控。虽然 CMMI3 所提倡的内容我这边有很多做不到，但 CMMI5 倡导的过程反馈自修正，我这边却能够实现一些。具体来说就是大家对完成进度有评估汇报，并针对结果修改工作方式。 我觉得你只是在说自己的项目管理多合理、多精细。但是你不能否认框架对软件开发所起的作用，放在一般公司里，你说的这些恐怕都做不多好，那么框架的优势就显示出来了，这也是框架经久不衰的原因。随着硬件越来越质优价廉，效率造成的影响只会越来越小了，2G内存不够，我加20G内存，可以了吧？20G内存才多少钱，但是我如果项目推迟的话，我的损失会多大，明白人恐怕都能算清楚了 |
| 返回顶楼 | |
|
发表时间：2013-04-13
yuyue007 写道 Surmounting 写道 可能是我无知了…… 不过 Spring 执行一个方法，比直接调用执行，慢 700 倍；这个是实测出来的。并且不是一次运行，而是多次。 我现在怀疑其实主要慢可能也不全是反射造成的，而是检查有没有切片。 为了避免记忆错误，我又做了个实验。实验代码如下。我这个类叫 GetAnnounceFunc ，您看，这还是相当公平的。
static public void main(String... arguments) throws Exception
{
int times = 50000000;
Class<GetAnnounceFunc> c = GetAnnounceFunc.class;
GetAnnounceFunc obj = c.newInstance();
Method m = c.getMethod("getName");
long start = System.currentTimeMillis();
for (int index = -1; ++index != times; ) obj.getName();
System.out.println(System.currentTimeMillis() - start);
start = System.currentTimeMillis();
for (int index = -1; ++index != times; ) m.invoke(obj);
System.out.println(System.currentTimeMillis() - start);
}
public String getName()
{
return "xp";
}
这在我的开发环境中，测试结果 31 3735 相差了 100+ 倍。 我也是属于不太喜欢框架的，但是感觉你要求稍微有点苛刻了。在你这个例子里面做了一个千万级别的操作，带来的影响是3秒，平摊下来是在一个可以接受的范围内。而且在短时间遇到这样大量的操作还是比较少见的。但是带来的后期的可维护性，却是成倍的提升。 另外，感觉你1楼的回答是有意留了一些包袱，等面试官追问，验证下是不是这样，还我想多了。。 怎么说呢……所谓性能，我总觉得，利用场景不同，要求的也不一样。我现在是做服务器的，对于服务器来说，性能好与不好，一般不体现在耗时的值上，而是几种方案的耗时比例。比如 1ms 和 3ms 这是三倍的运行耗时，虽然都很短，但意味着前者使用的系统计算资源，是后者的三分之一。而 120s 和 150s 的二种方案，虽然耗时都很长，但相差不大，所以消耗的系统计算资源接近，虽然改变方案能提高 30s 运行速度，还是没什么必要进行修改。 五千万，很多吗？对于弱连接的服务器，10 0000 人同时在线并不是不需要。这个时候每个人带来的运算有 500 个方法调用，就是五千万次方法调用。标准的长连接服务器，咱们再不考究，一台和家用 PC 性能接近的服务器，怎么也得维护 1000 人同时在线吧？你想想，随便调用一个方法，里边用几次工具，做几个对象，就是多少次方法调用？1000 人同时在做这些事情，还希望系统能够有较强的“即时性”。这就是性能的要求。 最开始对面试官的回答，我觉得一定程度的技术骄傲是应该的。只要这种骄傲不要成为听不进别人不同思路观点的障碍就行。那么面试的时候，表达自己的这种骄傲，就会在你观察到的地方体现成话没有说完留了包袱。接下来面试官有可能会追问，我就可以继续发挥；面试官不感兴趣，我们也不算互相浪费了时间。 :-) |
| 返回顶楼 | |
|
发表时间：2013-04-13
yongjie_2008_java 写道 Surmounting 写道 yongjie_2008_java 写道 不知道楼主做过管理没有，我个人感觉现在软件行业最大的危机不是系统效率的快慢而是人员流动造成的项目不能按时交付，项目后期维护困难等问题，尤其是中小型公司人员流动非常频繁，一个软件做下来有可能只剩一两个老人，后期维护更是问题，像楼主所说的不使用框架效率确实提高了，但是开发周期恐怕会更长，新人对项目的熟悉时间会更慢，后期维护成本会更高，项目成本可能会成倍增加。而ssh尤其是spring框架正好可以很好的缓解这个问题，spring对bean的工程化管理让项目更加易于管理，而且这个规范可以让很多没有楼主强大的新人能快速适应到项目中来。不是每个人都像楼主这么强大，更多的程序员尤其是现在的程序员都是速成的，没有很深的造诣和扎实的基础，正是软件的工程化管理让软件行业在现在尤其是中国这个国度能快速发展。正如一位高人曾言，软件工程的终极目标就是消灭程序员。所以我个人感觉ssh框架的使用对效率的考虑少一点，更多的是在软件项目工程化管理方面所带来的巨大优势。
本人也是程序员，如果哪些地方说的有问题请轻拍... 之前经历一些项目，对人员流失对软件产品发展的影响确实有不少感触。不过我现在团队的成员，全部都是通过价值观一致判定招聘来的，都是一些在技术上有不少追求的人，相对稳定一些。我觉得，人员流动不可避免，代代口口相传的普遍现象非常可怕。我这边非常重视分析文档和概要设计文档，事实上维护文档的成本确实很高。算下来大概能有 1/3 在这二种文档上。不过我觉得值，这造成几乎没有翻工，也督促了需求提出者的思考，使得需求变更变少了很多。每次改动，程序都是后改的，文档一定先行。所有改动都得经过二个不同的人审批，大家互相审批，既加强了对别人所做内容的了解，也保证了软件质量。事实上在大家都适应分层工作之后，分工也可以打散，并不太影响工作效率的。 而且您说得对，程序员大都是速成的。所以我的工作就是天天给大家上课做培训。针对一些具体的问题。毕竟是企业，用不到的内容只能先不管了。我这边的规范非常细致，从代码文本格式，到类名、方法名、变量名的起名原则、定则，到提取方法的粒度以及原因。因为都有比较充分的道理，所以我这边新人来了接受起来并不慢。当然也和他们都很上进有关吧……我觉得工程学最主要的意义，是让过程可控。虽然 CMMI3 所提倡的内容我这边有很多做不到，但 CMMI5 倡导的过程反馈自修正，我这边却能够实现一些。具体来说就是大家对完成进度有评估汇报，并针对结果修改工作方式。 我觉得你只是在说自己的项目管理多合理、多精细。但是你不能否认框架对软件开发所起的作用，放在一般公司里，你说的这些恐怕都做不多好，那么框架的优势就显示出来了，这也是框架经久不衰的原因。随着硬件越来越质优价廉，效率造成的影响只会越来越小了，2G内存不够，我加20G内存，可以了吧？20G内存才多少钱，但是我如果项目推迟的话，我的损失会多大，明白人恐怕都能算清楚了 这个回答确实是针对软件制作理念的。您看啊，并不是所有项目都很短命，也有不少项目经历了很多代的维护升级重做。只能做短命项目的公司，竞争力真比不过能把服务一直做下去的，这个咱们都能看到，对吧。 那么对于一个长期的项目，真正的大损耗在哪儿呢？一个就是重做的成本，另一个就是改进的时候不知道以前做的都是什么东西。以上的人工开发费用是最大的消耗，既不是第一次开发的人工费，也不是软硬件消耗。 因为看到了这一点，咱们才能够知道，真正的效益，是花费大量精力，让后人能够比较容易地明白之前的软件是咋回事儿。如果项目能维持较长时间，那么上述这种工作，是能带来长期最大利益的事情，无论是对甲方还是开发商。可是通过这些年的观察，我发现，越滥用现成的框架，越难以留下软件怎么做成的记录。能够让后人了解软件是怎么回事儿，需要记录设计思路，记录需求变更过程，记录前人的分析方向习惯，以及代码表现出来现有样子的原因。这些工作所需要的精神支持，都和不负责任为了临场解决问题滥用框架的精神不一致。太多程序员觉得以上工作没有意义。为了改变这种想法，就得从要做什么事情先想好，留痕迹入手做起。在这种指导思想下，会发现不是不用框架，也不是滥用，而是在该用的时候选择合理的。 想要改变，所以观察；所以努力去做自认为能改变自己看到的根源的事情。我的影响力只局限在很小的圈子，但我却没有放弃。我现在在游戏界。中国游戏界服务器开发，更是毫无记录可循，无规范的代代口口相传。我在这样的环境中，坚持我的坚持而已。自己看的不准，自然也希望能够从大家身上找准问题，进一步改正啊…… |
| 返回顶楼 | |
