企业官网建设流程全解析

从前端转向产品大概三周左右, 借由《我转产品了 - 前端转产品是种怎样的体验》这篇文章, 将自身的一些感受分享给大家, 评论区突然出现好多厉害的人。因较为忙碌, 不知不觉间似乎一下子又过去了一个多月, 此次趁着周末没开成会议, 给大家讲讲最近的“有意思但又很奇特的事”。

当前, 正在并行开展的一个项目重点具备类似文件管理的功能, 于这个项目里, 自身处于主要是旁听的角色, 此项目的产品以及需求系由公司的一位产品朋友负责完成。在文章里, 产品功能描述部分鉴于众人皆知的缘由, 我仅仅会大致简略地提及一番。

客户说的

作用是对传统OA系统里有的某些较繁杂操作予以化简处理, 效果可要编辑、预览, 若未具备这些功能, 也还是可以的, 可先推出上一版。

我们准备给客户做的

头一批原型是我们给客户画出来的, 在浏览器里面登录了一个网址, 去注册一个账号, 还有密码等, 之后啊, 于文件系统当中没准能在线预览像图片、PDF、word、excel这类东西。

客户其实想要的

于演示之际, 首个界面呈现时, 客户发出质问, 为何我们的系统仍需输入网址, 仍需进行登录操作? 众人一时皆满脸困惑茫然。随后作出解释, 因数据存于服务器处, 于浏览器内输入地址就能够对我们的系统予以访问。再者, 倘若不借助用户名与密码登录, 便无以知晓究竟是谁了。

客人讲出这样的句子：“我们所拥有的云桌面, 对于每一个人而言, 皆是具备唯一性的呀, 并不需要再度去准备一个账户……”。

下面这些话是我们讲的哦: 由于我们的系统是处于浏览器之中的, 而浏览器没办法访问操作系统里的用户信息, 所以要去注册一个用户密码……要是感觉这样麻烦的话, 我们也能够先在后台进行注册, 接着登录之后记住登录状态, 如此一来就不用每次都登录啦。

客户：『行吧。』

然后讲业务流程……

讲起某文档的审核功能时, 假如审核人打算对word作批注, 就得下载, 接着添加批注, 随后上传至审核意见附件里。

客户：『为什么要下载？』

我们：『因为我们的是浏览器。』

客户：『行吧。』

矛盾分析

演示历经了几周多轮之后, 客户还时常不时地老是问一些关于为何我们系统不能径直开展某操作的念头。不用写到这儿想必大家都明晰了, 客户所想做的事物实际上是一个利于操作的文件管理系统。要达成最大程度的便利性, 最优的做法则是跟操作系统连通。

然而, 我们这个地方, 技术栈方面, 主要是有着较多的B/S架构的经历, 对于桌面程序的经验, 基本上是不存在的。而且, 应当是我们这个地方觉得, 在浏览器里的文件管理操作, 也是极为常见的, 就像各大网盘都能够在浏览器完成文件操纵。

我们调研的方向, 是借助多样的.js.sdk实现功能。此功能为在浏览器里进行word的预览。此功能还为在浏览器里进行excel的预览。

一些自己的想法，不知该如何讲

这次关于产品的讨论会, 来来回回已经有5到6次了, 直至如今居然还没有结束, 虽说从第2次开始, 我基本上就断定, 客户的这一种情况, 应当运用桌面端去实现会是相对较好之上选, 可这般的事物, 实在是不太容易说明白, 毕竟这是需要产品工作人员以及技术人员进行最终决定的事物。

不能随便讲的原因在哪里：

这个应该大家都明白，角色问题。

就这个而言, 挺明晰的, 是难度方面的问题。头先来讲, 倘若做成桌面端, 但团队并无这方面的经验, 要是碰到操作系统相关的 API 调不起来该如何是好? 兼容性又该如何处理呢? 我所知晓的前端决然是实现不了的, 即便 node/能够与操作系统进行交互, 然而当下前端团队里没有具备该相关经验的人员。虽说后端 java 能够与操作系统交互, 可我绝不可能跟客户讲这东西我们这边后端 java 可以做。

想法是这样的, 要是他们跟客户能够达成借助浏览器来完成这个系统共享, 明白了浏览器相较于桌面程序而言所具备能力有着合适的边界范围, 那又为何不这么做呢?

我方开始妥协

