编写可维护的代码
最近在日常的开发过程中，发现了很多问题。思考了很多关于编写可维护性代码东西，以及一些关于程序的看法。
最早发现这个问题，起源于我想做一个需求，这个需求呢，很简单，就是点击一个按钮，弹出一个分享的界面，点击可以分享到 QQ，微信，微博等地方。作为一个已经持续了 2 年的项目，我觉得应该有现成的封装好的代码，只需要我调用一下，传一些分享的相关数据就可以了。可是当我找了一圈后发现，所有的关于分享的代码，全部都是复制粘贴的。我看了下，发现里边竟然有七八处，除了个别地方不一样，其他 95% 的代码都是一样的。当时感觉一脸懵逼，外加黑人问号。
依稀记得，当年实习刚入职 京东。接到的第一个需求就是优化一下分享，当时我就知道要把这个东西封装起来，让别人尽可能的调用起来方便。要考虑到分享渠道可配置，分享标题，内容，链接，图片等等，都要可传参，可配置。而这个工程对接的还是 友盟分享，一个功能上是相当齐全的库，结果还做成这个样子，每次使用分享，要复制粘贴一份。我头都大了。
第二个事情呢，就在前两天，我要做另外一个需求，还是一个点击事件，根据不同的参数，来决定跳转到那个页面，我当时问了一下，貌似有对应的功能，我当时还是很开心的，意味着我可以早早完成。结果，当我去调用的时候，发现跳不过去。而当我费尽心机搞定跳转的时候，我看了下里边的代码，发现了这样的代码。
这代码看的我真是虎躯一震
遍地的 if else，遍地的硬编码，遍地的随意拼接字符串，感觉要裂开了。
硬着头皮看完之后，我手贱，搜了一下，发现工程内，有六七处一样的代码，我的妈呀，这真的是酸爽啊。
写到这里，关于吐槽就完了。后边大致说一下这几天想的一些东西吧。
👉编写可维护性代码
最近看 代码简介之道 感觉挺不错的，里边的一些 tips 真的有用，可以让大家写出清晰，简介，易于维护的代码
我们在日常开发的过程中，大部分的程序员都不会编写很高深莫测的代码，都是常规的业务性逻辑。清晰易懂的业务代码，可以为后期的维护带来极大的便利性。
👉模块化
面向对象的三大要素，继承，封装，多态 这几点，看似简单，其实要用好挺难得，还有各种设计模式，尽量要做到高内聚，低耦合。
能封装的，就封装，做成独立的小模块，小而精，这样移植起来也更加方便，出错的可能性也就越小。
👉为了新技术
我一个前同事 DKH 入职了 TX 某部门，工程里边什么都有，一个 iOS 的工程，有 Objective-C，RAC，Swift, RXSwift，等等，各种技术，谁想用什么技术，觉得有现成的，直接搬过来，用的时候倒是挺爽，后来维护，修改，就变成了灾难。
我们前一段也尝试了 swift + oc 混编，想试一下新技术，用了一段时间后，就停下来主要原因有以下几点。
- 时间紧，任务重，陡然间上手 swift，效率较低
- 需要做大量的桥接工作
- 混编太慢
其实关于 1，2，经过长时间的迭代，是可以克服的，3 可以通过一些方式进行优化。但现在这个工程，已经是一艘将要倾覆的船了，意义已经不大。
去网上逛一圈，你会发现很有意思的一些事情，比如 文言文写程序，还有个一用 Dart 来写 Objective-C 代码，还有一个 用 Golang 写 iOS，还有这几年比较火的，就是 React-Native, Flutter 来开发 iOS Android 应用，以及各种热修复技术等等。诚然，这些技术是好的，有的可以极大的提升开发效率，节省时间。但是很显然，我们想的总是太美好，Airbnb 放弃了 RN ，Dropbox 放弃 C++跨平台技术 等等，这些大厂的经验，也应该给我们一些警示，这些东西用的越多，可维护性也就越差，也会让招聘变得更难。这些是好是坏，不能一概而论，什么样的场景，配合什么样的技术，这无疑是重要的。
之前有看过一篇文章，写的是一个程序员吐槽 Oracle，虽然全世界都在用 Oracle，但不排除，它也是个屎山。软件工程发展了这么多年，程序员大佬们写了那么多的书来指导，可是，还是无法避免，一个项目，最终沦为屎山，网上有很多因为代码写的烂，导致迟迟不能交付，最终拖垮公司的。这种最终讨论，总会上升到哲学性的问题。尤其是在中国，赶紧上线，才是大部分公司的常态。优化，是不可能的。
随便写写吐个槽，不过作为一个程序员，我们还是要有自己的底线的，起码要对得起自己。