京东一小伙一年输出20篇专利,其实你也可以

前言:

        本文属于技术总结类干货分享,是实战但又不同于实战,所以不能保证每位同学读后都可以立马自己也输出一篇合格的专利;

        ☆ 但通过本文的总结分享,已经帮身边同学半年内输出大于100篇专利,所以如果你细致的读到最后,再结合自己的实际开发经验,是可以有所思,有所为的;但如果只是走马观花的看一遍,可能是没有效果的。

        ☆ 本文发布于CSDN平台,不带有任何业务信息,不带有任何代码信息,立足于行业内总结思考而分享。

        ☆ 希望本文可以给你带来帮助。

目录

一、为什么要写专利

1、各有原因

2、写专利的好处

3、给面试带来的好处

4、开发人员不爱分享

二、做为开发人员,我们写什么?

1、微小而垂直的创新

2、你熟悉的领域

3、找痛点

4、有些东西不能带到专利里

5、从哪里找到那么多痛点?

三、一篇技术专利的生命周期

1、构思阶段

2、利用模板文档书写

3、提交,等待专家评审

4、外部撰写机构

5、等待专利局评审

四、当场写一篇吧

描述准备:

1、当前业内问题

2、当前行业内的解决方案

3、目前解决方案的痛点

4、本方案要实现的核心

5、本方案的实现步骤(语言步骤)

6、本方案实现步骤(流程图步骤)

7、专业名词解释

最后

一、为什么要写专利

1、各有原因

        有人是被动的,公司内部有要求,年初或者季度之初有KPI,每个人要求产出一定量的专利;有人是主动的,通过工作中发现的痛点,进行业内方案实现与总结,再利用模板快速输出;有的人没有输出过,干过的公司没有这个业务模块,没有这个要求,身边的人没有类似经验,所以一直还以为专利是一个非常高精尖的产物,非常人所不能,所以不知道怎么产出。

2、写专利的好处

        专利这个词如此的高端,写了一定是有好处的。有的公司会给予的一定的奖励,有的公司会进行表彰没有奖励,有的公司甚至没有这项业务。

        写一篇专利,首先锻炼的是自己对于某一个技术实现的思路创新,慢慢影响的时候身边的人,或者需要用到这项技术实现的所有人。

        所以你得到的不仅仅是一张纸,可能是额外的金钱,可能是圈子内甚至业内的专业影响力,还可能会更多。

3、给面试带来的好处

        也许你输出的只是一篇普普通通的专利,但如果你可以表现在简历上,这绝对胜过一个重点项目。HR一定会觉得此人头脑灵活,可以帮助团队解决问题。而技术leader看到你的专利,至少他会觉得你可以给他们的团队带来一定的活力,将来一定可以带动整个团队的专利事项。

4、开发人员不爱分享

        一直到现在我发现很大一部分开发人员有一个共性,不爱分享。宁愿自己熬夜加班做需求,但不喜欢跟别人review自己的代码;可能让他研究一项技术点,但他却不想跟人分享他是如何完成的,甚至答应下来要分享,却也不知道以何种形式来分享,搞得分享会很多人就是听一听,他讲一讲,只要别人不用你这项研究成果,那么他就不会主动去参与讨论;很多人不想分享,怕自己的点子被人提出质疑,让自己难堪;有的人不敢当众讲话,紧张,记得有一次晋升述职,有个同事讲着讲着断片了,讲得自己满头大汗。

        也就是不爱分享,不想分享,怕自己写的专利被人质疑,甚至感觉自己会受到嘲笑,所以宁可不参与。以上的各种技术人员的惰性,担忧,一旦你输出一篇有力的专利,影响到别人,不就可以在提升自己影响力的同时,战胜掉那些惰性和担忧吗?

二、做为开发人员,我们写什么?

1、微小而垂直的创新

        现在如果你想做一个大的创新,那已经很难了,但我们仍然可以从日常手头的工作中去发现某些小的技术类创新。

2、你熟悉的领域

        而专利写的一定是你所熟悉的领域,也就是开发领域。切不可发现马桶哪里不合适了你写一写,你发现快递盒子哪里不合适了,思考一下。这是很难的,因为你对那个领域不够熟悉,那么你想出来的很可能是人家已经淘汰掉的思路。

