软件沉思录 2022-05-01 / 579 次 / 快抢沙发 / 14

记录这么多年来，针对软件的一些个人见解。

备注：本来想将此文的标题命名成技术沉思录或者开发沉思录，但是觉得名字都不是很好的。取名软件沉思录，软件这个词可以更好的概括本文内容和限定本文的边界：既有针对软件的一些理解，也有针对开发细节的看法，还有一些关于技术管理的个人实践内容，以及核对软件开发人员的思考。

商业化的软件本身是需要创造价值的，价值不仅仅是以金钱来衡量，有的时候软件本身并不赚钱，有可能还亏钱，但是基于软件提供的服务，能够带来其他诸如业务增值、品牌曝光等价值，一样是软件创造的价值。

参考案例：

案例 A：

我们不管是接私活，赚个一次性的开发费和后续的维护费，还是说做了一个智能硬件产品的 App 端软件，用来辅助智能硬件，又或者说我们开发付费软件来提供相关的服务，甚至是反诈骗 App 帮助创造更大的社会价值。都是软件所创造的价值，也都是这些软件存在的意义。另外你出于出于个人兴趣爱好、锻炼技术能力开源一款软件，这种软件同样会给你带来各种潜在的价值。

案例 B：

我们团队曾经想要做一款特定垂直领域与产品应用场景下的定制 Android AI 生态系统，整合基础的 Android 系统、AI 语音以及第三方内容生态。前期投入了大量的时间做产品与技术架构设计，但是当我们真正想要去做商业化尝试的时候，发现这种产品很难落地，并且长远上，很难实现高附加值，而且客户定制化需求的程度太高，投入的人力与财力相对较高，短期内不具备系统商业化能力，最多只能赚点技术开发费，于是我们果断放弃了这款软件产品。

思考总结：

创造一定的价值，是软件存在的意义。相反，如果你的软件 UI 做的再好，使用的技术如何高大上，产品功能如何繁多，但是最终不创造任何价值，或者长期来看没有较好的价值，那么是时候放弃这样的软件了。

“你软件做得再烂，都没有问题，但是你软件的可快速迭代升级性，一定不能有问题”，为什么说软件的可迭代升级性，是软件最重要的基础呢？因为保持软件的可迭代升级性，相当于保留了快速的补救、挽回、迭代、优化的希望，这个才是根本深层次的原因。有问题？升级就可以解决问题。那么软件的可快速迭代升级的技术设计，尤为重要！是你的软件产品推出之前，最应该花时间和精力的地方。

参考案例：

案例 A：客户端

当年移动互联网蓬勃发展的时候，一个实实在在的案例：一款尤为重要的 App 产品，Android 端出现严重的技术 Bug：一打开应用就闪退，大量的 Android 用户受到影响，根本无法使用产品，而且这个产品正在处于用户增长的关键时期。原本以为可以通过应用自带升级机制进行升级（那个时候 Android 生态里还没有第三方应用市场助手或者手机自带的应用市场辅助升级），结果发现应用升级机制并没有实际作用，而且即使有，也没有针对一打开应用就闪退情况的技术优化。这对于刚需要用户增长，急需用户口碑传播的产品，是一个非常严重的影响。

案例 B：服务端

当年也遇到过一些关于服务端的有点哭笑不得的软件迭代升级的问题，当年客户的一款应用，长时间未更新，当想要去更新的时候，发现原来客户端的代码逻辑中请求服务端更新的 API 接口 URL，居然直接用服务器 IP 来指定的，并没有用泛用的域名。而且当时那台特定公网 IP 的服务器早就退还没有用了！还有比这更奇葩的问题，API 接口中指定的域名，由于忘记续费，被别人抢注了。似乎这样的问题，对于软件开发从业者来说，是低级的失误，但是确实是实实在在发生过的问题。

案例 C：智能设备端

