世界上分为三种人:第一种是精通技术的人(技术大牛),第二种是懂技术但不精通的人(小菜鸟),第三种是一点技术都不懂的人(客户)。
当技术大牛和小菜鸟相遇,正如“师者传道授业解惑,学者程门立雪“,最终桃李不言下自成蹊。
当技术大牛和客户相遇,前者明白后者的想法并很快付诸于功能实现,这是一场棋逢对手、将遇良才般畅快淋漓的故事。
当小菜鸟和客户相遇,前者明白后者的想法但无从着手,抓耳挠腮绞尽脑汁终于想出满足客户需求的方法,经过和技术大牛进行可行性分析之后,开始了一段跌跌撞撞在不断摸索中进步的神话故事······
1月23日,小菜鸟开始和客户接触,为其讲解公司自主研发的某系统,并现场进行实例演示。客户方面总共有8个人在场,级别最低的也是科长级别,小菜鸟心里那个紧张哟!小菜鸟还没一下子见过这么多的大官呢~~
小菜鸟演示完系统之后,客户这边对系统的功能给予了充分的肯定。但是·······这一转折,代表着小菜鸟的“悲惨命运”即将拉开序幕。
客户表示,你们的系统功能虽然强大,但是配置起来太复杂了,你讲了一遍之后,我们听得都是云里雾里,看得眼花缭乱,系统中的专业术语太多了,我们根本不知道你说的是什么意思,我们只看懂了系统运行之后的结果,嗯,这个不错!小菜鸟哇凉的心肝终于稍有慰藉。
至此,一直以此系统为傲的小菜鸟心里凉了半截,按照客户的说法,咱们这个系统就像是一个侠客,空有一身深厚的内功但却缺乏一招制敌的招式,终究难以笑傲江湖、独步天下。身为武侠迷的小菜鸟迷惘了,令狐冲遇到了风清扬和任我行,杨过师承独孤求败,郭靖有江南七怪和洪七公······小菜鸟该去哪拜师呢?
痛定思痛,痛何如哉。聪明的小菜鸟终于想到了办法:偷师学艺!
于是,小菜鸟偷偷溜到了“八爪鱼”、“火车头”、“网络矿工”等江湖上久负盛名的大师们的府第,开始了猥琐的学艺历程······
最终,小菜鸟终于偷到了大师们的武功秘籍。
有了秘籍,谨慎的小菜鸟就跑回家跟技术大牛们探讨秘籍的技术可行性,万一秘籍是假的,练不成绝世神功反而走火入魔、经脉错乱那小菜鸟可就该歇菜了。经过技术大牛们的分析,此“秘籍”是真的,可以练!
练就练呗,要不怎么能成为一代大侠呢?小学练算数,中学练方程,高中练函数,大学练编码····小菜鸟最喜欢练了。于是乎,小菜鸟开始了一段精彩如美国大片的练武经历····
客户不是不想输这输那的嘛,那就不输呗!客户就喜欢点点点(哪里不会点哪里,当是点读机呢?),就像六脉神剑那样。
客户是上帝,小菜鸟深信这一点,所以小菜鸟必须满足客户“点点点”的要求。
客户想点点点,你得将网页加载进系统,系统用什么元素呈现网页呢?最后选择了iframe。如果网页中没有再嵌套iframe还好说,要是再嵌套一层iframe呢?一层不爽,再套一层呢?······我嘞个去,没完没了了还?网页各式各样,小菜鸟只能想通用的办法。这难不倒聪明的小菜鸟,你想嵌套几层就嵌套几层,自动加载就是了。小菜鸟心中颇有一种“任你风吹浪打,我自岿然不动”的淡定。
用户想点点点,你就得让人家点啊!结果,一点就出事了:“出轨了!!!”。用户在系统中点击页面,页面直接跳出系统,直接在浏览器中自动打开了标签页。小菜鸟只能将iframe引用的网页的点击事件全部移除。“你随便点,我就当你没点过!”无视是最大的反击。可是小菜鸟真的无视吗?当然没有!客户的每一次点击,小菜鸟都接招了,只是让你看不到。“我不说,但是你的心意我都知道”。
可怜的小菜鸟又发现一个问题,iframe将网页加载后,就不能对网页进行处理了,因为要“跨域”。
聪明的小菜鸟想到了办法,网页加载后不能处理,那就在加载前处理呗!加载前,网页的呈现方式只是一个url,这怎么处理???这个好说,下载到本地就行了呗!在本地你想怎么搞怎么搞。当前摆在小菜鸟面前的问题是:如何将网页完整地下载下来?图片要不要下载?css要不要下载?js脚本要不要下载?
为了缩短网页下载时间,小菜鸟决定只下载网页源码,css、图片、脚本直接引用远程服务器上的就OK了。
信心满满的小菜鸟说干就干,网页下载下来了,那就加载到系统中瞅瞅呗!
一瞅,小菜鸟傻眼了!我嘞个去,这一坨是什么?好像是臭臭!
善于究根问底的小菜鸟去看下载下来的源码:哦,明白了!css引用的是相对路径,你得用绝对路径才能访问得到啊!小菜鸟刚才不是吹牛说“在本地你想怎么搞怎么搞”嘛!好嘛,自己挖了坑,那就自己跳吧~!结果,小菜鸟跳进去了,又跳出来了,这个问题也解决了。
看着系统中美丽的页面,小菜鸟心里的那个爽哟!
再换个网站试试!
换上了国家税务总局的官网地址,小菜鸟一看又傻眼了!
网页只有头和尾,中间的“身子”哪去了?这么大的一片空白,好像捅破的窗户纸!!!太丑了!
小菜鸟多聪明啊!还是去网页源代码里看去,这是一切问题的根源。
好嘛!里面又嵌套了一层iframe,只下载了父页面,没有下载子页面。这个问题也好解决:在本地文件中建立相对应的目录结构以对应iframe的嵌套关系,将网页源码中的iframe的src属性全部设为相对路径就ok了嘛!小菜鸟果然聪明,一试,果然OK!(其实,小菜鸟一点都不聪明,下载网页的时候,为了防止本地文件无限制地增长,小菜鸟每下载一次页面前都会将原来的文件全部删除。结果,路径搞错了,将系统文件给删除了几个,小菜鸟心里怕死了!系统执行的删除文件操作,在回收站里压根没有。这是自己好几天的心血啊!要是重写,还需要浪费不少的时间。于是小菜鸟先是从eclipse中恢复,再使用360文件恢复,总算恢复了七七八八。经过这次的死里逃生,小菜鸟真真切切地感到了数据备份的重要性。这是后话。)
好了,网页下载下来了,显示正常,也不会出现误删系统文件的问题。用户可以随便点击,都不会出问题了。
接下来,小菜鸟面临的是如何接招(处理用户的点击操作)的问题。因为有的网页层层嵌套,你看到的虽然是一个页面,其实用户点击的很可能是层层嵌套中最底层的页面。于是,解决iframe父子页面之间的通信问题迫在眉睫。我将此过程称之为“事件追溯”。如果用户点击的是底层页面,你需要分析各级iframe之间的关系,然后将事件处理后将处理结果层层上传(重孙子上报孙子,孙子上报儿子,儿子上报到top页面)。
用户“点点点”的功能基础就是xpath选择器,这是此次研发核心中的核心。用户有点击操作,小菜鸟要知道用户点击的是哪个元素,然后后台自动生成xpath路径。然后系统指引用户去进行测试,用户“点”了测试按钮,系统要逆向获取元素并后台触发,看有没有达到预期的效果。如果达到预期的效果,用户“点”保存即可,如果没有,则要反馈给运维人员,由运维人员从技术上分析问题的症结所在。
还有许多遇到的问题,在此就不再赘述了。
如果您对上述问题您有好的解决方法,还望各位技术大牛不吝赐教!
看了那么多文字了,来秀个图吧!
客户不想输网站编码,小菜鸟就得去后台自己获取编码;
客户不想输存储表名,小菜鸟只能根据任务名称后台自动生成表名,默认保存,让客户“眼不见,心不烦”;
客户不想输频率,小菜鸟就得去实现后台自动调整频率,万一ip被封那就将频率调大一点;
·············
总之,在技术可行性的基础之上,尽可能减少用户的操作。
总结下:一个开发人员,如果能将自己的所有技术都忘掉,真真正正地站在对技术丝毫不懂的用户角度审视系统,才能开发出集“简单易用”和“功能强大”于一体的系统,如此才能达到武功的最高境界—“无招胜有招”。
——— 一只在痛苦中快乐着,在快乐中进步着的聪明可爱的小菜鸟
2016年3月20日