3、找痛点

        其实刚开始我听到痛点这个词的时候,听着挺别扭的,觉得就是很多人爱噪生词,痛点痛点,听着真难听。但久而久之,发现这个词是真的很恰当。因为痛,我们才要费心费力去解决。这里从前端角度随便举几个例子吧,怎么算痛点。下一步呢,我会随便举一个例子,带大家分步骤写一篇专利。

        △ 比如你网站的图片特别大,所以每次渲染的时候就很慢,这已经算痛点了吧,你经过查资料,去各种平台查,又问过很多朋友,经过努力发现已经达到最大的进步空间了。这个时候你再想出来的点子,使大图片渲染的更快的这个点子,就是你独一无二的专利初衷;

        △ 比如你的管理平台已经做到第4期了,前3期都用的elementUI,到第4期的时候做一项工作,出了一个技术难题,比如el-table那根线就是怎么弄也弄不好。而更换UI组件已经不可能了,而目网上以至于element团队都没有解决这个问题。你经过自己的发力,最后采用了何种手段得以解决,这就是你的专利点子;

        △ 比如你的H5页面要嵌套到webview内,发现了一个问题。而这个问题业内为了达到相同效果,没有解决而是选择绕道而行的方式,那么你的解决方案就是独一无二的;

        △ 可能前3种都比较有难度,也可以是某一种实现方案,目前大家都是如何做的,但基于事物的两面性,每一项实现方案都是又带来了弊端的,那么你就可以想一种方案,只要是与其他几种实现方案不同的,而且也不会带来他们的弊端,也是可以写的。

4、有些东西不能带到专利里

        专利总计出来以后是一个方法论,是解决整个行业内某个问题点的方法论,所以你的专利里切记不带有某一项平台内的特殊业务,因为可能你这个平台业务在外面的公司平台根本就没有,而且你写出去也有泄漏公司业务机密的风险;

        不能带有代码,你的步骤,实现应该一种方法论,而不是特定的某一种开发语言的代码,所以有代码的部分要用语言去实现。而且要让别人可以看懂你的思路,步骤,解决的问题,而不是贴一段代码。

5、从哪里找到那么多痛点?

        当然是你最熟悉的开发领域,从你日常的开发工作中,只要你足够细致,你会发现每天日复一日的工作可能大家都是这么做,但你却在一个bug中发现了与众不同的东西;

        从日常的分享会中,只要有人分享,那么他一定是经过深思熟虑过的,而你经常他的思想的指引,再结合自己已知的实现思路,相信只要肯用心,总能憋出一种新的方案;

        读别人的博客,虽然现在博客良莠不齐,但读的多了,总能发现哪些人是在分享干货,哪些是在拷贝别人的经验去增加自己的平台积分,相信百篇博客中总能找到一篇与众不同的,也许这个与众不同的就会给你带来思路。

三、一篇技术专利的生命周期

5381d4b36c864ad88c458f298882a92e.png

1、构思阶段

        专利最重要的就是你这个点子是否足够新颖,是否足够解决当前痛点,所以在决定要写一篇专利的时候,一定要衡量,对比自己的这个思路,是否可以成型,是否会被评审专家否决掉,如果有人提出质疑你该如何提出自己准备好的观点;

2、利用模板文档书写

        专利最初的文档也就是交底书,是有一定的模板规范的。而不是自己写一篇流水账文章就完事了。不过这篇模板总算不是特别难,而且只要你写一个,根本谈不上难。

        记得有一次需要写PPT,我就想到了这么多年的office软件经历。word是干什么用的?写字的。excel是干什么用的?写字的。PPT是干什么用的?好像还是用来写字的。

3、提交,等待专家评审

        其实很多大公司可能有所谓的评审专家,他们可以根据自己的经验,去评判你这个点子或者构思是否足够新颖,解决了你所描述的问题。但有的公司所谓的专家,可能你写的东西他也不知道,也不懂;甚至有的公司没有评审,总共也没几个人,没法评审,直接就跳到下一步了;

4、外部撰写机构

        几乎很多公司吧,内部不设有专利撰写部门,有第三方专业的团队进行撰写。他们同样会根据你的初始稿也就是那篇超级简约的交底书进行评审,他们可以搜索到更全的平台文档,根据题目,内容,思路做对比。如果有重合度较高的,会问你是否还要补充或者想出更加不同的实现点子;如果他们这一步也通过了,最后会写一份专利提交文档,准备提交给国家专利局的,他们会把这份文档发给你看看,对他们写的有没有什么异议。一般人估计这一步也提不出异议来,因为你当时写的也就是一页,而他们给看的是一份80页的文档,里面几乎已经找不到你思路的影子了。你就大致看一看就可以了;