曾经参与一款 Android 智能带屏设备的项目管理，售后反馈设备软件存在问题，开发软件版本修复完成之后，尽然发现由于技术流程和细节的问题，无法远程直接进行应用升级，而且我发现早期居然连系统级别的 FOTA 机制都没有，发现远程自动进行软件版本升级无望之后，只能挨个的和客户联系，告知客户，找一个鼠标（定制系统定制应用页面无法直接载入到原生系统页面），通过鼠标进入到原生系统页面，找到浏览器，在浏览器里面输入：http://www.***.co/***.apk 然后点击下载，然后去文件管理器目录中，点击 ***.apk 进行安装升级。你看看这种早期不注重软件迭代升级的问题，后期是有多麻烦！！

思考总结：
可快速迭代升级性是我们软件开发最重要的技术逻辑，客户端与服务器端本身的技术逻辑设计，还有服务器端与客户端之间的通信技术逻辑设计，这三者都是缺一不可的。而且我们容易忽略服务器端的服务本身也是一种形式的软件，它自身的快速迭代升级，也需要考虑在内。

软件开发岗位，或许是互联网行业中最需要关注细节，并且需要不断的追求完美的工种了。但是如果你基于某项产品设计来进行软件开发，你刚开始过于关注细节、追求完美，你就会发现，前后左右都是坑，寸步难行。前期你会浪费掉大量的时间，而迟迟不能开发完成 MMF（Minimum Marketable Feature 最小可售功能） 并交付 MVP（Minimum Viable Product 最小可用产品）。

参考案例：

我们在开发一款 iOS 应用的时候，刚开始想要选择合适的技术架构，于是你反复考量 MVC/MVP/MVVM/Viper 等架构思想，当应用存在潜在的皮肤切换问题之时，你想要服务端配合自己构建一个皮肤动态管理系统，更快速方便的进行服务器端皮肤动态配置。你的应用又涉及一些潜在的可能会影响 App Store 上架的功能，你觉得你需要详细阅读应用商店的上架条款及注意事项。你发现服务器端给出的接口的扩展性、迭代性、以及版本控制不够完善，提出要服务器端配合整改。结果你的第一个版本上线的开发时间预估六个月……

其实以上问题，并不是你前期所需要考虑的，而是后期不断的迭代升级需要优化的内容，前期最重要的就是开发完成 MMF（Minimum Marketable Feature 最小可售功能） 并交付 MVP（Minimum Viable Product 最小可用产品）。然后通过市场用户不断的反馈，快速迭代软件本身。试想一下：等你万事俱备再去推出第一个线上版本的时候，别人的产品已经迭代了好几个大版本，并且已经找到了用户的需求和市场的痛点和商业化的关键，更可怕的是，假若你的产品模式，是国家法律法规已经不允许的了，你前期做了那么多工作，一切都前功尽弃。

思考总结：

有时候在软件开发中，不要过于关注细节，陷入对完美的追求。等待问题的发生，然后去解决问题，要比事先规避各种问题要好。

我们上面不是说，只需要保证软件的可快速迭代升级性这一点，而且只需要保证后面不断的迭代升级就可以了，为何说良好的软件架构设计很重要呢？况且很多公司没有所谓的软件架构师这一岗位，而且软件架构师的能力有大有小，也无法设计出完美的软件架构。其实这个并不矛盾，我们需要在软件开发开始之前，尽可能的、在我们力所能及的范围内保证有一定的软件架构设计就可以了，量力而行。而且在能力有限的情况下，可以采用一种技术上支持“架构可迭代性”，是一种很不错的做法。

参考案例 A：

之前我们从零开始开发智能硬件产品，是一款蓝牙智能音乐风扇灯：能够通过移动端 App 来控制灯设备的开关、颜色、色温，并且还能控制风扇和播放音乐。从技术端上来看，我们有三端：设备端、App 端、服务端。最需要技术架构的地方就是蓝牙通信协议这块，由于我们前期针对蓝牙通信以及数据传输本身都是从零开始摸着石头过河，很难有一个较好的技术架构设计，尤其是在设计蓝牙通信协议的时候，总觉得还欠缺很多：命令的动态可变、每条命令信息的独立性、设备标记、数据包分包与合包、数据传输稳定性、数据包加密与解密等等，需要考虑的技术问题太多了，而且总觉得还不够，不是觉得不够完美，而是怕会出问题。