于第6次进行演示原型那当口, 客户再度提及, 若存在一个文件需要去进行下载这一情形也是可行的呢。只是启用该系统之人年龄或许都相对偏大, 而要下载到何处他们时常都寻觅不到。

这情形的确不假, 每个文件都需要先下载来实行操作, 之后再进行上传, 已经相当繁琐了, 况且还要类似在垃圾中将刚刚下载的文件寻觅出来, 那就愈发麻烦了。客户询问是否能够对系统里我们可以限定的当下载位置进行指定?

我们再次表述下载位置是由浏览器所规定的, 并非系统能够指定的。之后, 客户提出如此这般, 实现起来不像诸如ftp这类工具那般效果, 能够将文件传递到某个特定指定位置也是行得通的……

随后, 我们的技术负责人讲道, 倘若如此这般, 那瞅一瞅可否将两台设备彼此联通互动一下, 在那个浏览器当内需下载某一文件之际, 冲着后端发出请示, 之后后端在服务器那儿对客户端电脑加以操控, 那个客户表明表示如此可行！

我理解上一段话下来是这样：

客户端与服务端存在着一种特定通道, 该通道使得服务端能够对客户端进行操作, 像文件的创建或者删除之类的情况。接着, 当客户端浏览器要将某个文件下载至C盘的时候, 会向服务器发起请求, 此后服务端进到后台里, 把那个文件下载至客户端的C盘。

肉眼直视之下好像也是能够得到实行可行之结果的, 对于前方的端侧浏览的器具来讲依旧是同样的情形, 径直朝着服务的那一端发送求取之请求便可以达成了。

但是我的想法是这样的：？？？

准备好了吗？坑要来了

上面所提及的功能得出的结果乃是可行的状态, 并且客户对于该结果也是处于接受的情况, 而且前端同样是如此, 即仅仅只需朝着服务器发出相应请求便可达成。然而我存有以下这般想法:

据我所明白的, 存在那么一种自天而降的掌法, 称作 , 其主要是从前端着手处理。然而这物件的体积太大了, 当然, 在当前客户所处的情形里, 体积并非是首要考虑的紧要问题。首要的关键问题在于, 这东西尽管相当厉害, 可是此地的前端并不懂得node。另外, 还有一些方案, 诸如浏览器插件配合、WPF这些也就全都不用去提及了。

那么是否存在这么一种方式, 它在条件上对于掌握 node 这件事不存在要求, 对于后端语言像是 java 或者 C# 也不存在需要掌握这方面的要求, 对于安装依赖包含运行库以及浏览器插件这类情况也是不存在需要安装的要求, 并且还能够和 前端已经编写完成的页面以及接口相兼容, 要是存在需要调用系统 API 的情形像是文件、IO、进程, 通过那种方式前端只不过在调用 js 方法之际去传递参数就行了, 大概类似。

从针对我个人的见识范畴以及需求范畴来讲, 差不多等同于没有。因而我计划自己搞一个（挖坑）。然而我不可以讲我要挖个坑呀?

开始挖坑

我以尝试性地姿态询问技术负责人, 要是采用套壳浏览器的方案, 前端按正常方式撰写, 当要对文件进行操作之际, 前台能够直接调用 js 方法, 诸如创建文件、打开文件、定位文件等等。您瞧瞧这样行不行? 负责人提出疑问, 那进行文件修改上传的检测可不可以? 我怔愣了两秒钟的时间, 随后表示行得通（哪怕没办法监控修改情况, 也仍然存在通过获取文件 MD5 进行对比的途径）。接着我于是说道那我在会后给您呈递一些 demo 供您查看。

给出一些 demo，让坑看起来没有坑

考量到要证实方案具备可行性以及便利性, 于是, 采用所用团队当下的技术栈Vue, 针对当前文件系统极有可能会运用到的各项操作, 均给出了示例。

把图标、描述定制好, 然后将其打包成这个单独的exe, 这个exe体积是1.2M, 似乎有点大了, 不过就这么着吧。

实测几次没问题之后，发给技师负责人。

技术负责人：『？？？』

不确定那时负责人心里是否在思索: 啥东西呀? 没事情可做吗? 给我发送个exe? 是病毒吗? 你很厉害吗? 产品试用期结束了吗?

// 可以编程式创建窗口。 const view = await new main.View(`http://baidu.com`) view.form.show() // 显示窗口

