[年终总结]2013年年终总结.pptVIP

2013年终总结 钟绍勇 说点啥？ 关于新版的PC客户端（代号:wj2） 项目情况 技术选择与环境搭建 遇到的问题与努力避免的问题 如何尽可能提高生产力？ 桌面客户端开发技术探讨 HTML5在客户端的运用 一些自己的研究 案例介绍 嗯。。先说一下客户端 项目情况 为什么要做新版？ 刚接手客户端开发，却无任何文档注释留下 UI实现困难，无法实现很多设计效果 代码结构混乱，过多无谓封装，滥用多线程导致难以调试 修改起来都“伤筋动骨”，修了一个Bug又出另外的Bug 基本处于一种“小Bug 四五天，大Bug一两周”的难以维护状态 项目情况 当前的情况： 基本架构已经成型（通信，基础类库等） 基本的功能（群聊，动态，客户端内照片上传）也完成了 高级功能（如照片同步，硬件检测等）实现部分算法 上述算法还有问题，重写了好几次，所以一直未能应用 人手不够，服务端和客户端都自己写的同步堵塞串行开发状态 处于网站和移动端之间的一种奇怪的混乱状态…… 技术选择与环境搭建 与C#、Winform说再见 带着个.NET Framework，不利于发布 Winform绘图太差劲，透明半透明阴影甚至圆角实现起来太复杂 只能用C# 2.0，很多高级语言特性都用不了 成也GC败也GC，无法确保对内存的准确控制 底层控制力不足，调用系统组件有太多未知影响 强强联手：Python 与 Qt 尽可能从技术上选择效率最高的方案 人生苦短，我用Python，大家懂的。 选择LGPL开源协议的PySide（Qt的官方Python 包装） 打包的话用Py2EXE就能够打包成普通应用程序的样子了 技术选择与环境搭建 拖控件才是硬道理 Qt界面开发的三种主要方式：纯代码，拖控件，QML 为啥不拖控件？有更好性能？程序更加可控？自己更有节操？ 在否定之前，必须得证据证明拖控件有错。 事实证明QMake生成出来的界面构造代码几乎与人手写的相差无异。 技术选择与环境搭建 遗憾：Python的局限性 每个语言都有其局限性，Python虽好，但还是缺乏底层的控制力 作为非Windows主要开发语言，Python调用系统组件麻烦 内存极值可优化，但均值不能 面对消息循环的处理，PySide无能为力 作为有节操的程序员，不得不放弃GPL协议的PyQt 最后还是不得不转投C++ 遇到的问题 Qt的坑爹设计 图片类型识别纯属低能逻辑 webkit交互浮点数处理的问题 加密解密问题 C++没有一个统一的加密库 cpyto++ 在Qt中使用会无条件崩溃 自写加密算法与服务端（C#）加密不相容问题 openssl与C#加密不相容的问题（pkcs7 padding） 字符串处理的问题 C++没有严格意义上的字符串，只是个以\0结尾的二进制流罢了 回调地狱 对于没有lambda或者匿名函数的C++98来说，异步回调是一个痛苦 为了异步，必须得M个Signal，N个Slot，代码支离破碎 照片上传到通知界面的一个操作，经历了8个回调。 竭力去避免的问题 避免设计模式和面向对象的滥用 善于运用C++的RAII特性，避免在堆中分配非QObject对象 避免没必要的堵塞操作和多线程操作 自适应布局应该多使用Layout而不是手动计算 减少对于第三方库的依赖 避免没有意义的重复劳动 论程序员的自我修养之小工具篇 一人编码真孤独，效率低下太痛苦。 为了适当“偷懒”减轻无谓的工作，于是我做了两个小工具 autotasker webproxy for Qt 小工具之autotasker 一个python写的，十分简单的定时任务执行脚本 本体其实是几个批处理和python脚本： updateui.py 扫描目录内的ui自动生成界面代码 vsbuild.bat 自动构建VS的工程（调试用） update_deps.bat 自动更新项目的依赖库 genproxy.bat 自动生成webapi的本地调用代码 releasebin.bat 自动复制exe文件以及所需dll和资源文件到bin 脚本运行后就会定时执行任务，这样我就安心编码，构建操作我就不担心了，后台会自动运行 小工具之webproxy 在webapi的接口方法(C#)上加上“[Webproxy]”的特性，就能被parser识别，可以生成方法的元信息。 webproxy特性支持： UseValidate ForMobile/Desktop/Web IsPost HasFile CallInterval Parser生成的元信息以Json格式输出 webproxy客户端(python)会根据元信息以及选择的生成模板生成代码 桌面客户端开发技术探讨 HTML5 在客户端的运用 在新版的客户端开发中，尝试了使用HTML5去实现一些