V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
Hyperion
V2EX  ›  问与答

软件工程的真谛是设计和划分模块阶段要完全和技术分离开?

  •  
  •   Hyperion · 2015-05-13 23:46:03 +08:00 · 5717 次点击
    这是一个创建于 3475 天前的主题,其中的信息可能已经有所发展或是发生改变。

    本学期我校某位编书神教授给我们上软件工程, 期间布置了一套软件工程实践作业.

    万分艰难的从一堆烂题目里选了一个看起可以做的比较贴近现实的东西: ftp文件检索系统.

    我之前实习(三个, 均非外包, 没有大公司经验) 和 接活(基本都是前端或者后端开发, 也有各种为各种烂系统善后的经验)

    都没接触过用这种看起来很"正规", 好像很"规范"的大型项目, 从需求分析开始, 到详细设计云云.

    到上个月底, 教授要搞PPT 交流, 遂, 做了从需求设计到详细设计, 憋了一份出来.

    分成下面三大块

    • 需求分析与需求规格
      • 调查研究 (引用了一篇2003年的论文, FTP相关搜遍知网也就那篇对得上号)
      • 可行性研究 (引用了RFC 2228, 提了几句做这个东西的必要性)
      • 功能需求 (分了四个模块)
        • 文件检索反馈 (提供查询的前端)
        • 文件索引维护 (存储文件信息的后端)
        • 搜索索引维护 (为文件信息建立索引的后端)
        • 系统维护管理 (管理后端)
    • 系统设计
      • MongoDB 实现文件索引维护部分
      • Elasticsearch 实现搜索索引建立
      • Python 实现查询和维护部分, 以及获取文件索引的爬虫.
    • 详细设计
      • 详细设计
        • 由FTP爬虫或在各FTP服务器上的索引程序对文件进行索引。(涉及FTP爬虫或索引生成程序)
        • 文件索引服务器接收到文件索引后入库存储。(写入MongoDB)
        • ElasticSearch搜索索引服务器通过elasticsearch-river-mongodb 插件,监视数据库op日志,进行相应的索引更新。
        • 前端搜索服务器使用curl方式向搜索索引服务器提出搜素请求。(涉及网页前端和后端,编写以及查询和页面缓存设计)
        • 最后提了下集群方面的事情.

    遂, 到了要“分享”的那天, 瞄了一眼同学的ppt, 哇, 全是流程图, 数据流图, 数据库er图, 完全不涉及任何技术相关问题, 只有干巴巴的结构.

    原来要这样?!

    意料之中, 或者又在意料之外, 老师赠与以下几点评价:

    • 你这个这么早编程干嘛? 我要看到的都没看到.
    • 你这个脱离了这个什么, 搞的不对

    事后几节课, 可能是听者有意, 应该是在说别人吧:

    • 太早编程, 就是完全一点也不懂软件工程
    • 论文你引个11年 12年的也算老了, 之前的完全是怎么怎么
    • 你们这个毕设就要根据我这个东西搞, 不能缺项

    至此, 我至今为止经历的猎奇冒险到此结束.


    问题, 所以软件工程在实际工作时候到底是怎么个样子? 所以我上面的设计是偏离软工的吗?

    软件工程的真谛是设计和划分模块阶段要完全和技术分离开?

    问题的出发点是好奇, 个人看法是, 这套东西实用度很低..

    88 条回复    2020-10-16 11:02:07 +08:00
    Septembers
        1
    Septembers  
       2015-05-14 00:05:48 +08:00 via Android
    歪下楼(一个完整的FTP路径包括用户信息是可以用一个URI完整表达的"ftp://username:password@host:port/to/path"
    Hyperion
        2
    Hyperion  
    OP
       2015-05-14 00:08:14 +08:00
    @Septembers 楼歪的略..

    实在看不出有什么关系, 而且这个不是常识吗?...
    101
        3
    101  
       2015-05-14 00:13:56 +08:00   ❤️ 1
    n 年前看的相关教材把这部分归在概念设计阶段算是生命周期法的初期,其中一个目的是跟项目其他成员交流,确定需求,看不懂 SQL 的起码理解 E-R 图容易点,编码都放到物理设计阶段。反正之后再没用过那套流程,实在繁琐
    chaucerling
        4
    chaucerling  
       2015-05-14 00:15:43 +08:00   ❤️ 1
    工程的意思就是要各种不同的部件最后能组装后能运行,开发只是里面的螺丝钉,能做的就是保证自己不出错。
    jesse_luo
        5
    jesse_luo  
       2015-05-14 00:22:32 +08:00   ❤️ 1
    所以我们才需要 PM 啊 😂😂😂
    wy315700
        6
    wy315700  
       2015-05-14 00:24:20 +08:00   ❤️ 3
    楼主觉得实用性低是因为楼主的项目还没到需要使用软件工程的底部。

    老师让用FTP来实践只是为了让你理解软件工程的流程。

    真正需要用软件工程的案例:
    军工,航天,

    互联网行业大家都习惯了上手就写代码,然后后来重构,这个其实是不好的习惯。

    我打个比方吧
    你造房子,
    不可能上来就搬砖开始糊墙吧。
    也不可能说 造了一半发现地基打的不对,然后重新造吧。

    肯定是从地皮规划,材料规划,然后各种模型图,每一个地方要用多少材料都规划好以后,然后是采购,人力。
    最后才是搬砖实际进行建造。

    软件也一样,要有规划,流程,写代码是最后一步,在软件工程里 代码其实不重要,因为文档完善了以后,任何人都可以根据文档写出代码来。
    Hyperion
        7
    Hyperion  
    OP
       2015-05-14 00:36:46 +08:00
    @101 是的, 而且一些东西完全没必要. 不过, 不得不说, 这套东西相当适合把90% 程序员当作普通工人来看待的行业, 比如政企, 行业软件开发.

    @chaucerling 擦汗, 似乎没有解答我的问题?

    @jesse_luo 是指PM协作还是? 似乎偏题了...?

    @wy315700 道理都懂, 不过可能有些误会? 我指的实用性低, 是指非超大型项目的情况下. 而且似乎重构的原因有一半是因为没法适应当前业务才进行的吧? 互联网行业(这说法好奇怪) 就个人浅薄认知, 并不是没有规划, 而是软件工厂的模式不合适吧?

    刚才问了下, 某厂流程是产品提需求, 实现, 联调. 不知各家公司的工作方式是不是都接近这个?
    lyklykkkkkkk
        8
    lyklykkkkkkk  
       2015-05-14 00:50:10 +08:00   ❤️ 6
    1. 没有所谓的“真谛”,只有“行得通的方案”
    2. 不是完全和技术分离开

    老师教的是软件工程,但你只懂软件,不懂工程。
    软件工程十分年轻,而其他行业还有很多工程可以借鉴,那些工程已经传承很多年了。
    架桥,造楼都是工程。这些工程也要完成长篇累牍的文档,但不会一开始就描述钢筋混泥土的型号。

    该写什么呢?

    任何工程根本上都是商业行为,其目的都是创造价值,那么软件工程就是通过制作软件来创造价值。
    在前期要完成的就是项目策划书,描述为什么能通过这个软件创造价值,也就是解决什么问题,也就是为什么有人会为你的软件买单,也就是你满足了什么人的什么需求。

    人+需求=你要解决的问题。

    你写了
    需求分析与需求规格
    调查研究 (引用了一篇2003年的论文, FTP相关搜遍知网也就那篇对得上号)
    可行性研究 (引用了RFC 2228, 提了几句做这个东西的必要性)

    但这样的内容经不起自己的推敲和他人的诘问。
    就说两个
    1. 你要做“FTP文件检索”,那么Who? When? Where? Why? How? 引论文有什么用?自己有想过吗?
    2. “提了几句做这个东西的必要性”,这是最重要的东西,提了几句不够。

    软件工程最缺的是想清楚怎么给用户用(怎么卖),而不是怎么做。
    形形色色的架构、方案、开源库、设计模式都是应问题而生,但第一重要的是想清楚问题!

    想清楚你的问题!
    想清楚你的问题!
    想清楚你的问题!

    你问,设计和划分模块阶段要完全和技术分离开?
    假定你这里的设计是指定义问题并给出解决方案(用例图,流程图,数据流图来描述),我只能说,甚至技术都没有资格跟设计相提并论。他们不在一个级别,就更不用提分离了。

    因为软件工程实践中,不会为了技术而技术,而是用技术解决问题。
    先有问题,然后选择技术(如果没有现有技术,则研发新技术)。没有合适的能带来价值的问题,技术压根就没有存在的空间。
    所以,找准问题比技术、编码更重要。

    你的文档要把问题研究清楚,别太早地纠缠细节。

    推荐阅读:《学会提问》
    Hyperion
        9
    Hyperion  
    OP
       2015-05-14 01:27:27 +08:00 via Android
    @lyklykkkkkkk 立项部分不多的原因,也是应老师要求简化。必要性的确没在意,因为是老师给的题,没有需求也要制造需求,我的确有欠考虑。

    论文引用了数据,为了说明这个系统存在的必要性,数据没贴出,个人觉得还是有一定说服力的。当然选题本身也很过时。

    这里不再讨论,并不是我不清楚的地方。

    -----------------------------------------

    用例图好理解,数据流图也好理解,研究用户需求并且白纸黑字定下来我也理解,和实际实现技术无关我也理解。

    我的问题,在于系统设计和详细设计。怎么谈这些,应该怎么谈? 这部分需要涉及技术吗? 看老师的反应,似乎依然认为这部分还不能谈实现。

    以及,技术选型并不是传统软件工程关注的事情吗?
    ipconfiger
        10
    ipconfiger  
       2015-05-14 01:44:59 +08:00
    除非你时间多到爆,否则纯粹的自顶向下的设计是没法走通的
    Hyperion
        11
    Hyperion  
    OP
       2015-05-14 01:54:03 +08:00 via Android
    @ipconfiger 切身体验,这种方法如果不是团伙作案,画图的时间就已经能填完这个坑了。

    不过,如果是几十上百人,而且规模很大的项目的话,可能不这样做规矩,基本就是个灾难片吧。

    题外话,随手翻了翻人月神话和另一本基本不看的软件工程的书,感觉学校老师嚼的这套东西和国外著作里叙述的并不一样。

    一个强调按部就班的流水线,一个强调解构和概念上的完整连贯。
    ipconfiger
        12
    ipconfiger  
       2015-05-14 02:02:34 +08:00   ❤️ 1
    @Hyperion 现在学校里教的软件工程一言蔽之就是屠龙技。而更2b的情况是大多数教软工的老湿,其实根本没有大型软件项目的管理经验,照本宣科尔
    101
        13
    101  
       2015-05-14 04:01:16 +08:00   ❤️ 1
    @Hyperion 我经验也不多,也不是软工的,说点浅见吧,这种流程的设计初衷解决大型工程的协作问题,适用于需求变动相对较小的场景,如 @wy315700 所说。但是有点不能认同,互联网现在的场景和演进速度这种模式并未考虑到,其缺点早就指明了不适用于频繁变更需求的项目,如果 Web 开发都这么搞,不饿死也累死。我唯一一次这么做时,花了很多时间写这些文档,后来代码功能都没实现完,更别说除虫了,想想如果将这些时间用在实现功能和除虫,最后的作品要好很多,而且实际代码中发现前期设计并不可行又是前后各种改。

    “系统设计和详细设计。怎么谈这些,应该怎么谈? 这部分需要涉及技术吗?“

    我猜你们教授认为你缺少概要设计和逻辑设计的文档,我当时概要设计的部分就是你同学搞的那些,逻辑设计就是扩展了一下,比如 E-R 图,扩展成对应的范式,具体关系表的设计再扯一堆(此处应当吐槽),还是没上代码。到了下一个流程才开始选定技术,确定何种语言,数据库。

    开发流程又不是这一种,针对场景选吧
    Hyperion
        14
    Hyperion  
    OP
       2015-05-14 07:19:11 +08:00 via Android
    @ipconfiger 根据教授平时上课夹带出来的私货,据说他和好多企业都有很深的合作关系。研究了下他的书和ppt,基本全是只适用sql+.net/java/asp 的案例。

    我现在手里的教材是他写的,据教授说出版社对此书甚为重视,求着出二版...

    题外话: 这教材深谙我朝语文精髓,一个概念换着法的换名字,有些东西就是死也不讲清楚什么是什么。教授布置笔头作业,但一个系统设计是什么的问题,按他老人家标准要分七点,每点得配上一句话才算"简答"。

    最后直接导致此门课作业才四次作业就写完了半本本子。

    @101 唔,似乎明白了。

    我的问题好像在于,没有搞清楚软件工程到底是干嘛的。软件工程似乎关注的是怎么白字黑字化,流程机械化,程序员僵尸化。

    拆解,分析,然后把软件像机械结构那样来制造,让工程能够只需要有一定职业素养的操作工就能完成; 最终降低大方向错误的的可能和成本。

    所以,这是一门只适合大型系统,比如银行,行业软件,政府医院软件的课(并不指这一个大学科,只谈我听到的东西)。

    题外话: 好像突然明白了为什么低端java 和.net 依然老当益壮和培训机构蓬勃发展的原因了...
    Hyperion
        15
    Hyperion  
    OP
       2015-05-14 07:23:19 +08:00 via Android
    @Hyperion "低端java 和.net 依然老当益壮" => "低端java 和.net 程序员依然有强劲市场"

    修正,并不针对语言,请勿追杀。
    wy315700
        16
    wy315700  
       2015-05-14 07:41:57 +08:00   ❤️ 1
    @Hyperion 补充一点,软件工程也有很多模式,比如现在的互联网模式其实是属于敏捷开发模式,你说的是指自顶向下的模式,还有自底向上模式。

    互联网行业!=软件行业,我觉得你会认为不实用,就是杀鸡用牛刀的道理,不是不实用,是不适合现在的项目。
    msg7086
        17
    msg7086  
       2015-05-14 07:44:41 +08:00   ❤️ 1
    另外,可能老师要求的是比较传统的软件工程过程,而你却习惯了敏捷开发……
    Hyperion
        18
    Hyperion  
    OP
       2015-05-14 08:02:38 +08:00 via Android
    @wy315700 我明白了,非常感谢!

    @msg7086 对...

    换个角度看,可能我不适合自顶向下的方法。我还是看的太少...
    wy315700
        19
    wy315700  
       2015-05-14 08:19:54 +08:00
    @Hyperion

    软件工程里 大部分是给商业项目用的,存在合同,甲方乙方的关系。

    老师不是让你做一个“ ftp文件检索系统”,

    而是有假设有甲方需要采购“ ftp文件检索系统”,

    你作为乙方,面对这个需求去做一个,是造房子的过程,要的是过程而不是最后的软件。

    而产品提需求, 实现, 联调,其实是房子已经造好了,然后开始装修了,你可以提意见说这个地方怎么怎么装修。
    msg7086
        20
    msg7086  
       2015-05-14 08:27:43 +08:00
    @wy315700 哇哈哈才发现同步了
    jun4rui
        21
    jun4rui  
       2015-05-14 08:29:46 +08:00
    软件工程分很多种方法的,目前绝大多数都不适合楼主老师说的方式,这样出来的学生只会纸上谈兵,楼主做过项目也知道这么干不切实际。不过学学没坏处,就当领略一下大型工程的设计方式。

    其实实际上需求是多变的,像MIUI这种先开发出原型,然后不断的迭代、重构我觉得更合适大多数的常见项目。因为现在大多数需求都在不断变化,甚至用户都不知道自己要什么,沟通也有问题,可能做了很久还不是他心里想要的那个,你要是还在反复设计,你会永远停留在纸面阶段,根本轮不到编码阶段。快速做出一个东西,然后用户看到、反馈、调整,这才是大多数项目的真实情况。
    binux
        22
    binux  
       2015-05-14 09:30:03 +08:00
    @Hyperion 就冲你这句「研究了下他的书和ppt,基本全是只适用sql+.net/java/asp 的案例 」还是不理解软件工程。人家的做的工程,换成 MongoDB 的,换成 Python 的有什么不可以?只要达到设计标准就好了。

    回到你的例子,索引用 SQL 数据库不行吗?检索直接查 SQL 不行吗?爬虫换个 java 的不行吗?
    软件工程关心的首先是为了达到目的,需要什么组件,至于它们是什么鬼根本不关心。

    你为什么选那些?选他们的理由和目的是什么?
    软件工程关心的是,你为什么要选那些方案,需要达到什么样的效果,预期压力。
    Hyperion
        23
    Hyperion  
    OP
       2015-05-14 09:35:02 +08:00
    @wy315700 嗯, 我觉得老师从头到尾有一个意思没有明确表示: 我是没指望你们写出什么东西, 你们就按照我说的走一边, 这就是你们以后吃饭的家伙了.

    @jun4rui 嗯, 全当观光了..
    learnshare
        24
    learnshare  
       2015-05-14 09:46:32 +08:00
    做架构设计,应该是技术无关的,要剥离具体的语言、数据库和运行环境。
    wy315700
        25
    wy315700  
       2015-05-14 09:47:49 +08:00   ❤️ 1
    @Hyperion 软件工程里,最后的实现,真的不重要,这么说吧,如果前面的东西没做好,最后根本拿不下来合同。

    所以学习的时候,侧重点根本不在最后的那个实现,

    语言和技术细节,其实最大的区别是:学习成本,维护成本,性能,稳定性,安全性。
    用户不会关心你用什么实现,对他们来说根本没区别。
    更何况,你看不起的.net/Java 真不赖。更何况,这两门语言是经得起考验的。很多业务都是用的私有的JAVA库,比如加密方面。


    还是 @binux 说得好,你住在房子里,不会关心用的什么牌子的水泥吧,也不关心里面的钢筋是哪个地方产的吧,你肯定关心的是房子牢不牢,能不能保暖,使用年限。
    ZHenJ
        26
    ZHenJ  
       2015-05-14 09:48:07 +08:00
    当年学的时候觉得自己是Engineer,然后工作发现其实是Worker
    Hyperion
        27
    Hyperion  
    OP
       2015-05-14 09:55:44 +08:00
    @binux

    1. 吐槽的重点是, 书和例子里的结构, 应该说都是为了需求而需求, 很假. 以及, 已经在这种结构公司工作的朋友吐槽, 这根本不符合实际. 技术可行性是最先要考虑的.

    2. 写这份东西的时候我没有意识到传统的软件工程要的是什么.

    但从我的角度来看, 这么实现是最快的. 索引? 不换. 数据库sql? 需求分析时候就否了. 直接查sql? 不满足需求. 爬虫换java? 这是可以的.

    而且可行性分析里, 经济成本预算是先定了全开源的. 预先假设是低成本.

    3. 当然, 我明白这不是所谓软件工程范畴了, 或者说从一开始我都没这么做.


    某些东西模棱两可.
    Narcissu5
        28
    Narcissu5  
       2015-05-14 09:56:52 +08:00
    软件工程早就沉了,软件工程有效的前提是

    - 需求相对稳定
    - 不存在有未知风险的技术难点
    - 项目规模足够大
    - 开发周期足够充裕

    真正做过开发的都知道,真实世界的项目能符合一条就赶紧烧香吧
    wy315700
        29
    wy315700  
       2015-05-14 10:03:58 +08:00
    @Narcissu5 工控,
    jarlyyn
        30
    jarlyyn  
       2015-05-14 10:09:03 +08:00
    觉得吧,这个方面,你老师应该没什么错。

    就如同你老板要你做方案,结果你去把代码写出来了……

    做开发第一步,不是先做方案,再看方案是否可行,乙方是否能接受么。
    binux
        31
    binux  
       2015-05-14 10:19:12 +08:00
    @Hyperion 你所说的「实现是最快的」,「不满足需求」是你软件工程中需要的,怎么解决是不需要的。
    你朋友的公司,如果项目是自己做的,那么肯定会考虑自己习惯什么技术。
    但是做软件工程的时候不必要。可行性是要考虑的,但是不会限定,从来没有说某个技术只能这么做的。
    Hyperion
        32
    Hyperion  
    OP
       2015-05-14 12:16:46 +08:00
    @Narcissu5 = = 不能同意更多...

    @wy315700 工控也做过, 不过只有PLC 和电路设计的经验, 那个需求几乎不可能有变化, 想来那时候的做法, 和现在这种形式化的软件工程很像.

    @jarlyyn 这.. 其实我至今觉得我现在是方案= =... 性能, 成本 都已经考虑在内了.

    @binux 唔, 还是先谢谢, 对, 怎么解决是最后的事情, 小项目可能一步就跨过去了.
    jarlyyn
        33
    jarlyyn  
       2015-05-14 14:14:37 +08:00
    @Hyperion

    个人感觉哦,可能你老师表述不清。

    一般来说,应该先确认功能和流程么。

    用啥技术其实没那么重要。
    imn1
        34
    imn1  
       2015-05-14 15:06:51 +08:00
    工作后就了解“一上来就写代码会死得很惨”这个真谛的
    Hyperion
        35
    Hyperion  
    OP
       2015-05-14 15:31:43 +08:00 via Android
    @jarlyyn 确认了才能做到选型这一步不是吗?

    我本质上没有跨过流程和功能这一步呀?

    @imn1 所以写代码的定义是什么? 我并不是没有设计啊。
    imn1
        36
    imn1  
       2015-05-14 15:47:29 +08:00
    @Hyperion
    如果我做老师也说你不及格,让你重做的

    需求分析做了么?
    你埋头设计有什么用?客户一句“不符合需求”就要重做了
    需求不是你设想中的需求,而是客户的需求

    其实说白了你只有一点没弄明白:老师,其实就是你的客户/委托人~
    lion9527
        37
    lion9527  
       2015-05-14 16:31:20 +08:00
    LZ没错。
    你老师只是想让你严格按照软件工程的流程来走,你却以开发者的角度去设计。
    漂亮的PPT,流程图是给客户看的,实际开发中,对开发者来说没什么卵用。
    上世纪70年代的《人月神话》都说严格的软件工程流程是50年代的糟粕。

    你自己做过项目肯定会有自己的一套流程,工作后团队合作也会有一套流程。
    这个只为了学分,拿同学的抄一抄就满足下教授呗。
    ivenvd
        38
    ivenvd  
       2015-05-14 17:43:03 +08:00
    个人感觉,现在学习软件工程,并非是为了遵循它,而是要明白其产生的原因和运作的原理、优缺点,从而作为敏捷开发等现代协作流程的入门契机。

    这个原理跟从 C 语言入门学习编程是一样的道理……
    zxkc
        39
    zxkc  
       2015-05-14 18:07:09 +08:00
    需求,沟通不够啊,这个和现实开发程序一样,否则费力不讨好。
    Hyperion
        40
    Hyperion  
    OP
       2015-05-14 18:42:33 +08:00
    @imn1 老师要求简化, 前面楼层已提到.

    @lion9527 懒, 而且教授也不太在意这个东西.

    反正我估计这辈子也不会去参与要严格走这种流程的项目, 生命基本都浪费在等待上, 很不爽.

    @ivenvd 偏执一点, 我觉得完全是让你明白这东西有多坑才开这门课的.

    ------------------------------------------------

    弄个小结论.

    软件工程(仅指课程, 不是泛指这个学科), 老师现在教的这套东西, 我认为是有用的, 但也只是对那些庞大, 臃肿的项目才有价值.

    当软件工程, 本身并不是但只有现在我看到的, 老师强迫要求搞的这些.

    我想明白两件事:


    1. 我习惯的是敏捷开发, 并不是传统软件工程.

    软件工程目的是所有东西文档化, 标准化, 目的就是统一质量, 重点就是降低人力成本.

    敏捷开发, 简化流程, 虽然依赖人, 但也不是没有标准和文档.

    我这边这位老师似乎看不起敏捷开发, 认为这不是正道, 我和他的分歧应该就在这里.


    2. 对的方法做对的事.

    软件工程方法论, 实用价值仅仅针对的是特定的场合. 而且死板 = 死亡, 按流程走不动变通也是死路一条. 互联网产品要走这流程, 基本都会把时间浪费在那些"设计"里, 原本的好处只是镜花水月而已.

    敏捷开发, 自由是好事, 太自由也不是好事. 文档是要写的, 但不见得要详细到毫厘, 但必须写, 写清楚.

    以及, 方法论这种东西, 脱离实际就是胡诌.

    -----------------------------------------------------

    4年前看陈皓的blog, 看到他的一个痛恨手册(http://coolshell.cn/haoel):

    """
    下面这个是我个人的“痛恨手册”,这足以证明,这是一个愚蠢的时代。

    痛恨各种不从研发团队出发,不从团队和项目出发的流程、方法论、咨询师、SQA、流程部门。
    痛恨那些为所欲为的,为了自己商业目标牺牲用户利益的中国IT企业。
    痛恨中国的C2C式的那种简单的抄袭和复制。
    痛恨互联网上的那个墙,还有那些烦得不能再烦的审查机制。(我能拥有.cn域名真是一种壮举)
    痛恨中国的某些编辑和某些作者乱出书,出烂书。

    """

    我还是图样图森破, 果然还只是只井底的青蛙, 谈方法论, 早了十年. 希望我以后有一天能有陈皓前辈那样的水平和阅历吧.
    Hyperion
        41
    Hyperion  
    OP
       2015-05-14 18:43:37 +08:00
    @Hyperion "本身并不是但只有现在我看到的" => "本身并不只有现在我看到的"
    kxxoling
        42
    kxxoling  
       2015-05-14 18:47:10 +08:00
    你的需求是“软件工程”而不是软件项目,也就是说按照工程而非作坊形式完成软件,也就是说需要抽象化一套适用于复杂开发环境的流程,不能因为项目简单而忽略流程,否则就是偏题了。
    Hyperion
        43
    Hyperion  
    OP
       2015-05-14 19:15:45 +08:00
    @kxxoling 然而按照老师的要求, 其实估计只要流程图, 数据流图, 然后辅以他书里的概念就算齐活了.

    而且, 我并不认为不结合实际, 能抽出适应复杂环境的流程.

    至始至终, 老师可能要求是只是走一遍, 就算是抄的也无妨, 只要走一边, 不用思考.

    另外想求教两个问题. 作坊形式要怎么定义? 是不是敏捷开发就是作坊形式?
    kxxoling
        44
    kxxoling  
       2015-05-14 19:56:12 +08:00 via iPhone
    跟你想的差不多,老师的目的就是让你熟悉这些内容。诚然,不在实际开发中学不到工程的精髓,但书上教的都是前人的经验总结,虽然不是银弹但还是比较有参考价值的。
    作坊模式,我的意思是像作坊一样只注重结果,把东西做出来就行,在小型案例中并没有什么不可,但是可扩展性较差。
    对于敏捷开发,我个人反而觉得更难定性一些,但敏捷本身也是一种流程,作坊模式几乎没有流程概念。
    最后,可以看的出来你对老师的水平不信任,我也相信你的老师缺乏某些经验甚至能力,但是学校里的这套东西仍然是有价值的,你如果认为相当其它概念价值较低,完全可以糊弄过去,淘宝上很便宜的,但是不要因此低估了规范的重要性。
    Hyperion
        45
    Hyperion  
    OP
       2015-05-14 20:34:00 +08:00
    @kxxoling 感谢回复

    1. 可扩展性较差的问题不知能否举例?


    2. 如果作坊模式是这样定义, 那传统软件工程阶段实现, 就我观察接触到的, 可能还不如"作坊式"的团队.

    软件工程最后实现阶段, 按老师和一些前辈说法, 完全按照需求规格来就好. 以至于我善后期间接触的代码, 真的只是一只听起来会嘎嘎叫, 用起来也很像的鸭子. 但打开黑箱一看, 基本就是一个畸形生物, 根本无法修改的东西(最近接触到的案例是: 存储过程编写出错, 不修正反而去修改代码, 用一坨if 来修正, 各种+1-1).

    但因为通过了测试, 就这么留在了里面, 而且这并不是个案, 其他项目也有这类糟糕的问题.

    "软件工程关注的不是实现", 这个是我在这个帖子里看到的比较统一的观点. 软件工程看重的标准化, 无可厚非. 机械和电气方向的做法放在软件领域, 我也知道应该会很漂亮. 但往往最终实现的时候, 代码复查, 审计, 好像被看得很淡.

    瞄了一眼认识的, 做外包或者大项目的, 基本都有这种问题, 我并不是要求代码完美无缺, 起码逻辑正常.

    软件工程似乎更注重结果? 老师也刻意的忽略这一块, 似乎他本身也不太懂这一方面.


    3. 老师的水平, 其实我无意吐槽. 个人是非常尊重所有老师的, 即使有意见, 我也不会顶撞.

    但相反, 我不希望被恶损, 或者被当作反面教材. 说是听者有心也好, 玻璃心也罢, 老师种种说法和观点, 我不敢苟同, 或者说有所反感.

    其他就不多说了, 毕竟不是寻仇贴, 犯不着和老师过不去. 只是单纯的不想浪费时间, 既然同样要坐在教师里, 就学吧. 可惜越学越糊涂..
    wy315700
        46
    wy315700  
       2015-05-14 20:40:10 +08:00
    @Hyperion 我只能说 你还是那个想法:现在出问题以后是可以修改的。拿一个案例说吧,芯片商合作的时候,需求和设计文档那得写的清清楚楚,芯片流片成功以后,就不能动了(流片一次1000万,你可以把流片理解为软件里的编译),要修改得等下个芯片才可以修改。
    seki
        47
    seki  
       2015-05-14 20:46:25 +08:00
    软件工程的理论是高射炮,可惜业界实践的 80% 都是打蚊子,用不上。
    打蚊子当然是敏捷开发和快速迭代模式更舒服。
    wy315700
        48
    wy315700  
       2015-05-14 20:50:40 +08:00
    @seki 其实是核弹,但你不能说核弹没有用。。只能说 暂时用不着。
    seki
        49
    seki  
       2015-05-14 20:55:49 +08:00
    @wy315700 是啊,我觉得如果是一个几十人以上全力参与的大型项目,就得老老实实按照这套理论全都理清楚了。

    不过国内教授的软件工程理论我认为会比较刻板,因为讲的人也不一定有充足的实践经验……
    wy315700
        50
    wy315700  
       2015-05-14 21:01:24 +08:00
    @seki 但是作为一门课程,我觉得好好学是有必要的,学习是给自己的,又不是给老师学的。


    @Hyperion

    其实吧,我发现你的逻辑是这样的: 这个东西我不喜欢不习惯,用不着 == 这东西没什么用。

    和上次某个帖子里一个人 : 这东西Google都没有用 == 这东西没什么用
    Hyperion
        51
    Hyperion  
    OP
       2015-05-14 21:01:50 +08:00
    @wy315700 哦, 我是接手别人已经交付到乙方手里的项目, 职业擦屁股... 特指一些"信息"系统.

    工控, 机械, 电子, 电路, 芯片和ic开发我都有所了解, 因为家里有人做这些, 打击面比较广. 流片之类概念还能理解, 但再深就不清楚了.
    Hyperion
        52
    Hyperion  
    OP
       2015-05-14 21:02:56 +08:00
    @wy315700 我并没有这么认为, 可以参考#40 楼.
    Hyperion
        53
    Hyperion  
    OP
       2015-05-14 21:08:52 +08:00
    @seki 是的, 大项目, 如果需求变动不大, 按传统软件工程思路没有什么大问题.

    但又有多少适合呢?..
    wy315700
        54
    wy315700  
       2015-05-14 21:09:26 +08:00
    @Hyperion 别纠结了吧,存在即合理,我们看不上的东西没准是好东西呢。
    birdgu
        55
    birdgu  
       2015-05-14 21:10:25 +08:00
    首先,学校里要拿到好分数还是要听老师的。

    其次,总的来说,我认为你的东西没有偏离软件开发方法的正路。具体提几个意见:

    1. 你的需求分析中缺少了非功能性需求,比如性能需求、安全性需求、系统容量需求等。这是很多人在做需求分析时都会忽略的内容。

    2. 系统设计阶段首先需要划分子系统或模块(非常高层的)。然后为整个系统进行技术选型是这个阶段非常重要的工作。你在这个阶段选定了几个第三方软件是很有必要的,只是欠缺了对系统整体结构的描述(从你自己的描述来看)。因为系统每个部分是自己开发、还是采用第三方软件对系统整体设计是有影响的。当然,实际项目中很多东西,比如数据库、采用的语言、框架可能在需求分析前就决定了。

    3. “前端搜索服务器使用curl方式向搜索索引服务器提出搜素请求。”
    这不是描述两个模块之间接口的正确方式。可以这样说:“前端搜索服务器与索引服务器之间采用HTTP协议,REST风格的接口定义,使用JSON为数据格式”。这应该属于概要设计的内容。在详细设计阶段需要列出这两个服务器之间每个接口的功能、输入数据、输出数据。

    4. 至于详细设计,不同的软件开发方法(流程)对详细设计详细程度的要求都不相同,这里就不详细说了。

    最后,我很好奇,老师为什么说“你这个这么早编程干嘛”,难道你交上去的作业里已经包含源代码了?

    ---------------------

    说说你同学的作业:

    流程图、数据流图可以用来描述业务流程,此时这些图属于需求分析的内容。如果描述具体算法实现、或者系统各模块之间的关系,那么属于设计的内容。ER图如果用来描述概念模型,那么也属于需求分析。如果用来描述物理模型,那么属于设计。所以关键不是用了什么图,关键是用来描述什么东西,决定了它们属于哪个阶段的内容。

    另外,现在还在使用ER图做设计,而不是用UML的,就好比还在用小篆写作文的。

    --------------------
    关于设计与技术:

    所谓“软件设计”,就是决定如何使用软件技术实现系统需求。那么设计阶段怎么可能不涉及技术呢?我也不记得任何一本软件工程的书说过设计要和技术分离。

    举个例子来说,到底是要设计一个集中式的系统,还是一个分布式的系统;所有的模块到底是在一个进程中,还是同一台机器上的多个进程,还是分布在多台机器上,这样一个重要的纯技术决策不在设计阶段进行要在什么阶段进行呢?

    ------------------
    传统软件工程的作用:

    在当前的商业环境下,即使对于传统上认为大而复杂的银行系统,传统的,基于瀑布模型的软件工程也是完全不适合的。很多公司依然在采用软件工程的一个原因是目前绝大部分的软件开发合同都是闭口合同,即开发范围、时间、费用都在合同中规定了。传统软件工程给人一种假象,似乎在这种合同下能够降低风险,以及在发生纠纷时易于区分责任。但这不过是一个假象罢了。
    birdgu
        56
    birdgu  
       2015-05-14 21:14:21 +08:00
    @kxxoling 传统基于瀑布模型的软件工程目前存在的唯一价值就是告诉大家曾经存在过这样一种软件开发方法。我认为大学应该开设“软件开发过程”的课,传统软件工程的内容作为发展历史的一部分讲授就可以了。
    seki
        57
    seki  
       2015-05-14 21:20:43 +08:00
    @Hyperion 我说的这些纯粹个人感慨,倒没有让你不学的意思,只是说不用太过认真,教授怎么说你就怎么做就好了

    主要是你不能一直就打蚊子,所以了解别人怎么操作高射炮也是有必要的,把实践抽象到理论层面有时候更有助于你理解,别的楼上的大家也说得多了。
    birdgu
        58
    birdgu  
       2015-05-14 21:24:49 +08:00
    “拆解,分析,然后把软件像机械结构那样来制造,让工程能够只需要有一定职业素养的操作工就能完成; 最终降低大方向错误的的可能和成本。 ”

    呵呵,这就是“软件蓝领”的概念。但这不过是那些搞培训的公司,或者只做低端外包和人员派遣的公司编出来骗人、骗钱的鬼话而已。
    jun4rui
        59
    jun4rui  
       2015-05-14 21:25:43 +08:00
    主要是学校基本不教打蚊子,直接从c语言语法就跳到大型软件工程,落差太大。
    birdgu
        60
    birdgu  
       2015-05-14 21:27:52 +08:00
    @Hyperion “是的, 大项目, 如果需求变动不大, ”,呵呵,这样的项目基本没有。
    Hyperion
        61
    Hyperion  
    OP
       2015-05-14 21:28:07 +08:00
    @wy315700 -_- 只是单纯的蛋疼, 人类文明也是无聊推动嘛... 求同存异.

    @birdgu 感谢回复.

    1/2. 受教, 谢谢. 下学期可能还有这方面的东西要写, 我一定注意.

    关于"这么早编程", 对, 我也很好奇... 我没有写任何一行源码, 完全没有.

    谢谢, 可能表述上让老师觉得我在编程吧... 我真的纳闷很久...

    ER图, 据老师说这个还是必要的东西, 不能缺项..


    3. 对, 很同意. 但听老师的意思, 这方面属于实现部分, 课程并不关注.


    4. 了解. 好像有那么点清楚软件工程的现实意义了.


    谢谢! 我以为以前实习时候师傅告诉我的都是错的...
    birdgu
        62
    birdgu  
       2015-05-14 21:41:28 +08:00
    @Hyperion 从你的描述看,你是把搜索服务器和索引服务器设计为两个分布式的子系统,那么这两个子系统间的接口设计是详细设计部分的重要内容。即使传统软件工程也不会认为这属于实现部分。不知道是你们老师没有理解你的设计,还是你误解了你们老师的话。
    birdgu
        63
    birdgu  
       2015-05-14 21:51:11 +08:00
    即使是一个由几十人参加的大系统,也完全可以用敏捷的方法去做。

    由一个总体设计小组负责根据需求做总体设计、子系统划分,然后每个子系统交给一个采用敏捷方法的团队去做。而需求、总体设计也可以是一个反复迭代的过程。关于在大系统开发中采用敏捷方法的研究还是不少的。

    而实践已经证明,采用敏捷方法完全可能比传统软件工程需要更少的人员。
    kxxoling
        64
    kxxoling  
       2015-05-14 21:57:41 +08:00
    @Hyperion 1. “可扩展性差”我没仔细炼,想表达的是“scalability”差,相信你能理解。就是说,如果项目更大、参与的人数更广泛,涉及的角色更多的时候即使修修补补也无济于事,肯定得换个思路了。

    2. 这种情况很正常,陈皓的文章中也说了,越是差的团队越是教条主义、不知变通,差的代码跟差的流程的生产者重合度很大。当然也有野路子,我现在的经验就是,虽然学院派不是银弹,但野路子很不靠谱。

    3. 软件工程更重视什么?这一点不需要太纠结,结果永远是最重目的,工程化是手段:只有工程化才能把过往经验更有效地传递下去,坏处是盲目相信会降低灵活性,但错不在工程而在开发者。
    学习和使用工程化的思维是为你未来更大的挑战做准备的,不必太拘泥于现在。

    举个例子吧,陈皓还介绍过“撞大运调试法”,如果我们把有条理的调试流程比作工程化,那么作坊式就是撞大运,在小项目中凭借经验和个人能力你可以一眼看出问题,当项目十倍百倍增大时就难以运作了。

    4. 关于老师。这个大家都懂的,没必要讨论了。
    kxxoling
        65
    kxxoling  
       2015-05-14 21:59:46 +08:00
    @birdgu 演进是需要时间的嘛~
    birdgu
        66
    birdgu  
       2015-05-14 22:06:50 +08:00
    @kxxoling 对软件开发过程来说,工程,或者建筑工程并不是一个好的比喻。建议读一下《软件工艺》(Software Craftsmanship》)

    比如,在建筑工程中不可能在你盖完一个三层小别墅以后,再变更需求要改建成小高层的公寓楼。但在软件项目中,这太常见了。关键是在实际的商业环境下,用户这样的需求可能是完全合理的!
    Hyperion
        67
    Hyperion  
    OP
       2015-05-14 22:20:25 +08:00
    @birdgu 翻了下当初他发下来的模板, 我应该没有理解错, 他的书, 认为技术选型是之后的事情, 很明确.

    @kxxoling 了解, 谢谢.

    @seki 谢谢! 受教.

    @jun4rui 是的, 以及今天听到了老师这么一段话:

    """
    国外有个TIOBE 的排行榜, 11年时候, 你们看 第一名是Java, 第二名是c, 第三名是c++. 说明这些语言肯定@#!@$!%#@^.

    我前面备课去查了一下 15年4月的排行, 第一名是Java, 第二名是c, 第三名是obj-c. obj-c是什么? 是苹果的那个语言. @!#!$%^

    然后, 后面就不用看了.
    """

    不用看了... 用看了... 看了... 了...
    wy315700
        68
    wy315700  
       2015-05-14 22:25:12 +08:00
    @Hyperion

    后面还是要看的 5月份 C++还是第三名

    May 2015 May 2014 Change Programming Language Ratings Change
    1 2 change Java 16.869% -0.04%
    2 1 change C 16.847% -0.08%
    3 4 change C++ 7.875% +1.89%
    4 3 change Objective-C 5.393% -6.40%
    5 6 change C# 5.264% +1.52%
    6 8 change Python 3.725% +0.67%
    birdgu
        69
    birdgu  
       2015-05-14 22:27:43 +08:00
    @Hyperion 不明白你们老师想说明啥。排名后面的语言没有学习价值?
    Hyperion
        70
    Hyperion  
    OP
       2015-05-14 22:29:44 +08:00
    @wy315700 嗯, 我下课之后查了下, 老师数据引用的不对. 不过从来没有专门去查TIOBE 的数据, 平时也是从各种论战里看到才了解一下.

    不过, 我也无话可说. 决定讲课内容的是他...
    Hyperion
        71
    Hyperion  
    OP
       2015-05-14 22:30:33 +08:00
    @birdgu 如果我揣摩的没错的话, 是的...
    kxxoling
        72
    kxxoling  
       2015-05-14 23:00:40 +08:00
    @birdgu 我的理解,软件开发是一个工程化很浓的工作,地基敲定后就不可变这一特性是建筑行业的特色而非工程的通性。硬要举个例子的话,你可想想一下现在想要替换 IP 协议会怎样?
    wy315700
        73
    wy315700  
       2015-05-14 23:01:54 +08:00
    @kxxoling IPV6这么多年不能普及就是这个原因
    min
        74
    min  
       2015-05-14 23:14:10 +08:00
    我最头疼solution design review的时候只拿一个数据库表结构来跟我讲的
    napsterwu
        75
    napsterwu  
       2015-05-14 23:50:34 +08:00
    @Septembers 一直在想密码里面带@的要怎么办 git也同理。。
    wy315700
        76
    wy315700  
       2015-05-14 23:52:11 +08:00
    @napsterwu 转义符吧
    birdgu
        77
    birdgu  
       2015-05-15 08:28:15 +08:00 via iPhone
    @wy315700 IPV6不能普及主要还是因为有大量硬件需要更要、地址需要重新分配、大量的系统配置工作要做…而对大量现有系统的拥有者来说并没而改变的迫切感,在无数自治系统组成的互联网上又没人迫使大家来做。So……
    birdgu
        78
    birdgu  
       2015-05-15 08:38:22 +08:00 via iPhone
    @kxxoling 对设计良好的软件来说,更换IP协议根本不是大问题。传统的软件工程希望通过大量的文档和评审来固化每个阶段的工作,尽量减少变化,特别是需求变化。对变化采取的是消极的态度。敏捷方法则是认识到变化是永恒的,因此只有想办法使软件和开发去积极地去适应变化。
    casparchen
        79
    casparchen  
       2015-05-15 09:40:34 +08:00 via iPad
    讨论这么多有意义吗?你上的是软件工程这门课,老师上课按照软件工程常规的来不对吗?你觉得敏捷开发更适合你更好,跟这门课有什么关系?你选了我这门课,我就得按照这门课的内容公平地评价所有的学生。就好像美术系的学生画画不行,我该因为他唱歌好给他好评,搞笑一样呢。
    wy315700
        80
    wy315700  
       2015-05-15 09:50:46 +08:00
    @birdgu 本质的原因就是 IPV6和IPV4 不 兼 容。

    如果兼容,那就没有什么问题了
    Hyperion
        81
    Hyperion  
    OP
       2015-05-15 12:27:32 +08:00
    @casparchen 如果我校能选课,我100%避开。

    想必你并没有看最后我提的问题。学了这门课,不思考一下一点价值都没有。我是想了解实际工作时候的情况,而且你举的例子,完全不对题。
    Hyperion
        82
    Hyperion  
    OP
       2015-05-15 12:29:20 +08:00
    @casparchen 补充最后一句话:

    既然要*被*花时间学这东西,我为什么不能给自己联系点有用的让时间产生点价值?
    casparchen
        83
    casparchen  
       2015-05-15 15:08:39 +08:00 via iPad
    @Hyperion 你当然可以给自己联系点有用的(非本门课内容)的东西来让你的时间产生(非本门课应该产生)的价值,但是你不能因为这样指望老师给予你(本来就没做好)的本门课作业的好评(没错,在本门课的context里,你就是没有做好)。还是那个例子,你觉得这门课没意义,去学音乐吧,反正跟这门课也没关系
    Hyperion
        84
    Hyperion  
    OP
       2015-05-15 20:11:55 +08:00 via Android
    @casparchen 1. 成绩我不在意,我认死理,我是要找我问题在哪里,没有价值的东西我上课当然过滤掉了,不是什么为了分像被人赶尸一样到达终点。

    2. "请尽量让自己的回复能够对别人有帮助",没看完我问题到底你是哪里来的勇气来指指点点?
    casparchen
        85
    casparchen  
       2015-05-15 21:56:37 +08:00
    @Hyperion 你认的理在我看来的确是死理. 另外你觉得我是指指点点我一点也不意外,毕竟你老师让你跟着他的课程设置走,你都觉得是不应该的。『可能是听者有意, 我应该是在说别人吧』
    Hyperion
        86
    Hyperion  
    OP
       2015-05-15 22:18:32 +08:00
    @casparchen 的确在跟着走,而且我也没有敷衍的完成。

    我的问题是这样的:

    """
    问题, 所以软件工程在实际工作时候到底是怎么个样子? 所以我上面的设计是偏离软工的吗?

    软件工程的真谛是设计和划分模块阶段要完全和技术分离开?

    问题的出发点是好奇, 个人看法是, 这套东西实用度很低..

    """

    你的思路很奇怪,我没有来发帖抱怨的意思(更多的是懊恼)。在布置的时候,老师的要求是:你们要做的是需求分析,详细设计。其他要求?没有,老师上实验课也是发样张让我们“改”出一份东西,这样我也能很明确的明白老师想要看的是什么,但PPT 他并没有提。

    翻了下他的书,我并没有研究出他要的是什么,我只能按照我实习时候的体验来做一份东西。完全没有敷衍的意思。

    你不知道这个前提,为什么会觉得我认为“跟着老师的课程设计,是不应该的”?
    crybro
        87
    crybro  
       2015-06-01 14:21:04 +08:00
    [现实中的软件工程]
    甲方:公司需要采购一套FTP文件检索系统,包括开发、维护和技术支持,预算有限,你们给出个方案,报个价吧^
    乙方A:架构师1人月,程序员6人月,测试1人月。
    乙方B:服务器一套,某商业软件授权一套,项目经理一名,二次开发工程师一名,测试一名。
    乙方C:做多少时间给多少钱,因为我们是敏捷的……
    ksssdh123
        88
    ksssdh123  
       2020-10-16 11:02:07 +08:00
    @birdgu
    最后一段话-传统软件工程的作用完全击中了目前软件行业中的问题,开口闭口合同,一直想着用合同来降低风险,但太过理想化
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2954 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 36ms · UTC 12:30 · PVG 20:30 · LAX 04:30 · JFK 07:30
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.