文章转载自「开发者圆桌」一个10年老猿原创文章传播开发经验，尤其适合初学者或刚入职场前几年程序猿的微信公众号。

wKioL1i5Ck7AkeuMAAChGHetiEM164.jpg

我播种，所以我收获。我深深地懂得“一份耕耘，一分收获”的道理。所以，我握着知识的锄头在学习的田野里辛勤地劳动着，在梦境中从朦胧的状态逐渐清晰，直至将它成为现实。5.1劳动节段子一枚，祝大家劳动节玩好。


农业劳作有农活技巧，工人上班有工作技巧，程序员coding也有coding技巧，下面总结了一些老猿们的生产技巧，有不错的参考意义，不要照搬，根据实际情况去应用它们吧。


短时间内，你可能无法感受到它们的作用，但是经过一段时间的积累和实践，你会发现它们的意义非常大。废话不多说了，我们来看看这些小技巧吧。


重构是程序员的主力技能；你不可能一直开发，也会有维护工作，维护工作甚至比开发更费心力，因为你首先要看懂，然后才可以修改甚至重构他人的代码。


工作日志能提升脑容量；养成写工作日志的好习惯，一是可以跟踪自己的工作情况，二是可以敦促自己合理安排工作时间。


先用profiler调查，才有脸谈优化；通过工具发现存在性能问题或者系统存在瓶颈再去优化，如果没有任何问题，不要着急去优化，那会得不偿失。


注释贵精不贵多；杜绝大姨妈般的“例注”，漫山遍野的碎碎念注释，实际就是背景噪音。你可以多参考一些Apache，Github上的开源代码是如何添加注释的。


普通程序员+google=超级程序员；搜索能力是程序员必备的，不同的搜索方法和技巧，搜索到的内容也会千差万别，关于程序员的搜索能力，可以参考我之前的一篇文章「谈谈搜索能力」。任何事情都有两面性，一味的依赖搜索会在一定程度上让大脑变得懒惰，不再思考和记忆问题，无法形成完整的知识体系，这是需要不断警醒的。


单元测试总是合算的；只要你是写代码的，写的代码质量再高，也难免有bug，而单元测试可以有效地发现这些bug，提高你的代码质量，而如果是采取测试驱动开发的，更能影响到你对整个系统的设计，这样设计出来的系统的可测试性会大大提高。


很多公司的开发人员写完代码就提交了，有的可能会简单写个测试代码(而非单元测试)来检验下代码是否能正常工作，当调用者调用这些方法(函数或接口)时，经常会发现有问题，由于这代码可能不是他写的，找bug就浪费了时间，有的隐藏的bug甚至在线上系统中才发现。造成的损失和影响有时就会很严重。


不要先写框架再写实现，最好反过来，从原型中提炼框架；先从解决问题出发，实现功能原型，然后再根据需要提炼公共方法或框架。


代码结构清晰，其它问题都不算事儿；不要写只有自己懂，而别人看不懂的代码，如何让自己的代码结构更清晰，请参考「代码大全2」这本旨在提高代码质量的书。


分清好项目和坏项目；好的项目作风硬派，一键测试，一键发布，一键部署；烂的项目生性猥琐，口口相传，不立文字，神神秘秘。


编码不要畏惧变化，要拥抱变化；在程序员生涯中唯一不变的就是变化，如果能够采用良好的系统架构、设计模式等做到低耦合高内聚，在一定程度上是可以把握变化，拥抱变化的。


常充电；程序员只有一种死法：土死的，IT行业发展本身就比较快，只有不断的学习和尝试新技术、新方法，才能保持职业生命力。


编程之事，隔离是方向，起名是关键，测试是主角，调试是补充，版本控制是后悔药。


控制代码行数；一行代码一个兵，形成建制才能有战斗力。单位规模不宜过大，千人班，万人排易成万人坑。


重构/优化/修复Bug，同时只能作一件；一次只调整一个参数或者一个方向，以观察变化，循序渐进开展工作。


简单模块注意封装，复杂模块注意分层；这个不多说了，大家可以自己去体会。


人脑性能有限，整洁胜于杂乱；读不懂的代码，尝试整理下格式，不好用的接口，尝试重新封装下。


迭代速度决定工作强度；想多快好省，就从简化开发流程，加快迭代速度开始。


忘掉优化写代码；过早优化等同恶意破坏；忘掉代码作优化。优化要基于性能测试，而不是纠结于字里行间。


好记性不如烂笔头；最好的工具是纸笔，其次好的是markdown。


任务拆分要够细；leader问任务时间，若答不上来，可能是任务拆分还不够细。


适当的悲观评估；宁可多算一周，不可少估一天。过于“乐观”容易让boss受惊吓。


会点英文很有必要；最有用的语言是English，其次的可能是Python。


百闻不如一见；多利用建模工具、思维导图画出结果，一目了然。


资源、代码应一道受版本管理；资源匹配错误远比代码匹配错误更难排查。


不要基于想象开发， 要基于原型开发；原型的价值是快速验证想法，帮大家节省时间。


序列化首选明文 ；诸如二进制、混淆、加密、压缩等等有需要时再加。


编译器永远比你懂微观优化；你只能向它不擅长的方向努力。


过细无用；不要定过大、过远、过细的计划，即使定了也没有用，采用精益创业的做法，逐步开展。


重视集成；至少半数时间将花在集成上。时间，时间，时间总是不够。


自省最可靠；与主流意见/方法/风格/习惯相悖时，先检讨自己最可靠。


出现bug主动查，不管是不是你的；这能让你业务能力猛涨、个人形象飙升， 如果你的bug被别人揪出来.....呵呵，那你会很被动～≧﹏≦


不知怎么选技术书时就挑薄的；起码不会太贵，且你能看完，哈哈，不过这样的技术书籍不多。如何选择和阅读技术书籍，可以参考之前的一篇文章「圆桌问答(2017 第三季)」。


Git是最棒的；简单，可靠，免费。


仅对“可预测的非理性”抛断言。


Log日志要精细；Log要写时间与分类。并且要能重定向输出。


注释是稍差的文档；更好的是清晰的命名。让代码讲自己的故事。


知识面要广；造轮子是很好的锻炼方法，前提是你见过别的轮子。


code review最好以小组/结对的形式；对业务有一定了解，建议会更有价值（但不绝对），而且不会成为负担。管理员个人review则很容易成team的瓶颈。


提问前先做调研；问不到点上既被鄙视，又浪费自己的时间。


永远别小看任何一段代码；一段看似简单的代码可能是N个人修改后的最终结果，改动之前确保你看懂了它。