猫窝私语 — Makumo's Blog

玛酷猫的温馨小窝,记录生活点点滴滴。

@玛酷猫2年前

04/20
22:04
计算机 项目管理

再聊聊钉钉开发

之前吐槽了下微信的开发,最近在钉钉中开发一套业务系统,顺便也吐槽下钉钉好了。

起因也很简单,上一家公司一直再用钉钉作为办公OA,相对于传统OA,钉钉更注重移动办公,手机体验感很好,换新公司后,也推荐使用钉钉作为日常办公OA。设置好后,大家也都开始尝试使用,可能是公司大多数人之前很少使用此类软件,对于OA存在一定抵触心理,不过使用一段时间后也都还好,毕竟每天也就占用几分钟的时间。

钉钉里面的业务模块还是比较少,公司的一个业务模块找不到适合的模块改造,于是准备在钉钉下自己开发。最早是准备单独做,后来考虑到办公OA用的是钉钉,很多业务逻辑都在钉钉里面沟通或者下达,何不也一并做进钉钉里面好了,还省得在单独处理用户和登录认证模块,并且以后系统还可以打通。

说做就做,首先还是看文档,虽然两者的模式类似,都是获取相关认证授权信息,然后接口调用,相比微信简单明了的文档,钉钉的开发文档就显得过于复杂繁琐,经常A模块中出现一个参数b需要在B模块获取,有个链接跳过去,然后再看B模块中有个参数c需要在C模块中获取,然后绕来绕去,最后彻底晕菜了。微信的开发仅针对微信内置浏览器,接口也基本两种模式,一种是程序通过API接口进行数据通信,另一种是用JSAPI的模式数据通信。钉钉开发不仅针对内置浏览器,还有PC版软件和第三方APP,相对提供的接口方式就比较丰富。对于我这个项目而言,主要还是使用内置浏览器方式调用web页面方式。文档大概看了几遍,有了基本概念,加上之前微信开发的一些经验。准备着手开发,毕竟文档脱离了具体项目是很难完全理解的。

由于钉钉存在手机版和PC版,这个业务模块在钉钉两个版本都会使用到,PC版为主,移动为辅,这个就要求页面要自适应宽度,在不同的宽度版本(移动和PC)都要良好的提现,文档中也有对于两个版本的一些宽度尺寸的规范。模块的UI框架直接使用了Amaze UI,这个框架以前项目开发中使用过,文档和易用性都还不错,有些功能或者细节方面还不是很好,不够灵活。不过基本能满足一般项目。(其实还是懒得折腾),框架定好了,刚开始开发就遇到一个大坑,移动版和PC版的JSAPI居然不是同一个,这个一开始没注意到(最开始使用的PC版),等到登录开发完调试的时候才发现,PC版获取钉钉登录信息并自动登录业务系统没问题,移动版直接卡在获取钉钉登录信息那块了。后来多次调试加上仔细看了下文档才发现这个问题。知道问题就好处理,加个移动端判断调用不同的JSAPI文件解决。其实个人认为获取钉钉登录信息通过钉钉自身的接口更好一些,跳转到钉钉的一个认证页面上,获取后在跳转回项目并带着认证信息,钉钉文档里面也有这个接口,不过需要申请才能使用,好像还要有一定的要求,本着不折腾的原则(其实就是懒),暂时用JSAPI的方式处理。接下来就是正常的项目开发,暂时用到钉钉接口的地方不多,最多的也就是将项目里面的信息推送到群里面或者DING下某些人。

钉钉的调试也不是很方便,比微信好的地方就是调试非接口性的功能,钉钉可以在普通浏览器调试,而微信接口控件会直接提示请使用微信打开。但是调试接口方便的,微信可以在官方的开发工具里面调试,而钉钉就只能在客户端调试,好在有PC版的钉钉,至少不用老是在手机上面点来点去了,也希望钉钉会对应出个开发工具,至少方便项目的调试。

