阿里巴巴 危机中的面试，5年开发经验后不能确定的答案！高手来看看。。。

Question

1.不需要,开发人员根据具体需求调整,如果是瀑布模型需要考虑参数设计范畴
2.代码白盒测试,或者提供文档给对应测试组,由未接受开发的人员进行黑盒测试
3.需要考虑,js,css会影响到客户端IE的内存和CPU的消耗
4.不需要,文档查看没有意义,直接查看数据模型即可

Answer 1

1.不需要,开发人员根据具体需求调整,如果是瀑布模型需要考虑参数设计范畴
2.代码白盒测试,或者提供文档给对应测试组,由未接受开发的人员进行黑盒测试
3.需要考虑,js,css会影响到客户端IE的内存和CPU的消耗
4.不需要,文档查看没有意义,直接查看数据模型即可

Answer 2

3   需要考虑,js,css会影响到客户端IE的内存和CPU的消耗 
        我不同意。    UI上的开发人员使用JS来控制什么，，设计人员很难去设计好。4。不需要,文档查看没有意义,直接查看数据模型即可
    我不同意。
    如果文档开发人员不看的话，那怎么去做开发啊。

Answer 3

来点深度的。解释下。CSDN的高手都在那里？

Answer 4

如果是我的话,我会这样回答:
1,是.但同时允许开发人增加函数或方法.
2,做个简单的Demo.或TDD
3,使用JS库或框加可以在设计时考虑.具体的JS需要规范即可
4,可以.同时增加点说明

Answer 5

DEMO无法验证我们自己的设计。真的。。DEMO可以验证功能实现，
但是伸缩性，扩展性，业务逻辑。怎么验证？JS部分，我感觉属于测试的时候需要注意的问题，不是设计问题

Answer 6

应该没什么标准答案，很显示是系统设计，不是概要设计和详细设计，
第一个问题让我感觉就是有问题的。
在系统设计中肯定不是设计接口或类图，只会讲述模块分法，使用什么框架，具体业务流程。。
1。系统设计是否需要把每个函数的参数都确定，确定参数属于设计的范畴吗？
这里的函数应该改为接口，而且这个工作不会在系统设计里面做。
  2。如何验证我们自己的设计？ 
这个应该不容易，具体的应该是，是否针对你前期的需求分析文档是否全部实现，没有实现的是否有标注，可能会动态变更的你采取了那些具体措施。。你选择的框架和流程是否可以完全实现，是否有更好的实现方法？ 3。页面上的UI控制，比如JS控制属于系统设计需要考虑的范畴吗？ （系架在角色分析的时候要对UI有概括说明）
            4。复杂的查询 是否需要在设计的时候把表关系图写在文档上？开发人员看文档这样是否方便？
（如果系架与数据库设计一起做的话最好有提供，表关系图—ER图是必须在每个开发人员手上的，开发人员在理解自己要开发的模块和流程时应该容易看懂这文档）
很显然这个工作是一兼多职

Answer 7

应该没什么标准答案，很显示是系统设计，不是概要设计和详细设计，
第一个问题让我感觉就是有问题的。
在系统设计中肯定不是设计接口或类图，只会讲述模块分法，使用什么框架，具体业务流程。。
1。系统设计是否需要把每个函数的参数都确定，确定参数属于设计的范畴吗？
这里的函数应该改为接口，而且这个工作不会在系统设计里面做。
  2。如何验证我们自己的设计？ 
这个应该不容易，具体的应该是，是否针对你前期的需求分析文档是否全部实现，没有实现的是否有标注，可能会动态变更的你采取了那些具体措施。。你选择的框架和流程是否可以完全实现，是否有更好的实现方法？ 3。页面上的UI控制，比如JS控制属于系统设计需要考虑的范畴吗？ （系架在角色分析的时候要对UI有概括说明）
            4。复杂的查询 是否需要在设计的时候把表关系图写在文档上？开发人员看文档这样是否方便？
（如果系架与数据库设计一起做的话最好有提供，表关系图—ER图是必须在每个开发人员手上的，开发人员在理解自己要开发的模块和流程时应该容易看懂这文档）
很显然这个工作是一兼多职

Answer 8

很显然，CSDN又在抽风。。当然我的答案也只是个人抽风。。

Answer 9

而试的各位是架构设计 是吧
那不能光靠技术了, 要熟悉CMM管理,软件工程, 建模等知识, 里面虽然抽象不能直接回答LZ的问题,
但结合实际系统设计经验, 结果就不用说了, 到那时, 具体原因LZ可以写一本书来阐明了

Answer 10

这是一个在专业范畴内相对宽泛的问题,我想考官考的出除了你的专业知识外还有你的思维能力,也就是你解决问题的角度,如果你可以给出一个open的答案,那说明,你的角度是从项目出发,也就是处理问题会随机而变,如果你的回答专业不失灵活就最好了,仅为个人观点.1.首先第一个问题,任何系统,尽量做到的还是对拓展开放,对修改封闭,这是大原则,起始确定参数是有必要的,这样有利于团队快速的实现统一的编程方法,从而导致后期难协调的问题出来.但是建议参数尽量在针对接口编程的基础上实现私有化.
2.同意楼上的观点,Demo在实际项目中,仅从测试的角度来看,对测试功能和部分bug是有帮助的,但是如果要想真正的验证设计,还是要广泛的听取客户的意见!从后期开始做,这样就使得第一条更加重要了,开放与封闭!
3.UI之所以叫UI,就是因为他是从客户角度出发的,所以应该先由前台设计人员设计出成型的UI,再根据实际情况,前期预留出脚本研发周期，这样才是面向对象嘛．
４．做及时的信息回馈和有效的信息沟通是一个职业开发人员的职业素养体现，开发文档要务必做到细致有效，不要嫌麻烦，要知道越细就越有益于系统的后期维护，可以要求开发人员养成写文档的习惯，也可以你亲历亲为，这样有助于你更加详尽的了解整个项目，也可以使文档风格统一．（不过这样工作量会较大，但是试过之后，你会发现，值得去做的）