从业20年大佬的经验谈：程序员应多做这4件事

　　从业20年大佬的经验谈：程序员应多做这4件事

　　我从事自由网络的开发工作已经有将近20年的时间，回首过往的工作经历，我比较大的感受就是：这四个习惯，要是能早点儿养成就好了。

　　深层自动化

　　你一直擅长运营单人商店，并且能将很多细节和流程牢记在心。该客户的部署有15个步骤，每月执行一次，每次运行最多花费5分钟。

　　你要与同事讨论该问题，明确需构建的所有功能和需修复的所有故障，有一个问题将反复出现：自动化仅花费你几分钟的时间且每隔一定时间段执行一次，这种操作真的值得吗?

　　只需要5分钟的时间即可手动执行该过程，频率为每月/次。而将该手工过程自动化需要花费3个小时。自动化操作也许会将运行进程所需时间间从5分钟减少到3分钟。

　　这里的关键在于：由于流程实现了自动化，运行此流程的人员可能不再是你本人。

　　月收益不仅仅是2分钟。你的5分钟可以精简为0分钟，因为流程自动化了这三分钟的事可能会交给别人来做。事实上，其他的任何人都可以执行此任务。关键时刻，团队中有3分钟空闲时间的任何成员都可以去运行该自动化流程。

　　不必亲力亲为。如果实现了深层次自动化，其他成员可以分担此项任务以便让专注。

　　广泛测试

　　由于擅长记忆所有细节，你知道构建新功能时需调整的每个小开关和切换按钮，确保没有通过添加新代码损害其他功能。

　　然而，你始终确信没有遗忘什么吗?要是其他人添加了代码呢?他们是否需要了解各个开关和切换键?每当别人整合新代码时，你可能还是会忐忑不安。

　　测试是增强自信的过程——即确信自己添加的新代码不会破坏任何旧代码;让开发者有信心部署好代码而无需午夜醒来并焦虑思考：“天哪，如果用户在删除付款方式后(而非事前)单击该按钮，他们将获得500元。我需要马上还原程序。”

　　编写测试代码确实有点耗时，其效果可能不如执行代码。但是，编写测试代码能让头脑保持清醒。测试代码的编写过程可以让开发者重点关注代码的性能要求。然后，再去执行具体任务。

　　测试为开发者提供空间——让开发者大脑有足够的空间专注于代码重构及改进，因为开发者不再需要忐忑追踪所有开关和切换键以维护重构过程。测试会帮助开发者完成追踪任务，你有了足够的空间去重构代码。

　　除此之外，深层自动化与广泛测试的组合是重要加分项：深层自动化+广泛测试 =深层自动化测试。使用自动化测试，任何人都可以贡献自己的代码并运行测试。你可以充满自信地进行构建、调整并进行演示和交付。

　　传授知识

　　程序员会遇到很多具体的编码问题，并在网络上寻找处理方案。这样不一定能找到解决之道。你可以在一些第三方文档中闲逛，调试不同的设置，创造性地思考问题，然后问题就得到解决了。

　　解决了自己的问题可不算结束。想想那些即将面对你刚刚经历过的问题的程序员们，花时间和精力解决了这个小问题后，请不要浪费专业知识。

　　笔者建议向他人传授所学知识。KentC.Dodds称之为“增加价值影响”，SWYX称之为“公共学习”。无论是撰写教程文章、博客文章，还是堆栈溢出问题的答案，程序员都需要明白这点：让他人受益，不要掠夺知识。

　　你自己也会从中受益。准备传授知识时，无论是实际的演示文稿，文章还是主题帖子，你都会比初次学习时更好地掌握解决方案。你将更加深入地理解问题所在，优化初始解决方案并了解如何与初学者交流深层次、低层次概念。

　　你将发现并为各种难题设计出色的解决方案。这就是为客户服务的工作内容，这也是在特定代码段中的任务。花些时间“增加你的价值影响力”——用授人以渔的方式分享自己的发现。你能帮助别人成为专家。同时你自己也将成为专家中的一员。

　　让他人参与

　　回想大学校园做团队项目时，我们都知道自己写的代码水平很低，甚至不清楚自己在做什么，调试实际上只是在搅动代码行以保护某些内容不受损。

　　作为一名独立的自由职业者，你可以看到代码的完整内容。而且很大程度上，所有的代码也许只被你一人浏览过。这或许会让你感到害怕和不安。

　　这种恐惧和危机感阻碍了你向他人求助并组建团队的脚步。原因在于你永远不会觉得自己的代码已经接近完美，能让其他程序员印象深刻。

　　恐惧和不安会限制程序员的发展。严重情况下，你与他人合作学习的机会、你脱离独立项目并为团队案例尽心尽力的机会、你成长的机会等，都会受到影响。

　　笔者建议程序员养成让他人积极参与的习惯。请其他程序员查看一下你的代码，接受并希望那些审阅者会注意到你代码糟糕透顶的事实。悦纳自己的不足，然后从中成长。顺便说一句，他人的代码可能也有糟糕的部分。

　　另外，当程序员开始践行此操作时，会自言自语：“特里，我想给你演示我已构建的这个模块，但是再给我最多3天的时间，我需要清理一下数据。”

　　无需这样。所有代码都存在改进空间，永远不会完美地完成检查任务。程序员总是想要拥有更多的时间来准备。只需拥有代码现在的样子即可，然后，请他人来参与审查吧。

　　更早更频繁地接纳他人的意见，你的代码才能逐渐得到完善。在编码时，程序员会对自身代码有一定预期，明白是哪些编码习惯或不足让审阅者感到尴尬或给予差评。

　　代码永远不会完美，不要等到代码完美无缺的那一天，才寻求他人的观点来阅览代码并给出反馈，那一天永远不会到来。