针对钉钉不断侵占企业OA这个市场,微信也针对的推出企业微信,虽然之前微信也推出过企业号,但是功能简单,易用性差加上功能没法定制,估计也没多少企业再用。这次的企业微信完全朝着钉钉去的,不可否认企鹅的借(chao)鉴(xi)能力,面对小企业基本能碾死一大片,这回面对阿里,最终结果还不得而知,不过借助微信的势,不可小觑。

再聊聊钉钉开发

@玛酷猫3年前

01/19
11:14
计算机 项目管理

微信开发闲扯

自从去年6月份开始接手微信开发,算下来也有半年多了,其间进坑无数,所幸依旧尚存,不得不吐槽下。

首先要说的就是微信这种开发模式,简直丧心病狂、毫无人性呀,不知道当初开发团队是处于什么考虑的,流程各种绕,前置依赖很多,虽然说有开发文档,但是如果你不去开发项目,仅仅的是看文档的话,直接就绕晕掉了。订阅号和服务号,再加上认证,就是四种类型的账号,对应不同的接口权限,加上微信开放平台的接口,微信支付的接口,零零总总一大堆,居然后面还有应用号,不知道又会开放什么新接口。

其次是调试困难,在官方开发工具出来之前,只有一个简单的网页版接口调试工具,用来检测下通信数据传输和返回值是否正常。对于大部分开发者都是本机开发,微信接口映射到本机就是个麻烦的事情,固定IP的话可以在路由器里面做下端口映射,非固定IP可以用一些动态域名比如花生壳之类的,或者使用ngrok工具,其实也是一种动态域名方法,即便是这样问题也很多,一方面大部分使用都是免费动态域名,每次域名都会变,都需要在公共平台里面修改接口地址,另一方面要使用jssdk接口的话域名需要备案,备案,备案。。。。。说完了后端部分就轮到前端了,由于接口必须需要微信浏览器支持,所以在普通浏览器里面用正常的方法都会显示微信的提示。在官方开发工具出来之前,还没有什么很好的解决办法,基本都是去掉微信jssdk部分调页面的效果,线上调试用微信PC版,可以看到源代码,查看下一些动态的内容是否正常输出,再剩下的问题就要靠经验了。还好微信也意识到自己这个生态环境不是很友善,出了开发工具,感觉就是个深度定制的chromium,使用起来还是比较方便的,至少能解决之前的页面和JS调试的痛处。

再次,微信开发应用使用起来也不是很友好,最严重的就是通过公共平台进入开发的应用,比如现在很流行的微商城,我在浏览商品的时候突然来了一个微信消息或者其他的信息,打开看了后就没回到之前浏览的页面了,尤其是在进行一些流程性的步骤,比如说购买,只能重新来过。通俗点说就是抗干扰能力非常差。这就需要开发者在开发应用的时候简单明了,层级流程尽量的短小,无需过多思考,一两步就能完成。也就限制了大型复杂的系统的接入性,不是不能接入,而是使用体验会很差,一有干扰直接重来。不清楚应用号会不会在这方便有所改变。

最后对于微信这个业态,我一直认为正确的微信模式就是服务号的模式,个人非常反感订阅号,虽然有很少部分订阅号质量非常高,也仅仅泥塘里的一两颗荷花,剩下的都是信息垃圾,各种鸡汤、伪科学、广告推广等等。我们现在处于信息泛滥的时代,人们已经开始由原来的被动接受信息转变成主动获取想要的信息,订阅号那种天天推送的模式反而令人反感,至少对我来说,再加上微信也是注意到了这些,将订阅号全部合并折叠起来,消息的获取宽度更窄,其实也是鼓励运营者向服务号转变。通过之前微信要推出应用号这个消息也能看出来,微信在不断的弱化自身的媒体属性,更多的作为一种平台,或者说是入口。公共平台利用微信上的人脉,加上微信很方便的扫码、摇一摇周边等参与模式,将用户导入进自己的平台系统中去,这种精准化营销是其他平台不具有的。支付宝虽然也在做类似的事情,可是起步晚了很多,虽然用户基数也不小,可是要用户改变已经养成的使用习惯,也是很难的。如果解决好微信开发的应用使用上的问题的话,也可以是企业一个很好的营销入口。