后来我们通过保证蓝牙设备本身的 FOTA 机制，保证 App 端本身的升级机制，还有就是服务器端本身升级性，以及服务端与 App 端， App 端与设备端的之间通信的可用性的基本保证，然后通过服务器端存储 App 端蓝牙通信库 SDK 的版本与蓝牙设备间固件版本对应关系，以及做好 App 端蓝牙通信库对蓝牙设备固件的全版本兼容。同时最重要的是通过将蓝牙设备的蓝牙广播信息标记当前设备使用的蓝牙通信协议版本，一下子让我们的所谓的技术架构存在可方便迭代的可行性，即使现在蓝牙通信协议没有设计的足够好，但是我通过这个可迭代的关键技术架构来一定程度保证了技术架构的“良好”。

参考案例 B：

当年我们给传统厂商做智能灯 App 的时候，由于业务推进过快，接入太多厂商，还有不同定制需求，最麻烦的就是项目开发时间太短。由于前期没有做好主项目及衍生定制项目功能模块化，技术模块化。针对应用本身的升级机制以及版本管理，甚至是基本的应用软件版本规范都没有，更别提对于衍生项目最重要的就是多渠道打包、单个代码仓库多逻辑集成。

这就导致我们超过百款的应用，虽然上百万用户，上万月活。但是最终这些应用都处于无法迭代升级，无法收敛版本，无法有效的运营产生价值。而且代码的可维护性极差，经常是这个应用的通用功能修复了一个 Bug 无法同步到其他应用，一些通用的重要的 SDK，比如蓝牙这块，都无法做到 100% 同步更新。我们很多工程师一看到这样的代码，离职的心都有了。

思考总结：

良好的软件架构设计很重要，软件开发前期要一定程度重视起来，如果公司有条件，配一个专职的软件架构师，是蛮重要的。如果没有，也没有关系，在软件架构设计上，考虑软件架构本身具备迭代升级性，是一种比较好的保障性策略。

我是一个 Java 程序员，我是一个 Android 程序员，我是一个 iOS 程序员，没错，你是用 Java 来开发程序的，你是面向 Android 或 iOS 开发程序的，这些都没有错。但是很多时候，我们面临的问题，可能一定程度超出你的技术范围，但是大方向上还是属于软件工程，比如说 Leader 安排一个工作，这个工作中可能涉及到一项技术，比如 Shell 编程，或者你一个 Android 开发工程师要去解决 iOS 开发工程师的问题，不要一遇到类似的问题，就开始自我设限，认为我只是一个某某工程师，我只会某某语言。

其实很多的问题，只需要在你能力范围内，往前走一步两步，你就可以解决相关的问题，而这一两步，恰巧是你能力提升的关键，我曾经只是一位 Android 开发工程师，只会一点点 Java，也不妨碍我用 Bash 命令编程来解决实际的问题，也不妨碍我开发 iOS SDK 以及解决 CentOS 服务器的一些特定的问题，这里我在之前的一篇文章中有详细提到过，诚然我不否认，专业的人，做专业的事情，但是当一个问题摆在你面前，需要你参与解决的时候，一定不要给自己设限。

我工作中见过太多能力很强的人，他们大多都具备极强的学习能力和强大的问题解决能力。一个人可以很快掌握一个原本不属于他自己知识领域的内容，让他看起来像是这个领域的专家，而且一个人强大的问题解决能力，会掌握一套解决问题的方法论和特定招数，并且有强大的 PUSH 能力。

参考案例：

最近之前公司市面上有上万台 IoT 设备出现问题，之前公司的人员不太清楚是什么原因导致的，于是我参与帮忙确认问题。问题表象：Android 系统的 IoT 设备出现页面登录和加载不了，有一些参考因素：最近腾讯云配合工信部进行备案信息核实，提醒备案信息存在异常。

