首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  职场话题

CTO 对软件工程似乎不太了解,感觉很不好

  •  
  •   sfree2005 · 2017-08-09 08:07:15 +08:00 · 5899 次点击
    这是一个创建于 797 天前的主题,其中的信息可能已经有所发展或是发生改变。
    从老板那了解到 CTO 在软件行业里也有十几年经验了,虽然不是科班出身,但应该也会了解到很多吧。

    但刚刚接到的的项目,他只是需要客户提供些界面设计草图和澄清一些问题,就开始设计数据库写代码。

    如果这个 app 简单,或者是模仿某个现有 app 还好说,但现实是里面的核心功能是完全独有的,高定制的。

    在我看来,不是应该先有剧本(use case),各种 UML 图,然后再有界面的设计草图吗?没有这些,作为后端的我几乎不知道干啥。我也可以想象到前端移动端更不知道除了按界面设计图画模板外还能做些什么。

    需求一直改是肯定的,但在剧本和 UML 图阶段就改掉部分绝对是节约大量时间的。如果跳过这个过程,去改 code 甚至数据库设计的话那将会很头疼呀。

    作为后端,我实在坐不住,就有主动做些需求分析工作,写下 use case,画些图和设计数据库之类,CTO 人也好的,他有鼓励我做这些。但没有项目管理层去领导或者推动,感觉还是不对。

    CTO 自己花时间在根据新需求改界面设计草图,我实在不能同意这样的工作流程。这些改动完全可以在 use case 阶段修改从而节省大量时间。

    大家的经验又是怎样的呢?没有花时间在软件设计上真的可以?在我看来就等同于没有图纸建大楼呀。

    P.S. 我想在回复里会有人说“要么忍,要么滚”,由于个人原因,我是会两个月之后离职的。
    61 回复  |  直到 2017-08-10 15:47:31 +08:00
        1
    facetest   2017-08-09 08:11:03 +08:00 via Android
    lz 公司是互联网公司吗?如果是,互联网公司一般走的是敏捷开发,快速迭代,很少会搞软件工程那套流程。
        2
    jint   2017-08-09 08:13:17 +08:00
    从两次提到 UML 来看,应该刚入行不久,建议你完整的跟完整个项目,再总结经验教训。
        3
    fengjianxinghun   2017-08-09 08:15:18 +08:00 via iPhone
    画 UML 图太浪费时间了,也没人想看。
        4
    ihuotui   2017-08-09 08:15:47 +08:00 via iPhone
    这样后期肯定坑爹,即使敏捷开发也是每个环节都构思清楚,大家都明白才能开发,敏捷只是把迭代期变小,加快反馈,从而知道目标和实际差距还有方便调整。
        5
    ihuotui   2017-08-09 08:16:43 +08:00 via iPhone
    uml 不一定有,但是 use case 肯定要清晰,要不然写到一半写不下去。
        6
    jamesxu   2017-08-09 08:18:30 +08:00 via iPhone
    我们都是确定原型和数据库设计后就开始搞了,没那么多流程
        7
    wangxn   2017-08-09 08:24:50 +08:00 via Android
    现在有谁用 UML。
        8
    ytmsdy   2017-08-09 08:46:43 +08:00
    我都是拿到设计稿以后,就开始脑补需要那些表。数据要怎么存,然后直接设计数据库。做完以后再过一边,大家讨论讨论有没有什么问题。如果没什么大问题,就开搞了!
        9
    C0dEr   2017-08-09 08:50:30 +08:00
    功能设计和数据库设计总要有文档,不管你是先开发还是先设计。但有些项目的肉太少,那文档肯定是第一个被简化的内容。
        10
    stcasshern   2017-08-09 08:54:05 +08:00
    学习了。前几天面试就是在想这个问题
        11
    Lonely   2017-08-09 08:55:00 +08:00 via iPhone
    CTO:行行行,你来当
        12
    artikle   2017-08-09 08:58:16 +08:00
    在小公司大公司呆过,都没见过 UML,还以为进入假公司,看来大家都一样
        13
    happinessnch   2017-08-09 08:59:00 +08:00
    是先做好设计确定需求再开发,还是边迭代边调整,程度如何,这种事情一定是拥有项目信息最多的人做决定,不管他做什么决定一定是对的,因为其他人根本没有条件来考虑这个事情,只知道开发内容的开发人员跟着团队的节奏走。
    新人比较容易犯的错误之一就是过度设计。
        14
    lonenol   2017-08-09 08:59:26 +08:00
    CTO 还要做这些工作,应该是个创业公司了..创业公司去搞那套复杂的流程不是自寻死路吗..
    大公司貌似也没人画 UML 吧,反正我没见谁画过,最多画个顺序图,梳理一下思路...
    你想想网上那些大神,多谢个分号括号都觉得浪费时间,你让他们画 UML..那不是在谋杀他们吗...
        15
    taine   2017-08-09 08:59:40 +08:00
    了解过 CTO 为什么要这么做吗?
        16
    jhaohai   2017-08-09 09:00:02 +08:00 via iPhone
    uml 只在教科书里听说过
        17
    Patrik   2017-08-09 09:07:29 +08:00
    看楼上回复我好慌……

    我两个学期四门课考 UML 我可能上了个假大学……
        18
    blackshadow   2017-08-09 09:09:35 +08:00
    之前的公司,只要有设计文档,写写思路、实现步骤,数据库设计就行。现在公司,要求画 uml。看着设计文档模板,感觉比我的毕业设计论文要求还高。
        19
    Cbdy   2017-08-09 09:22:54 +08:00
    As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyze what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot."
    --Dijkstra
        20
    x7395759   2017-08-09 09:23:12 +08:00
    真没有用过 UML 了,但是具体的细节的需求还是弄清楚才行。
        21
    depress   2017-08-09 09:24:16 +08:00   ♥ 1
    我在银行,瀑布模型,各种图各种文档都要写,楼主如果喜欢这种可以去银行。
    之前在互联网公司,需求直接变代码,中间步骤省略。
        22
    sweetyang   2017-08-09 09:28:20 +08:00
    我的天,那招聘信息上写会 uml 制图,岂不是扯淡
        23
    loveCoding   2017-08-09 09:40:26 +08:00
    一般公司项目没到用 uml 大杀器的程度
        24
    ezreal   2017-08-09 09:56:32 +08:00
    只在教科书里听过 UML
        25
    nicevar   2017-08-09 10:12:48 +08:00
    UML 十年前拿出来还是很高大上的,现在已经很少有公司用了,说白了这东西已经不适合这个时代了,除了管理层用这玩意在项目中意思一下,刷刷存在感,真没太大用处,反而容易成绊脚石
        26
    evefree2   2017-08-09 10:19:20 +08:00
    cto 对业务比较熟,架构或者其他的不是技术总监或者架构师负责么?
        27
    evefree2   2017-08-09 10:20:03 +08:00
    可能组织结构不同吧,一般来说至少了解点
        28
    ansheng   2017-08-09 10:26:53 +08:00   ♥ 1
    露珠太天真,项目来了一句话一个原型,开干,根本没技术评审这不流程,所以露珠有老大指导还是很幸福的。

    还有,不要怀疑老大的能力,有什么问题直接问,自己 YY 会出事。

    ----
        29
    imn1   2017-08-09 10:34:11 +08:00
    你离职三次会发现个个公司都这样
    你觉得为什么“ CTO 自己花时间在根据新需求改界面设计草图”?
    建议你忍耐做下去,等到去和客户交接时也跟着去,当然记得在客户面前要比忍耐 CTO 再多 200%的忍耐力。然后你就明白了
        30
    parkcg   2017-08-09 10:46:57 +08:00
    需要看所从事的行业是做什么的。如果是互联网公司我觉得不是很需要 这些流程,但如果是开发的是针对某一个行业的软件(银行,证卷,医疗 等等) 那需要把软件工程 的那套流程大部分都走一遍才行。程序员没有经过专门的培训不可能会行业知识的。但这也是国内的软件公司不重视的地方。做好领导交代的任务,每一个任务都 通过邮件进行确认,到时候出问题了 你也不用担责。
        31
    senghoo   2017-08-09 10:49:42 +08:00
    看到大家的回复就放心了,还以为一直做的是假开发。。
        32
    jason19659   2017-08-09 11:07:09 +08:00
    CTO 听完需求就去设计数据库的,基本上就是所有原型在脑子里都已经想好了。
        33
    66beta   2017-08-09 11:26:44 +08:00
    UML 只在考试的时候有~
        34
    sfree2005   2017-08-09 11:34:44 +08:00 via Android
    @jint @fengjianxinghun @wangxn @artikle @lonenol @jhaohai @Patrik @x7395759 @sweetyang @loveCoding @ezreal @nicevar @senghoo 看了诸位对 UML 的看法,我同意画完完整各种的 UML 图 的确没有必要,但在一些很核心的业务有一张图会让我对业务的理解很大帮助,完全胜过一堆文字。我有把图给客户看和解释,再次沟通后发现我有误解,及时改了过来。我难以想象如果这部分写成代码后要改会多用多少倍的时间。
        35
    RubyJack   2017-08-09 12:09:03 +08:00
    设计数据库不是画 ER 图么?
        36
    michaelye1988   2017-08-09 12:25:37 +08:00
    我以前也觉得要设计各种模型什么的,但是后来发现那个东西根本就没有用,没人关心,也没人看。而对于有经验的工程师,其实根本也不需要这个东西,很多人在和我谈需求的时候,其实我就已经知道该怎么搭建框架了。我待过的都是互联网公司,大家讲究的是快速做出产品,跟老板说这些东西?老板更在意这个东西能不能撑过下一轮。
        37
    kanezeng   2017-08-09 13:02:58 +08:00
    对小互联网公司能承受的项目级别来说,很多确实不需要跑完全的软件工程的流程。
    个人认为有几步是必须的,比如简单的产品原型图,都有什么页面,页面上都需要什么内容。如果原型能走通的话,后期需要的修改就少多了。
    小公司如果要从 UserStory 开始的话不太现实,因为很多人员也没有相关的经验,这么搞花很多时间而且最终仍然覆盖率不足,反而不如直接在原型图上讨论和修改。
        38
    hjdtl   2017-08-09 13:51:19 +08:00
    画过 uml,立项写需求文档什么的,当初对于我来说太难了,还好最后还是把项目完成了。
        39
    bzzhou   2017-08-09 13:57:58 +08:00
    你这种心情可以理解

    我自己反思自己以前也有过同样行为,现在想想自己当时才是傻逼呀,不过谁没年轻过么,是不?
        40
    zyltd1990   2017-08-09 14:01:25 +08:00   ♥ 1
    UML 没写过,Use case 肯定要的,如果没有,除非整个产品非常简单,不然在开发过程中会有非常多的坑,返工严重。 另外,别拿伪敏捷开发来掩饰自己不懂得产品管理流程。敏捷开发里面就就有强调该怎么尽量避免需求的变更,但是我从楼主的说明中并没看到这些。 经历了几个创业公司,打着敏捷开发的幌子,实际上就是瞎搞一气。
        41
    tabris17   2017-08-09 14:09:13 +08:00
    UML 画给自己看么?你确定工期来得么?

    其实很多情况只要有用例就可以了
        42
    rswl   2017-08-09 14:09:38 +08:00
    当 CTO 开始设计数据库的时候说明脑海已经画通了
        43
    sfree2005   2017-08-09 14:10:25 +08:00
    @zyltd1990 我觉得我目前的状况就是你说的那种创业公司,我就是为了避免我日后需要返工才更主动做需求分析。敏捷开发也要需求分析的,不是吗?只是变成产品局部模块的需求分析。
        44
    huanglexus   2017-08-09 14:11:32 +08:00
    严格的 UML 和 Use Case 定义只有教科书或者外包公司才会用。

    现在这些互联网公司用的所谓的敏捷开发,Scrum 框架,1 周或 2 周为周期作为一个 sprint,鬼才有时间做什么 UML 和 UseCase,都是看完 prd 文件直接开撸原型
        45
    hitmanx   2017-08-09 14:26:40 +08:00   ♥ 1
    看公司吧.上家公司设计阶段,架构师肯定是要出 UML 的,具体类的继承关系,接口函数什么的.也需要把各种用户用例的边界条件\异常处理讨论清楚.现在这家公司没有,不过伪代码和数据结构这些在设计文档里还是有的.
        46
    chmlai   2017-08-09 14:26:42 +08:00   ♥ 1
    要看什么样的系统, 和大公司小公司没有关系; 要是业务非常复杂的系统靠几个 UI 原型就开工的多半会坑爹;
        47
    justfindu   2017-08-09 14:32:13 +08:00
    CTO 为啥要做这些工作
        48
    sampeng   2017-08-09 14:40:43 +08:00
    除了非常复杂的逻辑画一下 uml。其他的脑子里都有了。。有点浪费时间
        49
    Taojun0714   2017-08-09 15:00:56 +08:00   ♥ 1
    @facetest
    @huanglexus 敏捷开发就是最常见软件工程,国外正经互联网公司敏捷开发 scrum 框架,uml 用的少,但必然要有 Use case,user story
        50
    Shazoo   2017-08-09 15:04:53 +08:00   ♥ 1
    完整的 UML 图是应该有的。但是,并不是说非它不可。

    规模小的时候,为了速度,不写这个也没啥问题。(只要沟通及时)

    反之,开发日志和开发过程的实现文档是必须要得记录下来的。
        51
    otakustay   2017-08-09 15:26:08 +08:00
    UML 是没必要的,但重点功能画几张草图留一点文档显然是必要的,楼上都把文档和设计当成啥了……
        52
    zyltd1990   2017-08-09 15:44:02 +08:00   ♥ 1
    @sfree2005 我想大家可能有个误解,把 USE CASE, UML 和 PRD 混为 一谈。 我不知道你们公司有没有 PRD 文件,PRD 文件应该要包含有需求说明,而 USE CASE 就是一种大家最为熟悉的需求说明。身为产品狗,我也经历过那种听了几个人的意见就开始撸原型,撸界面的时候,这种情况的结果通常都不会太好,不是产品没人用,就是体验相当差。
    上面有人提到 Sprint,我想 use case 主要是由 product owner 或者是 product manager 决定的,这和 sprint 有什么关系,这些是在 sprint 开始之前就准备好的,如果没有这个凭空开发,那不是敏捷开发,那是瞎搞。
        53
    chztv   2017-08-09 15:46:57 +08:00   ♥ 1
    团队需要有默契吧,楼主家的 CTO 是刚来?还是楼主入了一个新团队?
    每个团队只要有自己的默契就行,Boss 说要 UML,那就画呗,既然 CTO 觉得没必要 UML,楼主不用那么在意。
        54
    a591826944   2017-08-09 15:49:38 +08:00
    美人花 UML 了。。很少很少的。。确定需求,PR,数据库设计等 就开工了
        55
    sfree2005   2017-08-09 16:15:21 +08:00 via Android
    @facetest 说是敏捷开发,但我连产品需求很多都模模糊糊的时候,敏捷不起来呀。

    @happinessnch 我是连基本的设计都不全下不了手呀

    @taine 他想快点出东西,但对于我,我没进食(input )实在拉不出屎( output )呀。但他是支持我继续需求分析的,这不错。

    @evefree2 小公司,他有时会客串

    @ansheng 我也有和他讨论,也能发现自己设计中没有考虑好的地方

    @imn1 我也会和客户沟通,客户挺不错,她对我的需求分析也感兴趣,我会给她讲解然后听她意见,最后修改设计和她确认
        56
    huanglongtiankon   2017-08-09 16:37:19 +08:00
    UML 就没必要了吧,我都没见过,有明确需求就好,客户端的设计可以用各种原型工具,数据库设计只要需求大概定下来就能做的了啊,我觉得你主要的问题是需求不明确吧
        57
    imn1   2017-08-09 16:38:57 +08:00
    @sfree2005
    不是说你所提的想法不好,只是你的这种想法会被岁月和环境磨灭
    其实你的 CTO 以前以前的想法是和你相同的,但他现在就是被磨灭的过来人

    感觉你没分清 “客户” 和 客户 的区别

    沟通一切顺畅,最后演示不通过的,遇的多了
    因为沟通的那个人不是最后拍板给钱的那个,这就是“客户”和 客户 的区别
    希望你这次遇到个好的客户吧
        58
    sfree2005   2017-08-09 18:16:32 +08:00
    @jason19659 #32 简单的项目我也是这样,但这次的项目比较复杂或者说这种类型的项目我没有经验,真的需要好好分析才敢动手干。

    @sampeng #48 嗯,我只是在业务复杂的那一部分画,而且也只能算是不正规的 UML 图。

    @tabris17 #41 关键是我连用例都没有~~~UML 主要是自己看,还有和同客户沟通时确认。工期还好,不是太赶。

    @rswl #42 数据库 CTO 有弄,我经过我自己的分析我有在上面更改,CTO 和我接收到的信息量是一样的,只是我比较有时间做些分析什么的

    @huanglexus #44 我的 PRD 是简陋到不能再简陋那种,不敢马上就下手,或许是因为我的经验还不够吧。

    @chztv #53 他不是刚来,有合作一段时间了。Boss 不会插手这些事,都是我们自己商量。

    @a591826944 #54 关键是具体需求,PR,数据库设计这些都没有,我需要自己分析。

    @huanglongtiankon #56 是的,非常的不明确。

    @imn1 #57 还好 CTO 没有倚老卖老,禁止我去做那些事情。这次也算幸运的,拍板给钱和沟通的是同一个人。
        59
    eyp82   2017-08-10 06:46:10 +08:00 via iPhone
    听楼主这么一说感觉这个 cto 为人还不错的样子
        60
    tabris17   2017-08-10 12:40:14 +08:00
    @sfree2005 至少有个什么书面文档吧,难道都是口头描述?没有用例测试也没法测啊
        61
    sfree2005   2017-08-10 15:47:31 +08:00 via Android
    @eyp82 是的 他人不错的。
    @tabris17 有书面文档 但只是很概括性的东西,只有十几页而已,没有用例,没有图
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   948 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 27ms · UTC 21:54 · PVG 05:54 · LAX 14:54 · JFK 17:54
    ♥ Do have faith in what you're doing.