1. 尽量努力的多去阅读别人的代码，越多越好

对所谓“屎山”的代码，你如果全都读进去，研究下去，你起码会有两个好处:

你能具体知道代码烂在什么地方，那么以后你的代码就不会出现同样的问题——由于你知道了烂代码烂在哪里，你一定能写出更好的代码，从而让那些屎山的代码逐渐会被自己写的好代码所替代。这样一比较，你的专业能力会显得非常突出，让更多的人认可你这位架构师的能力。
你对公司这些代码读的越多，掌握的越多，你越不可替代——对公司这些代码读的越通透，你越能更快速轻松地把控这些代码，让以后对这些代码的变革变得更容易。而轻松修改、革新这些代码的能力，就会变成你在这家公司不可替代性的重要因素。

所以，各种代码，无论质量好坏，都需要能读懂读通，并且读的越多越好。

能读懂读通任何质量的代码，才是真正的掌握了阅读代码的能力。读的越多，则能识别代码质量的能力就越强，将来自己就越能写出更好质量的代码。

2. 准确判断项目的发展方向

对第二天的会议提前和参会各方沟通，开会时间尽量协调到一起，这样能腾出一整块儿时间，把当日所有可能的会议都集中开完。后续就会有连续的时间去深度工作了。
在开会前一天，把会议内容和可能出现的问题都预先做功课。一方面是防止会议开着开着跑题；二是万一出现争议问题，可以列举出来事先准备的技术方案，这样也能加快会议进度。
还有，对于一些不那么重要的会议，一定会态度坚决的避开或者指派别人参加。

对于版本工具使用不当，会耽误开发人员很多时间。而版本控制工具，即使一些工作多年的程序员，往往也经常会使用不当。

这些不当的使用，会造成许多问题。比如，各种各样的代码冲突、版本重叠，莫名其妙的代码丢失。

对此，每次负责一个新项目，都会严格指定版本工具的使用规范，会花时间对开发人员统一培训版本工具的使用。同时，也会把各种技巧、注意事项、常用命令整理好，放在内部的共享文档中。

这些举措，在实践中，大大改善了版本控制工具不当使用造成的问题。

有一个项目组在规范使用之后，竟然比之前的开发速度快了三分之一。可想而知，这个问题有多严重了。

从纯技术角度，当然会鼓励人们想的越全面越好。但是，在实际落地的时候，你要明白小项目，没必要为了各种概率很低的风险，把明明很小的一个功能给做的很复杂。

针对这种问题，就需要技术 Leader 及早发现、介入，防止出现过度设计、过度开发。

对于任务紧急程度的判断经过深思熟虑、实际分析过的，任务之间的先后顺序，也和任务交付人认真沟通。对一些根本没必要的任务，态度坚决的对这些任务说 No。

我们需要学会的是不要写呆代码。你不能写完代码运行下没问题就觉得正常了，你在写代码之前需要好好思考。

这种思考，既不是什么搞设计模式松耦合，也不是搞功能切分独立成块。这种思考本质是需要你写代码前去理解业务，去真正明白业务在实际是怎么运作的。

比如，你修改了注册功能，可以兼容第三方登录。那么，可能有的老用户会重新注册一个账号，以方便第三方登录。那你对这种情况，其实该做的是绑定，而不是让用户重新注册个新账号。

这种疏漏，等到上线之后才发现就晚了。这不能完全依赖产品经理，作为一个技术人员本来就应该对自己的功能做通盘的考虑，这才是真正的负责。

比如，你搞一个用户充值功能。本来你只是想着用户游戏内购直接充值即可。但是，在实际上线后，有时候运营为了方便 vip 客户或者为了和第三方渠道互换资源，也会使用这个充值功能。

运营大批量的连续充值，并且这些充值转换成系统中的货币，就像游戏中的元宝，就有可能超出 Java 中的整数上限，从而造成问题。如果你提前知道用户、运营人员都是怎么使用这个功能的，你就会把数据类型修改成 Long 了。

博客园持续更新，欢迎大家关注，一起成长。

参考链接：https://mp.weixin.qq.com/s/65CiE5vZVyFqKMf0x-gwjA

版权申明：内容来源网络，版权归原创者所有。除非无法确认，都会标明作者及出处，如有侵权，烦请告知，我们会立即删除并致歉!

支付宝打赏支付宝扫一扫二维码微信打赏微信扫一扫二维码微信扫一扫关注公众号

百人技术团队技术总监的忠告百人技术团队技术总监的忠告

原创文章，作者：254126420，如若转载，请注明出处：https://blog.ytso.com/267898.html