首先第一步，我们从源头确认，紧急联系客户，帮忙获取具体的 Android 系统日志，确认到关键 API 接口访问数据错误，看到有关键词 https 和 SSL，然后初步判定可能是 SSL 证书过期了，之前是用的腾讯云免费的一年证书，上去查看，果然已经过期一个多月了，但是想了下，为何过期这么久了，今天才出现这个问题呢？我们先紧急把 SSL 证书更新下，发现市面上的设备还是存在问题，后来经过确认，发现我们的服务器的服务被阻断了，刚开始我们根本就没有意识到这个问题，经过和腾讯云反复确认，才发现这个问题！

经过与客服详细沟通，发现出现问题的原因：由于腾讯云配合工信部对企业网站备案信息进行阶段性审核，查询到技术负责人离职，于是和企业负责人联系，确认现有备案信息底下的三个域名的可用性，然后由于企业负责人不是很清楚，自认为另外另个域名网站不再使用，腾讯云就配合直接取消了网站的备案号，导致直接触发了腾讯云服务器检测到网站取消备案号，就阻断服务了！

目前当务之急，就是要赶快恢复线上服务，我们想着取消备案号出现的问题，那就赶紧再次备案，要知道备案是没有那么快的，因为各种备案信息的问题，经过评估，至少需要 7-10 天才能备案好，这个显然不行的，客户已经炸了。当时就灵机一动，如果把域名和服务器迁移到国外，是不是就可以避开这个网站备案的问题。于是赶紧和腾讯云客服确认，对方答复是肯定的，我们先想到的是购买国外的服务器，把整个服务器内容直接迁移过去，但是发现原来服务器上的服务一大堆，慢慢配置很困难，有些东西大家还不知道，这样风险比较大。

突然想到了腾讯云是有香港和国外的服务器的，而且腾讯云有镜像可以直接迁移到新的服务器上，于是赶紧联系到腾讯云客服，得到确认的答复：域名在腾讯云，服务器选择香港或者国外服务器，这样是不需要备案就可以直接使用的，于是乎当天就通过这种操作，很快的解决了问题！

由于当前时间有限，我无法针对所有的 Tips 做一个详细深入的探讨。有的只有简单的一句总结而已，并没有细节的阐述。以后有时间再逐步展开细化，深度思考与大家一起总结探讨。

俗话说得好，磨刀不误砍柴工。有好的工具，是软件技术开发高效的开始。我所用的几乎所有通用的硬件与软件的工具，在我的另一篇《个人生活、学习和工作的生产及管理工具、方式及架构思考》中提到过了，这里就不再赘述，感兴趣的可以阅读这篇博文。

以下软件各端的 Tips，仅仅是个人这么多年的技术开发过程中接触到的，认为有一定重要性的内容，并不适合所有的软件开发人员，但是可以作为移动互联网与物联网软件开发从业者的一个参考。

软件各端：包括但不限于服务端、设备端、前端、移动端

说明：其实只要相对于服务器端来说，都可以算作某种程度的前端，所谓大前端的概念，其实也包括移动端。我这里提到的设备端属于 IoT 嵌入式那块（当然 Android 定制设备也算），移动端更多的是指非定制的 Android 设备（有时候也包含）以及 iOS/iPadOS 等设备。我这里提到的前端更多是 Web 及相关端。

