Android工程师说：只有「不当Android工程师」才是「好工程师」

开发Android需要经历些什麽样的心酸？...不是说iOS开发不会有心酸事，一想到「天线门」、「TouchID出现又消失」.......，嘴角总是会不经意露出「爽快的微笑」。

看到Fushia出现（或每次有发展进度上新闻），总是一堆「疑似C++工程师」在那边忍住笑意的说「Google要抛弃Android」了，——大家都有自己的辛酸事，大家都会觉得「别人过好爽」（像「Android的市占率」跟「Java的物件导向好学习、好上手、好开发」），但事实上并不是。

开发Android有多心酸呢？
前面有提到：大型专案经常「最早的雏形成品开发很容易，但真正进入专案阶段，就问题连连。」
为什麽？
到底会碰到些什麽情况？

（下面这个情况，虽然在这几年没再发生了，但我觉得挺经典的。）

在Android中，「活动」的内容可以自行设定，但如何启动、如何初始化、如何卸载释放，就必须要由系统来掌控。（这称为生命周期。）
在Android4/5时，开发到一半，伴随着专案规模成长，经常从天外跑出一个现象就是：请系统启动某个刚完成、准备测试的特定功能，结果这个功能最後虽然启动了，却连续的执行了两次初始化；不单单是连续执行了两次初始化，事实上，这是两个不同的「活动」，（同一个物件、不同实体，）但第一个活动初始化完成後就石沈大海了！（不是初始化了吗？为何不执行回收释放动作呢？）

所以如果雏形所确立的框架中，会在初始化执行某些功能，则这些本来计划在初始化中执行的功能会非常不稳定。
例如要进行连线......本来只要执行一次，会变成执行两次。

这问题不难修正。
问题在於专案管理结构：很多负责开发核心雏形的工程师不太愿意承认「他写好的雏型框架会发生这种事情」，即使承认了，进行的修正也未必适合所有正在进行中的专案，个别专案试用新的解决方案的成本可能会差异很大。

一个问题完之後是另一个问题...「为什麽不能承认、然後进行修正？」

这可能是因为他的工程师素养中并没有「平行沟通」这种东西。

有个现象是：如果GoogleDev中写了篇文章，（不管这文章是否权威、是否专业精准，）只要它有提到这个现象发生，这位工程师就有很高的机会承认「对！我写的核心发生了这个现象。」
反过来说，如果GoogleDev没有出现过类似的文章，那他面对这个问题的方式大概就会变成「耸耸肩，说：一定是某某工程师的程序码有问题，请他自己检查一下、Survey一下症结就好了。」

这类工程师做事情大概就是简单三个原则：「凡事都只认官方文件。」「凡事都只认权威的文章。」「尽可能花心思去精通这些管道释出的文章，而不是认真培养程序建构的技能。」

先不要评论。
最初写程序，有个DK和简单的小作家能写份「.txt」文件就够了。
虽然DK偶尔会无法执行，但排除方式都挺一拍两瞪眼的。

後来，开始有了IDE/专案建构工具/版控软件........
解决问题的方式（可能性）开始极速倍增。
DK版本 x IDE版本 x 专案建构工具版本 x 版控软件 x 防火墙设定 x …… ＝ 直接寻求别人的意见去解决你碰到的问题时可能会得到的答案数量。这些答案中超过一半都是错的，剩下的一半答案几乎都只是让问题收到的错误讯息变得不一样，（所以一样是错的。）

这些问题有个特性：解决方式通常没有逻辑，无从推论，大概就是某个不可思议的参数、必须要使用某个特定不可思议的值。

如果身为工程师，工作和解决问题的方式不再是以「逻辑」、「结构」、或演算法之类的事情为主，而是要不停的在「别人提供的制式程序」中查找，那请问工程师还能叫工程师吗？

甚至，习惯在这样的环境下工作的工程师可靠吗？

（本来想要在这篇文章中把Google装来痛骂一顿，这样才能更契合标题，但时间精力有限，还是明天吧！）