截止现在我工作6年多了, 目前是一个开发团队的leader, 但主要精力仍然是开发, 随着编写程序经验的积累, 慢慢有了些以前不曾有过的感觉.
写程序不只是技术, 还是一项艺术. 写程序是一项纯粹的脑力劳动, 而且有时候挺伤脑细胞的, 业余时间还要学习各类新老技术, 一不留神就落伍了, 这行当真的不容易, 所以很多程序员的沟通能力表达能力都比较欠缺, 因为大量的时间是在对着屏幕写代码, 或者思考下一步怎么写, 怎么写得更好, 更健壮, 怎么利用上更好的技术, 怎么把空间时间的利用做到最优化等等. 有时一坐就是几个小时不动, 啊, 话题扯得有点偏离主题了. 好的程序需要程序员日积月累的技术积累, 高智商的计算机天才们在这一领域如鱼得水, 但这类人毕竟是少数, 大多数程序员还是普通人, 我们不但要靠勤奋学习技术, 我个人觉得还有一项特质需要在日常工作中有意识地去加强, 就是把程序写得美一点, 我这里说的美其实并不需要高智商, 是可以养成的好习惯, 起码下面两个好习惯要有吧:
1. 清晰简洁的模块接口. 工作中可能每个程序员都会遇到写一个独立的模块, 供别人调用这类活儿, 那么你需要站在系统的角度去思考一下你的这个模块在整个系统中处于什么位置, 扮演什么角色, 需要提供什么服务,需要引入什么服务, 会受到什么制约等等多种因素, 总之, 你要理清你的模块的上下文环境, 然后才开始设计, 不要盲目开始写, 只有弄清楚了头绪后才有可能写出优美健壮的代码. 既然是模块, 那么一定有供外部调用的接口, 弄清楚你的模块提供什么服务, 针对这些服务提供对外接口, 不提供的服务不要提供对外接口, 让对外接口清晰简洁, 不要和其他模块耦合, 不要依赖高层模块, 只依赖低层的模块, 时常想想, 如果把这个模块拿到其他项目, 能不做改动就能用吗, 如果能那就是一个封装良好的模块, 否则, 这个模块必然耦合了其他模块的逻辑. 这类模块以后的维护必将给你和别人带来很多痛苦.
2. 适当的注释. 我经常给手下人强调注释, 这个习惯必须得养成, 想一下, 如果某个几乎没有注释的模块时隔两年突然出现了需要修改的地方, 这时有两种情况, 第一, 模块的作者还在职, 当然会让他去改, 但由于时间太久没有看里面的逻辑, 很多细节都无法记得当时的算法逻辑, 甚至里面有很多隐形的约定, 这时让他改, 他可能需要重新理顺当时的逻辑, 不但成本高, 自己也烦恼. 第二种情况, 原作者已经离职, 这时只能劳驾其他人, 情况比第一种更恐怖, 如果模块内部逻辑稍微复杂一点, 那么他可能将花费几倍于原作者的精力去理顺, 并且由于不同的人的思考习惯总是不同的, 很有可能再改出bug....头要爆炸了. 如果有良好的注释, 把一些不太容易想到的, 或者有特俗考虑的代码行写出说明性的文字, 会给以后的维护带来极大的帮助, 我深有体会.
还有一个体会就是, 要学会站在产品经理的立场写程序. 程序员容易陷入技术深井, 不可自拔, 并且由于只关注技术层面, 忽视了其他层面, 比如, 从整个产品的视角来衡量一个技术方案. 有时候我们对技术要求太过于完美, 必须追求最好的实现方案, 实际上, 这个世界上大部分软件的大部分模块都不需要太复杂高深的技术, 从更高的公司战略来看, 公司似乎对于产品具体用了什么技术方案不太关心, 只要能满足产品的要求, 只要能带来用户, 实现赢利, 更好的技术架构可以延后, 甚至取消, 因为很多时候, 占据这个市场上最前面的产品真的不是技术最好的, 腾讯缺技术吗, 为什么搜索做不起来? 百度缺技术吗, 为什么做不出微博, 微信这样的移动互联网领域的杀手锏产品, 很多东西不是技术决定的, 很多时候我们需要跳出技术的小圈圈, 跳上一个更高的台阶去思考一个产品, 一项解决方案. 当然了, 如果公司允许, 成本在预算之内, 更好的技术肯定是好事. 但技术绝对不是一切, 有时候甚至只是一小部分. 所以, 我们写代码的时候, 需要刻意让自己跳出程序员的小圈, 用更为全局的眼光去审视你正在做的产品, 这对你自己的成长, 对公司的成长都是绝对的负责任行为. 举一个具体的例子, 加入产品经理让你实现一个功能需求, 这个需求实现起来很困难, 但你分析了一下觉得花点精力能实现, 由于他没有技术基础, 他的要求可能完全是出自他的想法, 但并不是唯一的不可协商的方案, 但你缺认为产品经理非要这样实现不可, 于是乎, 你不假思索地答应下来, 废了九牛二虎之力实现了, 并且自己很有成就感, 没想到, 过了几天产品经理突然说又不想那样实现了(因为他的方案真的有很多种选择), 这时你傻眼了. 其实如果你在接到需求时认真分析一下产品经理的出发点, 和他商讨一下, 很有可能讨论的过程中他就改变了想法, 换了一个你实现起来很容易的解决方案, 并且这个方案不但技术简单, 可能体验上也更完美. 这就是你多思考一步的结果.
写程序不只是技术, 还是一项艺术. 写程序是一项纯粹的脑力劳动, 而且有时候挺伤脑细胞的, 业余时间还要学习各类新老技术, 一不留神就落伍了, 这行当真的不容易, 所以很多程序员的沟通能力表达能力都比较欠缺, 因为大量的时间是在对着屏幕写代码, 或者思考下一步怎么写, 怎么写得更好, 更健壮, 怎么利用上更好的技术, 怎么把空间时间的利用做到最优化等等. 有时一坐就是几个小时不动, 啊, 话题扯得有点偏离主题了. 好的程序需要程序员日积月累的技术积累, 高智商的计算机天才们在这一领域如鱼得水, 但这类人毕竟是少数, 大多数程序员还是普通人, 我们不但要靠勤奋学习技术, 我个人觉得还有一项特质需要在日常工作中有意识地去加强, 就是把程序写得美一点, 我这里说的美其实并不需要高智商, 是可以养成的好习惯, 起码下面两个好习惯要有吧:
1. 清晰简洁的模块接口. 工作中可能每个程序员都会遇到写一个独立的模块, 供别人调用这类活儿, 那么你需要站在系统的角度去思考一下你的这个模块在整个系统中处于什么位置, 扮演什么角色, 需要提供什么服务,需要引入什么服务, 会受到什么制约等等多种因素, 总之, 你要理清你的模块的上下文环境, 然后才开始设计, 不要盲目开始写, 只有弄清楚了头绪后才有可能写出优美健壮的代码. 既然是模块, 那么一定有供外部调用的接口, 弄清楚你的模块提供什么服务, 针对这些服务提供对外接口, 不提供的服务不要提供对外接口, 让对外接口清晰简洁, 不要和其他模块耦合, 不要依赖高层模块, 只依赖低层的模块, 时常想想, 如果把这个模块拿到其他项目, 能不做改动就能用吗, 如果能那就是一个封装良好的模块, 否则, 这个模块必然耦合了其他模块的逻辑. 这类模块以后的维护必将给你和别人带来很多痛苦.
2. 适当的注释. 我经常给手下人强调注释, 这个习惯必须得养成, 想一下, 如果某个几乎没有注释的模块时隔两年突然出现了需要修改的地方, 这时有两种情况, 第一, 模块的作者还在职, 当然会让他去改, 但由于时间太久没有看里面的逻辑, 很多细节都无法记得当时的算法逻辑, 甚至里面有很多隐形的约定, 这时让他改, 他可能需要重新理顺当时的逻辑, 不但成本高, 自己也烦恼. 第二种情况, 原作者已经离职, 这时只能劳驾其他人, 情况比第一种更恐怖, 如果模块内部逻辑稍微复杂一点, 那么他可能将花费几倍于原作者的精力去理顺, 并且由于不同的人的思考习惯总是不同的, 很有可能再改出bug....头要爆炸了. 如果有良好的注释, 把一些不太容易想到的, 或者有特俗考虑的代码行写出说明性的文字, 会给以后的维护带来极大的帮助, 我深有体会.
还有一个体会就是, 要学会站在产品经理的立场写程序. 程序员容易陷入技术深井, 不可自拔, 并且由于只关注技术层面, 忽视了其他层面, 比如, 从整个产品的视角来衡量一个技术方案. 有时候我们对技术要求太过于完美, 必须追求最好的实现方案, 实际上, 这个世界上大部分软件的大部分模块都不需要太复杂高深的技术, 从更高的公司战略来看, 公司似乎对于产品具体用了什么技术方案不太关心, 只要能满足产品的要求, 只要能带来用户, 实现赢利, 更好的技术架构可以延后, 甚至取消, 因为很多时候, 占据这个市场上最前面的产品真的不是技术最好的, 腾讯缺技术吗, 为什么搜索做不起来? 百度缺技术吗, 为什么做不出微博, 微信这样的移动互联网领域的杀手锏产品, 很多东西不是技术决定的, 很多时候我们需要跳出技术的小圈圈, 跳上一个更高的台阶去思考一个产品, 一项解决方案. 当然了, 如果公司允许, 成本在预算之内, 更好的技术肯定是好事. 但技术绝对不是一切, 有时候甚至只是一小部分. 所以, 我们写代码的时候, 需要刻意让自己跳出程序员的小圈, 用更为全局的眼光去审视你正在做的产品, 这对你自己的成长, 对公司的成长都是绝对的负责任行为. 举一个具体的例子, 加入产品经理让你实现一个功能需求, 这个需求实现起来很困难, 但你分析了一下觉得花点精力能实现, 由于他没有技术基础, 他的要求可能完全是出自他的想法, 但并不是唯一的不可协商的方案, 但你缺认为产品经理非要这样实现不可, 于是乎, 你不假思索地答应下来, 废了九牛二虎之力实现了, 并且自己很有成就感, 没想到, 过了几天产品经理突然说又不想那样实现了(因为他的方案真的有很多种选择), 这时你傻眼了. 其实如果你在接到需求时认真分析一下产品经理的出发点, 和他商讨一下, 很有可能讨论的过程中他就改变了想法, 换了一个你实现起来很容易的解决方案, 并且这个方案不但技术简单, 可能体验上也更完美. 这就是你多思考一步的结果.