5、等待专利局评审

        这一步很漫长,2年到5年都有可能,所以慢慢的你会忘记你还有一篇专利在专利局,也可以更好的让你放心期待的心情,去准备构思下一篇。

        不过在公司输出的专利属公司所有,如果你哪天离职了,哪怕通过了,也不属于你了。

四、当场写一篇吧

描述准备:

        今天我们随便写一篇大众一点的,就不写奔驰一点的了。

        比如某些平台C端展示的是一个图片,用户点击图片的时候会跳转到对应的链接去。而这个链接是由管理员配置上去的。我们都知道管理平台输入链接的地方一定是一个输入框,而这个输入框带来的弊端就是很灵活,管理员高兴了输入一个链接,不高兴了想输入啥输入啥;就算他高兴了,由于每天事物繁杂,可能输入的是一个错误的链接,比如这个链接根本就是一个无效链接,C端用户点了直接跳转到404页面去了,这是一个非常大的用户体验问题。所以今天这篇专利就围绕判断链接有效性来展开。

        以下说的是具体的书写步骤,如果大家觉得这个例子不太适合自己,或者觉得下面的书写步骤比较简单,自己写的时候好好润色一下。

1、当前业内问题

        在当前软件行业平台中,C端前端很多链接URL都是通过对应的后台管理系统配置出来的,而由于管理系统配置存在很大的人为因素,所以时而导致C端链接无效,致使用户在点击到这一元素的时候跳转到了非预先准备得页面,严重影响用户体验。

2、当前行业内的解决方案

        一般情况下为了使管理员在配置链接URL的时候,会进行链接的校验,一般都是通过前端正则表达式,判断输入的链接是否是有效链接,从而很大程度降低了错误链接的配置。

3、目前解决方案的痛点

        由于正则表达式的校验只是判断了链接的格式是否正确,但如果管理员配置的是一个格式正确,但是已经失效的链接,仍然会致使用户跳转到非预备的页面,根本问题仍然得到解决。

4、本方案要实现的核心

        本方案希望可以在验证链接URL的正确性后,利用链接URL的HTTP网络属性,进行一次网络请求,一旦请求未返回HTML文档内容,则表示次链接异常,并做出提示;一旦正常返回HTML文档内容,则表示链接正常,可以继续做配置操作。

5、本方案的实现步骤(语言步骤)

        ☆ 在配置链接URL的输入框后布局一个检测按钮;

        ☆ 当管理员输入完链接URL后,可点击按钮做验证操作;

        ☆ 先通过正则表达式判断链接格式是否正确,进行第一步验证;

        ☆ 验证通过后,向此链接发送AJAX的GET请求;

        ☆ 请求dataType格式设置为HTML格式;

        ☆ 等待请求结果

        ☆ 成功返回,则表示链接正确,给出相应提示;

        ☆ 返回异常,则表示链接失活,给出相应提示

        ☆ 以上,不仅通过前端格式验证,还通过提前试探请求链接URL是否存活的方式,大大改善了配置错误链接的几率,从而有效提升了用户体验。

6、本方案实现步骤(流程图步骤)

abdbb971e79044e196d15ce092309cc3.png

7、专业名词解释

        这里是对本方案中一些专业名词的解释,例如方案中提到的AJAX请求、正则表达式等等,目的就是使比较不懂技术的人也能明白方案的可落地性。

最后:

        使用CSDN平台已经有10年了吧,感谢有这样的平台可以让自己分享一些东西。知识嘛,就应该自己融汇了以后分享出去,只有在分享的过程中才能知道自己掌握的程度,这也是一个突破自我瓶颈的方式吧。

        

232a36a906a84a6ab601d8f1eeaa51aa.png

         之前有个同事的签名是 见自己,见天地,间众生。有时候我还开玩笑的说,你站在大街上不就正是也看见自己,看见天地,看见众生了吗?其实对于我们做软件开发的人来说,每个人每个阶段都会有一个所谓“见”的认识。之前给朋友们分享专利的思考也是同样,自己掌握的东西,我不怕分享给别人,并不是分享给了别人自己就会少更多的思路,就会堵住自己的道路。而是自己分享的越多,探讨的越多,你才能精进的更多。

        希望我书写的内容可以给大家带来帮助!!!

版权声明:本文为博主作者:经海路大白狗原创文章,版权归属原作者,如果侵权,请联系我们删除!

原文链接:https://blog.csdn.net/xingyu_qie/article/details/127892336

共计人评分,平均

到目前为止还没有投票!成为第一位评论此文章。

(0)
乘风的头像乘风管理团队
上一篇 2023年12月29日
下一篇 2023年12月29日

相关推荐