-
不要毫无计划地写代码，思考、调研、计划、编码、测试、修改，一个都不能少；
-
不要写代码前过度计划，在一头钻进代码前做点计划是好事，但是即便是好事，也可能物极必反。
-
请勿低估代码质量的重要性，如果你只能够关注你所写的代码的一个方面，那么肯定是可读性。
-
尽量不在循环里远程调用、或者数据库操作，优先考虑批量进行。
- 远程操作或者数据库操作都是「比较耗网络、IO资源」的，所以尽量不在循环里远程调用、不在循环里操作数据库，能「批量一次性查回来尽量不要循环多次去查」。（但是呢，也不要一次性查太多数据哈，要分批500一次酱紫）
-
使用实现功能的最简单方案，作为专业的程序员，你的职责不是找出问题的一个解决方案，而是找出问题的最简单的解决方案；
-
适时放弃，当你开始怀疑一个解决方案的时候，你就应该考虑抛弃它，并且重新思考这个问题。不管你已经在这个解决方案中投入了多少精力。像 GIT 这样的版本控制系统能够帮助你分开管理和尝试多种不同的解决方案，把它利用起来吧；
-
擅用 Google，除非你正在使用一种极其前沿的技术，否则当你遇到一个问题时，很可能别人早就遇到过同样的问题了，并且也找到了解决方案了。给自己省点时间，先 Google 一下；
-
做好封装，基本的想法就是你想你的代码高内聚和低耦合，意思是说保持相关的代码在一起（在一个类中），降低不同类之间的相互依赖；
-
做好规划，写好需求再写代码，尽可能编写目前正在实现的方案所需的最少量代码；
-
要懂算法，使用合适的数据结构；
-
不要写重复性代码，要用好配置文件，不要使用没必要的条件语句和临时变量；
-
写完代码，脑洞一下多线程执行会怎样，注意并发一致性问题
- 我们经常见的一些业务场景，就是先查下有没有记录，再进行对应的操作（比如修改）。但是呢，(查询+修改)合在一起不是原子操作哦，脑洞下多线程，就会发现有问题了。
- 接口需要考虑幂等性
- 尤其抢红包、转账这些重要接口。最直观的业务场景，就是「用户连着点击两次」，你的接口有没有hold住。
幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。
在编程中.一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。
一般「幂等技术方案」有这几种: - 查询操作
- 唯一索引
- token机制，防止重复提交
- 数据库的delete删除操作
- 乐观锁
- 悲观锁
- Redis、zookeeper 分布式锁（以前抢红包需求，用了Redis分布式锁）
状态机幂等
-
做好代码注释，但是不要给傻子都知道的代码写注释；
-
不要觉得代码运行起来就是正确的，有些时候代码的 bug 可能并不是显而易见的；
- 「改完代码，自测一下」 是每位程序员必备的基本素养。尤其不要抱有这种侥幸「心理：我只是改了一个变量或者我只改了一行配置代码，不用自测了」。改完代码，尽量要求自己都去测试一下哈，可以规避很多不必要bug的。
-
要能够质疑既有代码，作为一个初学者，总是应该假定那些你读不懂的、且没有文档注释的代码很可能就是糟糕的代码。质疑之，询问之，使用 git blame 揪出罪魁祸首！
-
不要过度迷恋最佳实践，我觉得“最佳实践”其实是害人的，它暗示着你不需要深入研究它，这就是有史以来最佳实践，不用质疑！
-
不要过度迷恋性能优化，如果你在运行代码之前就在优化它了，那很可能你就是在过早优化代码了，也很可能你正在费时费力做的优化是完全没必要的。
-
手动写完代码业务的SQL，先拿去数据库跑一下，同时也explain看下执行计划。
- 可以先把它拿到数据库跑一下，看看有没有语法错误嘛。有些小伙伴不好的习惯就是，写完就把代码打包上去测试服务器，其实把SQL放到数据库执行一下，可以规避很多错误的。
同时呢，也用「explain看下你Sql的执行计划」，尤其走不走索引这一块。
explain select * from user where userid =10086 or age =18;
- 主从延迟问题考虑
- 先插入，接着就去查询,这类代码逻辑比较常见，这「可能」会有问题的。一般数据库都是有主库，从库的。写入的话是写主库，读一般是读从库。如果发生主从延迟，很可能出现你插入成功了，但是却查询不到的情况。
- 如果是重要业务，需要考虑是否强制读主库，还是再修改设计方案。
- 但是呢，有些业务场景是可以接受主从稍微延迟一点的，但是这个习惯还是要有吧。
- 写完操作数据库的代码，想下是否存在主从延迟问题。
- 主从延迟问题考虑
- 通俗点说，我们使用缓存就是为了「查得快，接口耗时小」。但是呢，用到缓存，就需要「注意缓存与数据库的一致性」问题。同时，还需要规避缓存穿透、缓存雪崩和缓存击穿三大问题。
- 缓存雪崩：指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。
- 缓存穿透：指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，进而给数据库带来压力。
- 缓存击穿：指热点key在某个时间点过期的时候，而恰好在这个时间点对这个Key有大量的并发请求过来，从而大量的请求打到db。
-
以用户体验为目标，要站在最终用户的角度看问题。专业的开发者要考虑这个特定功能的用户需要什么、怎样使用，要想方设法使得这个功能容易让用户发现和使用，而不是想方设法在应用中用最便捷添加这个功能，毫不考虑这个功能的可发现性和可用性。
-
为你的开发任务挑选合适的工具，你可以使用最原始的工具建造房子，然后享受甜蜜时光。你也可以花费一些时间和金钱去了解先进的工具、更快地建造更好的房子。工具在不断地改进中，你要乐意去学习它们、使用它们。
-
要理解好代码问题和数据问题之间的关系，即使是程序中最小的 bug 也会导致它所管理的数据去到一种不可预测的状态。尤其是当所有数据校验都完全在这个有 bug 的程序中进行时。
-
切勿重复造轮子，使用好现有的轮子和各种开源库，会让你事半功倍。当然，不要仅仅为了使用一两个函数就引入一整个代码库。
-
调用第三方接口，或者分布式远程服务的的话，需要考虑异常处理，安全性，超时重试这几个点。
- 异常处理（比如，你调别人的接口，如果异常了，怎么处理，是重试还是当做失败）
- 超时（没法预估对方接口一般多久返回，一般设置个超时断开时间，以保护你的接口）
- 重试次数（你的接口调失败，需不需要重试，需要站在业务上角度思考这个问题）
简单一个例子，你一个http请求别人的服务，需要考虑设置connect-time，和retry次数。
如果是转账等重要的第三方服务，还需要考虑「签名验签」，「加密」等。
-
对代码审查保持正确的态度，应该把每一次代码复审当作是学习的机会，欢迎他们、感激他们、从中学习，最重要的，当你从你的代码复审人员那里学习到东西的时候，要感谢他们；
-
用好版本控制工具和系统，新手往往低估了一个好的版本控制系统的威力，我这里所说的好的版本控制系统其实就是指 Git；
-
正视 Error，Error 是好东西。Error 意味着你在进步，意味着你可以通过简单的后续修改就获得更多的进步。专业程序员喜爱 Error。新手则痛恨 Error；
-
方法入参尽量都检验
入参校验也是每个程序员必备的基本素养。你的方法处理，「必须先校验参数」。比如入参是否允许为空，入参长度是否符合你的预期长度。这个尽量养成习惯吧，很多「低级bug」都是「不校验参数」导致的。
如果你的数据库字段设置为varchar(16),对方传了一个32位的字符串过来，你不校验参数，「插入数据库直接异常」了。 -
修改老接口的时候，思考接口的兼容性。
很多bug都是因为修改了对外老接口，但是却「不做兼容导致」的。关键这个问题多数是比较严重的，可能直接导致系统发版失败的。新手程序员很容易犯这个错误哦~
所以，如果你的需求是在原来接口上修改，，尤其这个接口是对外提供服务的话，一定要考虑接口兼容。举个例子吧，比如dubbo接口，原本是只接收A，B参数，现在你加了一个参数C，就可以考虑这样处理。 -
不断的学习的精神
程序员要保持不断的学习与进步，因为程序员界新的技术层出不穷，在新的技术中去注意自己应该掌握的知识点，学习并利用就是最好的竞争力。 -
充足的睡眠和持之以恒的锻炼
对于程序员来说，加班是常事，但是生活的作息的良好可以让我们得到更好的工作效率，充足的睡眠是保证我们工作效率的第一开端。哪怕我们工作再忙，切记一定要保证充足的睡眠。持之以恒的锻炼源于运动是生命之本。 -
团队精神和协作能力
可以说是基本素质，这是程序员应该具备的最基本的，也是最重要的安身立命之本。把高水平程序员说成独行侠的都是在呓语，任何个人的力量都是有限的，即便如linus这样的天才，也需要通过组成强大的团队来创造奇迹，那些遍布全球的为linux写核心的高手们，没有协作精神是不可想象的。独行侠可以作一些赚钱的小软件发点小财，但是一旦进入一些大系统的研发团队，进入商业化和产品化的开发任务，缺乏这种素质的人就完全不合格了。 -
工欲善其事必先利其器
持续优化开发工具和方法（包括编码IDE、运行环境、前后端调试工具）
将耗时重复的工作编写为手动脚本、自动脚本或辅助工具；
如服务器监控脚本、防攻击脚本等
8799
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
