2012年入行，从前端开发入门。2013年转IOS开发，一直到2019年7月。
在13年至19年期间，3年的基础业务开发到移动端主管。开始慢慢思考管理这件事。
直到17年负责整个移动端，移动端团队的搭建，项目推进，实施，线上问题的解决。对管理的感知更加深刻，管理不像技术这么实在，管理的对象是人和事，技术面对的是机器和业务逻辑。
技术上的牛逼更容易被人认可，应该说是更容易被懂技术的人认可。而管理上的能力容易受制于公司的组织结构，不像技术更容易进入角色。这也是2年前，没有职业安全感，选择从事java开发的一个重要原因。
但今天看来这似乎又不是那么肯定。技术型的管理与普通的业务管理会有不同的地方，至少懂技术是必须的。甚至是有架构经验，实际项目的经验对于解决技术难点，以及业务实现的具体方案在需要考虑实现成本与质量之间的平衡时，这是必要的参考条件。或者说这是解决80%技术问题需要的基本技能，剩余20%的问题，利用已有的知识储备，融汇贯通，总结出可行的方法论来解决。
比如：技术选型，对于有项目经验的管理者来说，结合现有业务的规模，系统最大可承受的吞吐量，业务开发的难度，现有技术人员的技术能力，实现和维护的成本，最终得出的可行方案。
如果有项目经验就好比有现成的技术方案，只需要确认部分未知的变量。而对于无项目经验者，变量会多一些，需要将变量转换为常量需要一些决策和调研时间。但是最重要的是参考的维度，只要考虑的维度一致，最终的方案是接近的。最坏的结果是考虑的维度不够，导致最终得不到预期的结果。
所以技术选型，至少需要做到两点：
1、确定需要参考的维度(业务指标，软件成本，人力成本，后期维护成本，技术学习曲线，技术难度，瓶颈，优势，劣势，业务场景匹配程度)。 2、明确常量与变量，剩下的就是积累总结经验，将变量范围不断缩小。
技术能力
这里的技术能力可以是项目经验，更重要的是技术思维。从事软件行业，想扎根这个行业，应该具备技术最底层的思维能力，对于技术底层的运行原理应该熟悉，甚至掌握。这是这个行业变化最小的，也是最关键的地方。其它技术都构建在此之上，不论是算法，数据结构，或者是设计思想，架构等等，都源于底层技术延伸。这也是提升技术学习能力的关键，有了这部分扎实的基础，对于学习新技术的理解能力，设计能力的提升都是一个加持。如果把各种技术之间的关联比作齿轮，这部分基础就是最核心的那部分，转得最慢，但影响范围巨大。
编码习惯
刚开始入行时，会非常注重编码，但也不得要点。会加很多注释，也会强制按某种方式命名，去强制遵循某个规范。
目前来看来编码做好两点：命名遵循一贯性，代码具有结构性。最终的目的，实现代码的可读性。
一贯性：命名涉及到针对不同的场景，方法，变量，常量（临时变量，成员变量）…，对应不同的场景，都应该具有相似性。能够一眼分辨出不同类型的命名。对于不同的语言，可能命名习惯不同，但一定符合一贯性。就好比同一类型的动物具有相似性，人们一眼就能分辨出来这是一类动物，例如：鸟类都有翅膀。
可读性：维护代码的哥们只需要通过阅读代码，就能够了解整个业务实现流程。
结构性： 做到结构性的思考问题，从大流程到具体实现，输出的代码就自然成型。后期的维护，是围绕如何持续保持稳定的结构。如果不能满足业务，需要修改之前的结构，再进行重构。而好的结构设计，一般性的业务迭代，都应该在固定的大结构下去做修改，不应该影响整个结构的稳定性。 就好比开发商交付的清水房，大的框架已经确定，内部的装修只要不动承重墙，是可以满足大部分业务的。
管理能力：
初期80%的精力在技术，20%用于对人的管理。前面80%做好，是后面20%的基础。有一句话非常赞同，以至于听一遍就记住，大致意思是，不能让自己成为团队的天花板，而是地板。这样带出来的团队才是不可限量的团队，这可能也只是一种理想状态，并未求证和实践。
业务理解能力：
技术需要去理解业务，理解业务的目的不是去推翻业务。而是为了业务在落地时做好与技术实现的平衡。业务需求如果没有限制的话永远是要最好的效果。技术如果没有时间限制的话，任何业务都可以满足。而没有时间限制，任何业务都没有意义。业务问题实质就是在有限的资源条件下，用最适合的方式解决问题。技术了解业务的目的，就是找到业务取舍的部分、技术实现的质量与时间的平衡点，最终得出一个解决问题的最优解。
所以接下来我要怎么做？
1、基础能力还是第一位，操作系统，计算机系统原理，计算机网络，高等数学，离散数学，英语最近两年需要学习的方向
2、基础能力产生效益会相对缓慢，但影响也是持续最久的。短期类掌握JVM底层原理，Srping关键技术(Ioc,Aop)的实现原理, Redis底层原理，对实际项目会有实在的帮助
3、设计模式是提升代码结构性设计的一种工具，可以进一步巩固。