*技术开发规范
*RESTful API
*软件版本：semver.org
*数据抓包
*HTTP: GET/POST/PUT/DELETE
*库/安装包等大小优化
*性能优化
*GitHub + StackOverflow
*源代码的版本管理：Git + SourceTree + GitLab
*源代码单仓库多分支、多渠道、动态打包、Git Submodule
*GitBook
*CI/CD：Jenkins
*Artifactory
*Paw/Postman/Apifox/Swagger
*Code Review
*Buglist
*软件版本升级管理机制（常规更新、热更新、热修复、官方/第三方应用市场等）与软件节点回滚机制
*利用开源代码进行商业化软件开发，需要注意开源代码的许可证授权范围问题
*运营数据统计 SDK/工具
*MQTT/WebService/WebSocket
*XML/JSON
*国际化、本地化
*数据库：MySQL/SQLite
*软件支付集成
*Nexus Repository
*Phabricator
*库、SDK、插件化、组件化
*链式操作
*Maven 私服
*消息推送
*Git/Repo/Gerrit
*买断制、订阅制
*单点登录/异地登录/单设备登录/多设备登录
*VPN/VPS/VPC
*不同网络运营商之间的数据缓存问题

服务端：各种 Server
说明：服务端与后端开发相关 Tips。

*域名、服务器、SSL 证书等
*SIT/UAT
*服务端服务器与数据的安全性（防攻击与数据容灾等）
*API 接口设计：安全性、扩展性、迭代性、[Token/Session/Cookie]
*OAuth 技术
*内网部署、外网映射、服务端可用性、负载均衡
*云存储（阿里 OSS、腾讯 COS）、云服务器（CentOS）、CDN
*DNS 解析：1.1.1.1、8.8.8.8、8.8.4.4、114.114.114.114

移动端：Android/iOS 等
说明：Android/iOS 移动端共有 Tips。

*定位技术
*音频焦点
*Android/iOS 无线调试
*软件著作权（Android）、隐私政策声明（iOS）
*Android （Google Play）、iOS （App Store）上架
*日志捕获上传分析
*i18n（Internationalization）l10n（Localization） 及相关工具
*UI 适配：不同尺寸、不同分辨率、不同比例（dp/dip/px/sp）
* .9 图的制作与理解
*MVC/MVP/MVVM/Viper
*云测试（Testin）
*WebView/JS 与 Android/iOS 交互
*C/C++ 的跨平台运用
*消息推送
*录音
*私有 API
*应用加密/加固与远程开关
*模拟器测试调试、单步调试
*Android/iOS 包 AndroidManifest.xml/info.Plist 文件解析
*Bugly
*包管理：Android （Maven Central/JCenter/JitPack） iOS (CocoaPods/Cathage/Swift Package Manager)
*C/C++ NDK
*WebView JavaScript 交互
*Java/Kotlin、Objective-C/Swift 混合交互
*闹钟机制
*开发者大会

移动端：Android
说明：Android 移动端 Tips。

*Android 开发证书过期或者忘记密码
*Android 签名 v1/v2 问题，Debug 证书、发布证书
*Android 系统 SSL 证书
*ClassyShark
*ADB 命令
*Gradle 命令
*AIDL
*Messenger
*jar 包/aar 包
*Android JetPack/AndroidX/LiveData
*Java/Kotlin
*debugable 配置
*守护 APP

移动端：iOS
说明：iOS 移动端 Tips。

*iOS MFi 机制
*iOS Development Running 包/Development Distribution 包/Ad Hoc 包/Enterprise 包/TestFlight 包/App Store 包
*Spark Inspector
*dSYM

前端：Web 及相关
说明：前端相关 Tips。

*Android/iOS 设备扫描二维码跳转到不同的应用商店或者下载应用
*小程序、PWA

设备端：嵌入式及相关
说明：IoT 设备相关 Tips。

*智能设备的配网方式：蓝牙配网、Wi-Fi 配网、声波配网等
*智能设备 FOTA：通过第三方设备、通过自升级
*通信协议设计：蓝牙/Wi-Fi/Server 等
*ANC/ENC

其他
说明：其他一些和技术有问题的 Tips。

*HUAWEI Wireless Kit
*NAS

*A2DP/BLE/SPP/HID/HFP
*A2DP/HFP 音量同步
*蓝牙通信命令、通信加密
*AirKiss
*iBeacon
*蓝牙 UART
*蓝牙 UUID
*蓝牙 A2DP 与 BLE 回连机制
*BLE Audio
*可以通过 A2DP/BLE 名字备注音频/数据来提升用户连接交互的友好性
*IoT 类设备的蓝牙/Wi-Fi 等通信命令框架设计重要性：安全性、方向性、设备特性等。

