关于工作和软件开发的一些思考

公司工作每周都有周报要求发送，初始的目的是为了大家能够总结上周，规划下载，复盘思考一周的工作。但是由于各方面的原因大家的周报都有点流于形式。分析觉得表格的格式可能是一个原因，故采用 markdown的方式书写，写好后使用 Chrome 的 Markdown here 插件一键转换成格式不错的周报邮件。希望借此可以激发大家发周报的激情。

Markdown here 网站

关于 android 权限开发

android 的权限开发本来就从 23 （android 6.0.0 代号M ）作为分水岭，分为RunTime 和 target 两个不同的维度有运行时授权和安装时授权，已经让开发者很混乱，加上国内的Oppo vivo 魅族， 小米， 华为，各种神奇奇葩机器的权限判断和表现不一致。加上，定位和蓝牙权限有快速开关的顾虑，导致权限的问题确实一个一个比较复杂的问题。 网络上大部分的库均为官方sdk 的便利性封装，疑难杂症的应对不是特别好，ele 团队中有一个开发人员维护的 permission4M 是一个比较不错的库，经过我的测试可以很好的处理oppo上的问题。

关于软件的技术架构选型

看了公司一个项目的 android 代码，架构的很棒，也有了很多技术库，各种流行的android 技术都在这个 app 中有所体现。从技术角度来讲确实是不错的技术仓库。不过思考商业和技术的平衡来看，需要适度的找到平衡点。不能太技术，也不能太耦合。

关于共同维护代码库

代码仓库需要尽量有自己的独立性，抽取出来的代码库，都是需要维护的。一个仓库就需要一份精力去维护。

需要维护的事宜有：

• 升级优化仓库中的功能
• 新增功能更
• 废弃一些不太常用的(或者因为版本更新，有些功能已经失效)功能
• Readme 的完善
• 示例代码的编写和完善
• 测试用例的编写和完善
• Issues 的处理和解答
• 处理 merge request

以上是我能够想到的抽取一个仓库要做的事情，抽取越多的仓库，就要同时做很多这样的事情，所以抽库要谨慎，功能点考量清楚后再抽库。

关于周报

原本的表格方式，大家在表格内写文字，换行都觉得不好意思，一行写不了多少文字，写多了都感觉被表格压抑了。建议常识去掉表格，随心而谈，这样我们可以有更过自由的交流。同时也很期待看到大家更多的思考。

Markdown here 使用后的样式

现在表格样式的周报