前端对该方案的实测效果

也可以指定本地文件，例如 .html 。

{ "page": "desktop.html", "pageShow": true }

没过多久, 前端同事把负责人跟他之间的沟通转发给我, 随后满脸疑惑地询问到底要做些什么, 在一阵一阵的沟通后, 才晓得会议内容压根没同步给前端同事, 讲了好长一阵子客户需求之后, 才渐渐明白要弄一个客户端, 然而他又一次陷入惊愕, 我身为一名前端人员, 凭怎么样的缘由让我去搞客户端, 我根本就不会！

忽然之间, 我的感觉是, 自己陷入难处了。随后，我这般说道: “并非是我要求你去弄客户端。而是客户有客户端的需求。我仅仅是给出了一项方案, 你瞧瞧, 是否可行呢”。

接着, 让他先把我所提供的dmeo, 在他自己的电脑之上用来一试, 看看各个相关功能是否都是正常的情形。

很感动，果然没有问题。

然后同事问：『那这东西把我现在写的系统放进去能正常用吗？』

真的是个问题, 我说道, 说的是, 不知道, 你可以去尝试一番, 并且建议采用路由 hash 模式。

之后, 同事径直将自身系统的链接放置进去, 试着进行若干自己原有的功能, 这些功能的表现属正常状态。

然后同事问：『这东西基于什么技术，关键词？』

我答：『。』

紧接着, 同事去进行了一番搜索, 之后甩给我一张截图, 随后向我问道: “跟 edge 是同样的情况吗? ”。

我说：『不严格等于，但约等于。』

也不知道同事看了这句话有没有骂我，搁这给我玩哲学？

又有其他同事发问了, 问的是, 客户所使用的电脑是 win7 系统的, 而客户的那台电脑上面还没有安装 edge 浏览器, 这种情况该怎么处理呢?

我：『拿我的 demo 上去，能打开就是支持的。』

从理论层面来讲, 要是客户的电脑之上不存在相应环境, 那么便会自行开展安装操作。然而, 客户所处的那边网络环境是无法连通外部网络的, 所以我要求直接进行尝试。

然后一会之后，实测下来，还好就是支持的。

前端的同事接下来会尝试运用我所提供的 api, 在已有的项目里对操作系统上的内容进行操作。一番沟通之后, 实际测试也不存在问题。

疯狂暗示，我挖的坑，与我无关

在这会儿发生着一边处于沟通怎样让我的轮子被入坑的状况之际, 与此同时, 我还给出了前端用来实现桌面程序的别的方案以供其去进行挑选, 并且时刻都没有忘记去进行提醒, 你瞧瞧哪一个是适合你的就选用哪一个。这个exe是由我来进行封装的, API仅仅只有示例, 详细的文档是来不及去撰写的, 对于桌面程序我同样是没有太多的经验的。

备注一下, 意思是这样的, 方案是由你来进行选择的, 要是选择我的轮子, 某些功能我是要先去研究一阵子的, 某些功能我也存在解决不了的可能性。并且我当下主要的重心是放在产品上面的, 所以有可能没有时间去研究新功能。 /手动狗头用来保命。

小惊喜

虽说晓得, 麻烦着, 可我这儿着实没文档, 也麻烦, 可是过了好些天, 忽地收到消息:

然后我邪魅一笑（哈哈哈哈，入坑了！入坑了！入坑了！）。

后记

这个坑并非我蓄意挖之, 乃是特意挖掘而成。缘由在于存有一想法, 拟开发一款简易的桌面程序, 仅采用前端语言予以开发, 暂且仅思量于其上运行, 期望开发体验仿若于浏览器之中那般, 继而言程序之模样恰似本地应用那般, 调用本地文件、系统命令、后台运行、托盘菜单这些均无任何问题。

我对一些常见的方案做了调研, 结果发现, 大多数情形下他们都不喜欢, 原因在于, 这些方案常常体积过大, 或者对除此之外的其他语言有所要求, 存在某一个方案, 从表面上看, 在实现方面是自己期许达成的目标, 然而其提供的应用程序编程接口个数过少, 由此, 我决定含着眼泪去打造一个新方案, 在这个新方案的应用程序编程接口设计环节, 我会充分考虑使其更加贴近, 进而方便两者之间能够顺利迁移。

代码仓库在这里

，如果有愿意的小伙伴，可以 star 支持一下。