微信开发闲扯

@玛酷猫6年前

08/16
18:21
项目管理

版本控制与版本号

头几年的工作也都没考虑过版本控制,一方面是和工作条件有关,那时候公司小,架构简单,开发也就1、2个人,交叉部分很少,自己做自己的就好了,另一方面自身也并没有版本控制的概念,直到09年。

那时候技术人员也将近10人,交叉工作比较多,尤其是程序人员和设计人员经常发生文件覆盖事件(那时候项目还没三层化,都混在一起),当时就想寻找一种解决方案才慢慢知道版本控制,于是便向当时领导提出应用版本控制,减少避免此类现象再次发生。虽然当时领导认同这一看法,但却没有实施,一方面可能是版本控制器没人会配置,当时并没有多余的设备用来架设,另一方面现有人员习惯了目前的开发方式,认为版本控制影响效率,版本控制推行难度比较大,最后也就不了了之,多注意多检查罢了。

PS:那是常常想当时可能不是部门负责人,没有资源推动实施,等自己做了负责人之后才发现,并不是成为领导就一定能推得动,新的思想、方法,部门绝大部分人尤其是老员工不支持甚至抵制,实施难度还是很大的。

时间到了今年年初,部门老人走了不少,新人又都比较支持的条件下,才上了版本控制器,也仅仅作为开发使用,一旦开发完毕上线后进入维护阶段,版本控制器也就不再使用,直接在运行的项目上直接修改。安全隐患也是蛮大的。不过自己离开原来单位有段时间了,现在使用状况也不得知。

说道版本控制自然也要牵扯到版本号。对于版本号都不陌生,IE6\7\8\9,office2000\2003\2007等等。这些只是简单的命名方式,常规命名方式主要有三种,以下引用百度百科:

1、 GNU 风格的版本号命名格式
主版本号 . 子版本号 [. 修正版本号 [. 编译版本号 ]]
英文对照 : Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]]
示例 : 1.2.1,2.0,5.0.0 build-13124
2、 Windows 风格的版本号命名格式
主版本号 . 子版本号 [ 修正版本号 [. 编译版本号 ]]
英文对照 : Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Number]]
示例: 1.21,2.0
3、.Net Framework 风格的版本号命名格式
主版本号.子版本号[.编译版本号[.修正版本号]]
英文对照: Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Number]]

其实大同小异的了,借用原来的网站项目,可以把每次改版作为主版本号,板块的修改和功能的添加作为子版本号,每次的小BUG修改作为修正版本号,最后一项可以用版本控制软件累加的那个计数。版本号最关键的并不是怎么命名上面,而是每次版本变动的版本文档,里面会清楚的记录每个版本添加了什么功能,取消那些设置,修正了那些bug等等。当你向别人介绍产品的时候可以很清楚的说明这个项目经历多少次更新,原来有些什么功能,现在扩展了哪些功能。别人也能了解到你这个项目的发展情况。而这个正是我们现在缺乏的地方,随便抓个人出来连最基本的所有功能都说不全,就甭提其他的了。

其实版本控制并不是仅仅是上一个软件,大家都在用这么简单的事情,它也是一种迭代开发流程和思想,同时也是文档建设的基础。在每次同步版本控制软件的时候,都会有提示添加说明,其实在这里就应该把这次源文件做的哪些变动填写好,便于自己以后查找,同时也便于团队其他成员熟悉,最后也汇成版本文档。

下一篇集中写下开发流程和文档建设。

版本控制与版本号