公司的一款产品已经研发了一年多，我之前参与了整体的产品规划，并不曾深入到代码层面。最近要具体负责这款产品，就仔细地看了一下后端服务的代码实现，还是略感到震惊。

这款产品的研发团队并不是专职，还有其它的产品研发工作，以及项目支持工作，时间安排上不算宽裕。这我都能理解，想到在代码质量上会打折，但还是低估了打折的程度。代码层面的问题已经很严重，结构层次不合理，接口命名不规范，冗余代码到处都是，离失控也只剩一步之遥了。后续要想添加新功能，必须对原有代码进行重构优化，否则根基不牢固楼层越高越容易崩塌。

造成这个局面的原因有很多。

第一，缺少有把控力的技术负责人。一款产品需要有一位能掌控全局的技术带头人，特别是在团队成员技术能力高低不齐的情况下，更是如此。这个技术负责人需要能把控住产品的整体方向、设计原则和代码质量，用自己的行为做出良好示范，并要求团队成员按照研发规范操作。

第二，团队成员不固定。一款产品需要一个稳定的团队，一方面是利于高效协作，一方面是有归属感能够持续优化产品。临时成员有敷衍心态，反正搞一把就走，没必要花大气力关注设计和代码质量，能实现功能就好，反正代码乱成一团麻后面跟我也没关系！

第三，编程基本功薄弱。有些小伙伴不是不想把代码写好，是他不知道该怎么做，心有余而力不足。新人编程基本功薄弱是正常的事情，每一个刚出道的程序员都会面临这个问题。但是，有些人工作十年后，能成为大神，而另一些人，写出的代码还是不堪入目！为什么呢？还是那句话：知耻而后勇！看到自己的弱点，我感到可耻啊！我一定要想办法改进它！今天改一点，明天改一点，日拱一卒，不期而至。

第四，公司大环境的影响。公司在文化制度上不够理想，缺乏一种积极进取，你追我敢，争创一流的精神！

第五，项目支持的干扰。项目支持工作，的确是占用了一些成员较多的时间。但这并非导致代码质量低劣的主要原因，不能以此为借口。因为项目支持总是以产品进度的拖延为代价，并没有要求在原计划限定的时间内完成产品开发。

以上这些问题，有公司层面的，有团队层面的，有个人层面的，有些比较容易解决，有些是极难解决的。今天我只想从个人的角度——作为一个普通的软件开发人员——探讨一下如何排除各种环境干扰而获得自身的成长。

我以前曾分享过斯多葛学派的控制三分法。我们再复习一遍哈。围绕我自身的所有事物可以分为三类：第一，我能完全控制的；第二，我完全不能控制的；第三，我能控制一部分但不能完全控制的。

对于我能完全控制的事物，我会倾注大部分的精力，全力以赴。比如编程技能，如何设计、如何封装、如何重构、如何测试，这是我能完全控制的事情，我会花大量的时间孜孜不倦地完善这些技能。

对于我完全不能控制的事物，彻底地忽略掉。比如公司的文化制度、团队成员的去留，这是我完全不能控制的事情，我根本就不会费那个心思，顺其自然好了。

对于我能控制一部分但又不能完全控制的事物，进一步采用目标内化的策略，以减少失败时的失落感。比如，我参与研发的产品最后能不能在市场上成功是一件我能控制一些但又不能完全控制的事情，怎么办？与其担心产品能不能成功，不如换一种思路：我的目标并不是让产品在市场上大获成功，而是在研发过程中精心打磨自己的编程技艺，发挥出自己的最佳才能，尽可能地让产品优秀。让产品在市场上成功是不可控的，而磨炼自己的编程技艺是完全可控的，这样就完成了由外部目标向内部目标的迁移。只要我尽力练好了基本功，就算最后产品失败了，我也不会太懊悔，因为我个人获得了成长。

对于任何一项可以不断精进的技能，游泳也好，编程也好，练好基本功都是绕不过去的坎。我们有时候自以为聪明绝顶，投机取巧一把，觉得可以不用费那么大气力就可以取得成就，何必要苦哈哈地练习枯燥的基本动作。但到头来总会发现到达某一个点后举步维艰，再也难取得大的进步，回过头还得把基本动作练习纯熟，才能更上一层楼。

我的学习游泳的经历就是很好的佐证。如果不是这次我认识到自己在基本功上的不足，痛下决心把游泳的基本动作练习好，我永远只会停留在自娱自乐的菜鸟级水平上，学习更高深的游泳技能更是与我无缘。

顺便跟大家报告一下，现在我已经可以连续游上四个来回400米了，后续只要技巧和力量练习同时跟上，进步的空间还是很大的，我有信心。等我蛙泳练习纯熟，目标是连续游上十个来回1000米，我就开始自由泳的练习了，给我加油吧，朋友们！