*AI：Robotics/Planning/Speech/Vision/Expert System/Machine Learning
*VUI
*语料、技能、词槽
*技能、意图、语料、实体、实体内容
*技能进入退出词、自定义技能
*远场、近场、麦克风阵列、降噪
*PCM/OPUS/WAV/MP3
*ASR/NLP(NLU)/TTS
*VAD、语音的开始与结束
*语音唤醒、误唤醒、打断唤醒、有无唤醒词、离线唤醒词、声纹、唤醒词定制、离线语音合成与识别
*语音对话、连续对话、多轮对话
*智能对话架构师、智能对话训练师
*召回率
*科大讯飞、阿里、百度、腾讯等 AI 语音开放平台
*AI 语音实时转文字
*SDK 接入/API 接入
*语音 SDK 封装

*系统设置定制开发：蓝牙、Wi-Fi、关机、音量、屏幕
*系统权限（系统广播）
*FOTA
*产测工具
*AI 语音集成
*定制 Launcher/隔离 Launcher
*NITZ 和 SNTP 时间同步
*系统通话：拨打、接听、挂断，电话状态共存：网络电话、特殊电话、系统 4G 电话
*唤醒锁，电池优化清单
*ADB 命令在定制系统开发中的应用
*与系统设置相关的内容，尽量避免上层应用来定制开发，通过框架层来修改定制 UI 是最合适的，特别是：Wi-Fi 连接、闹钟设置。
*多屏幕显示技术
*设备烧录信息
*如果天线没有被校准的话，会影响通话、蓝牙、Wi-Fi 等性能。
*设定当前应用为 Launcher 应用，电话主应用。
*android:largeHeap=”true”
*android:persistent=”true”
*电话：主叫、被叫、呼叫等待、呼叫转移、接通计时、免提、多方通话。

问题篇：
*底层定制 AI 语音录制，导致内存泄漏，通过 adb shell dumpsys meminfo 命令查看情况。
*Android RTC 闹钟需要底层芯片支持，否则断电关机之后，不生效。
*Android 系统签名整合，便于调试问题。
*Android 设备剩余空间大小通知问题。

*测试过程中的录制：屏幕本身的录制和屏幕外的录制
*人工手动测试能力
*自动化测试方法和工具
*对于 Bug 测试的精准性和细节的确是作为一个测试工程师应该做的，但是另外需要考虑测试 Bug 的级别，和解决这个 Bug 所需要付出的代价，有没有实际的意义，比如一个很难复现的 Bug。

*对 Git 理解不够深刻，提交代码、切换分支导致新代码都丢弃，以及没有及时 PUSH 到远程而丢弃代码。
*线上生产环境，直接用 IP 来设计接口
*iOS 应用，采用企业版本证书来发布

*用户不知如何操作、操作无响应、卡死、闪退都是用户体验的杀手
*控制好软件升级的频次和时机，尤其是智能设备的系统升级，特别是诸如智能汽车这种，最好是无感升级：静默、热更新等。

*少用鼠标，多用键盘，快捷键。
*照着别人的代码敲一遍的过程中，不断思考，也是一种深入的方式。
*无用代码及时删除，否则有的时候会成为一个严重干扰或者定时炸弹。
*单步 Debug，能够帮助你解决很多问题。
*读懂别人的代码是一种很重要的能力。
*及时提交代码到远程备份。
*理解业务逻辑是开发过程中非常重要的一步。
*代码规范使用的重要性，例如：Android 开发中减少 print 打印，采用 Log 打印。

*代码管理：代码泄露问题等。
*软件 Leader 不一定需要多强的技术，但是解决问题的能力一定要强！

上一篇： « 工作沉思录 下一篇： 项目沉思录 »