[翻译]On the road to being a better developer
[翻译]On the road to being a better developer
原文地址:http://blog.mostof.it/being-a-better-developer
每个人都想在其所在的岗位上做的出色,这是人类的本性,这就是为什么我们会成长. 关键是持续不断的提升,不因小的失败和过程中的起起落落而失望. 在过去的10年中,我作为一个开发者,我认为我已经学到很多有价值的经验,许多是可以应用到生活和工作的其他领域. 现在我将与你分享我的经验.
以下没有特定的顺序:
Lesson #1-See the big picture(关注大局)
在细节上容易迷失方向,专注于小事而丢掉了重点和方向. 整体总是超出它的所有部分的总和. 即使你是个刚入行的程序员,尽量关注项目的其他方面,如,商业,沟通,尽可能的多的方面. 当你把这个工作作为你的专业时,编码是欧莱雅艺术而艺术不再欧莱雅 – 它有一个理由,一个目标。我们的目标绝对不是’完成编码任务’. 它是和在敏捷开发中的”done done”的概念是同一个事情,即:一个项目只有经过了测试,被人认可,健康的,再经过压力测试和回归测试后才算完结. 最后的测试应该较少的注重技术方面,而应该把更多的精力关注与操作,利益,品牌建设和客户满意度. 在这样的方式下获得成功,你的视野中必须始终拥有项目的全局目标.
Lesson #2-Take your time(慢慢来)
这听起来是容易,自然的,但是这通常是很困难的,当deadline逼近的时候. 不要追求速度,速度会带来重点的丢失和疏忽,制造bugs. 在后期你要花费大量的时间,精力及情绪. 速度自然而然的来自于好的设计和架构的选择及解决方案,另外加上经验和熟练程度. 这些事你不可能在匆忙中得到. 请注意,它已无关懒惰或者挑灯夜战,那些都是坏习惯.
Lesson #3-When things go wrong, be ready for a paradigm shift(当出乱子的时候,做好转变的准备)
这也需要时间和经验,但这是宝贵的东西. 当目前的技术和方案变得缓慢或不可用时,你应该停止用旧的方式解决新问题,应该寻找替代方案. 近期的NoSql运动就是这样一个例子(什么是NoSql?如:google的bigtable, apache的hadoop). 但是当旧的方案被证明还是有用的时候,不要用目前炒作的,流行的lib或软件. 假如你的好的旧的关系型数据可以很好解决你的问题,那么就没有理由使用NoSql服务. 同样的对于函数式语言,如果只是因为你可以有一个更完美的解决方案的话,就不要在你的代码库里引入新的语言. 从另一面来说,你的面向对象的方式不能自然的,不能有效的解决你的问题,那么去找一个功能性的方法. 为此,保持对新趋势的了解,阅读一些新技术的文章,至少每周一次.
Lesson #4-Keep your brain trained(保持大脑思维能力)
不要满足于日常的工作,做一些额外的训练. 可以到codegolf或Eler项目的网站上找一些问题,想出尽可能多的解决方案,然后比较他们. 也可以练习算术,特别是状态,图形和集合的理论. 当你遇到一些复杂的算法问题,他们可以真正拯救你. 作为一个开发者不要在下班后就停止与其相关的事- 这是一种生活方式. 很多好的点子往往是从生活中来的.
Lesson #5-Have/get a life(享受生活)
这可能是最重要的. 年青的爱好者看起来像编码的神(指他们精力充沛),但是火可以快速烧尽. 如果没有适当的休息和意志,你不可能长期从事此职业. 在做好本职工作的情况下尽量少加班,与项目管理者适当的搞好关系, 可以适当的规划. 睡觉,睡觉,睡觉. 有些时候通宵一两个晚上是必然的, 但要小心因为这容易形成一种模式-你的大脑需要休息. 即使睡眠减少你也不会得到更多. 多与人交往,拥有家庭和朋友可以得到更多的快乐, 你的大脑也需要各样的思考.
Lesson #6-Focus(专注)
同一个时间专注于一个事情(不能丢了大局). 尽可能的避免多工作业. 有些时候,在你的工作环境下,单工作业是不大可能的,多个任务在你的大脑中有同样的权重,如同在并发编程中:任务的切换对大脑也是相当堵塞乏味. 你失去了专注点和灵感,并且需要花很多时间去找回他们.
Lesson #7-Be persistent(坚持)
在失败的时候不要放弃. 不断尝试. 你会在你的错误中学到更多,而不是在你的成功故事里. 假如经历了很多次失败后,可以尝试其他的方式解决问题,这和Lesson 3有点关联. 相信我,在大多数的情况下你花了时间就可以找到正确的方法. 不要害怕或者羞于向别人请教-一个新人看待一个问题如同在做奇迹,而老人则不然.
Lesson #8-Measure(衡量)
衡量你可能衡量的任何事情. 不要只”想着”你的方案是最好的. 不要假设,不要太自我. 哪个色彩方案能够吸引更多的用户注册呢?做一下A/B测试,你就会知道. 人类的判断和预测是不准的. 有时候你会对估计和实际的巨大偏差感到惊奇.
Lesson #9-Don’t focus on code performance(不要专注于代码性能)
大多数的情况下,这是不着边际的. 不要花两天或更多的时间优化一个页面的性能,从加载一次550ms变成500ms. 这是不值得的. 你的用户感受不到这样的差异,而你却浪费了宝贵的时间,你应该接着做下一件事. 事实上代码中有些更为重要的因素如:清晰,简单,优雅.
Lesson #10-Be ready to chop off features(准备好砍掉功能)
有些时候,你肯定无法在指定的时间内完成任务. 那么就要准备作出一些牺牲,根据重要性原则重排你的功能,至少砍掉一个重要功能. 然后你可以重新安排时间,完成剩余的功能. 不要认为做不到. 我们的工作就是这样.
Lesson #11-Have ‘coding standards’(编码规范)
即使你不在一个团队中,也要尽量的保持一致. 虽然编码规范是一个可以并且需要发展的标准列表,然而还是一直要尽量的保持一致. 这可以为你和你的团队节省很多时间.
Lesson #12-Test(测试)
要把测试当然工作和计划的一部分,而不是那些乏味的额外工作. 花一些时间做一些适当的测试. 在多个层测试(如:数据层,商业逻辑层,表现层). 坚持不断的做测试,但更重要的是做单元测试. 很多人从事测试. 手头也有很多测试工具-测试服务器,测试软件,如:RSpec,Cucumber,PhpUnit等等.
Lesson #13-Usability(可用性)
当你在做UI的开发的时候,最重要的原则是保持可用性. 这是困难的,我们都有这样的意识,但是作为一个开发者永远不可能和真实的使用者理解一致. 这是事实,做一些实物模式,设计图展示给更多的人,特别是你的最终用户. 接受批评,这是过程的一部分,而不是对你的羞辱.