软件技术学习笔记

在软件开发领域，人员的离职或转岗是经常看到的。有的团队每年离职/转岗率10%~20%，有的团队则高达50%。人员的离职，对团队有以下冲击：

1. 项目进度受到冲击，只能拆东墙补西墙。
2. 业务增长放慢或缩减，收益减少。
3. 在职人员的负担加重，心里也会有想法，工作效率降低，可能引发更多的人员离职。
4. 新成员培养成本。寻找合适的新成员并不容易，需要一定的周期；新成员入项需要老员工的指导；新成员需过一段时间才能独立开展工作。

我们从驱动力、软件架构、生产效率、成本、收益、压力与成长等几个方面来看这个问题，再看看一些应对之策，如何给公司创造长期的、更大的价值。

在编码时，我们一般都遵守“Less is Better”教条。按照代码行数，大部分时候也是对的。但是，对整个系统而言，并不是所有的场景都满足“Less is Better”。敏捷宣言中的“简单设计”不是没有设计，编码之前进行适当的软件架构设计是非常有必要的。

这段时间参加了一些前端面试，也看到了一些软件问题，主要体现在以下几个方面：

1. 第三方件管理。
2. 污染全局变量，修改原生对象。
3. 使用设计模式去Hack有问题的代码。
4. 组件化开发，并没有做到单一职责原则。

经过长时间的观察，我发现软件开发过程中的许多活动都与自动控制系统、通信系统有非常相似的地方，于是把它们变成我的一个指导思想。本文就从这两个系统的角度来思考软件开发，仅代表个人观点，也许还是不够成熟的观点。

在我的软件职业生涯中，大部分时间都在设计与开发新系统。刚开始参加工作的时候，代码也写得不好，但也不会糟糕到开发效率越来越低的程度，也有业务不够复杂的原因。后来开始学大厂的开发规范、极限编程、敏捷软件开发与设计模式，再后来开始学软件架构相关的知识。在软件设计上，“Uncle Bob"对我的影响颇深，学习他写的书也比较多。

在这类书籍当中，里面讲到了稳定依赖原则、稳定与不稳定划分等概念。一开始并没有体会到这些概念的重要程度，只需遵守原则、重构坏代码，一切都很顺利。在亲自接手腐烂的代码项目之后，才深刻感触到代码与业务的关系就是“水能载舟，亦能覆舟”，处理好这些概念就变成跳出泥潭的关键。

作为一名喜欢研究软件技术的铁憨憨，一直以来，很想写两篇关于软件思想的文章，主要目的是：1、记录自己一段精彩的经历；2、把自己独特的想法成文。

后续的文章会有：

1. 成功跳出“泥潭”的经历：接手一个“大泥球”代码的前端项目，运用软件大师那里学来的知识，如何当好一名“学生”。
2. 从自动控制系统、通信系统的角度去看软件工程、软件设计，发现软件相关的许多活动都符合这两个系统的特征。
3. 哪些情况下“Less is better”教条并不适用。
4. 在软件阵线上见闻与思考：我们的“士兵”为何临阵脱逃，有的人不再从事软件开发工作。

对个人而已，这方面的文章要比一个技术实践难写多了，要写好只能慢慢道来。