每个时期的经验都是不一样的。孩童时期的编码经历、学生时期的编码经历、CS 研究员时期的编码经历,以及在成长型初创公司时期的编码经历,它们对我来说都是无价之宝。但各个时期的经历都是不一样的。在职业生涯早期,如果你加入了一个优秀的团队,那么在一年内学到的东西要比自己独立工作五年多十倍。如果你的代码没有拿给别人评审,就不会成长得那么快。 所以,导师很重要。加入团队比暂时多赚点钱要重要得多。如果有可能,不要接受那种独立工作的初级职位。在选择第一份工作时,不要只为了钱,加入好团队才是真正有价值的。 职位头衔什么的其实都是浮云。想象一下 5 人团队的 CTO 和 50 人团队或者 500 人团队的 CTO,虽然头衔一样,但它们所要求的工作技能却是完全不同的。所以,我也不会因为被安了“高级开发者”的头衔而变成高级工程师。而且头衔具有“迷惑性”,同样的职位在不同的公司之间也不具备严格的可比性。
很多公司或者初创企业压根就没有测试代码,即使有,数量也很少。为了让产品尽快上市,或者为了生存,很多初创公司忽略了早期的测试。即使是那些看起来挺不错、赞助过开发者大会或开源项目的公司,它们的一些项目也都是只包含少量测试的大单体。 没有一家公司的技术栈是完美的。每一家公司都有自己的问题,都逃不过技术债务,关键在于他们做了哪些事情来解决这些问题。 如果你在某些问题上缺乏实际经验,但又固执己见,这样就显得有点傲慢了。我给人的印象是一个无所不知的人,并坚持一定要写测试代码,但我在这方面其实也没有大量的经验可言。坚持原则固然重要,但也要试着开放心态,并真正从别人的经验和角度来看待问题。
很多大会演讲只涉及概念验证,并不是真实的案例。如果你在某某技术大会上看到某一项很特别的技术,那并不意味着他们公司一定会在日常开发中使用这项技术。通常,演讲者所使用的演示 App 并非真实的案例,所以要注意区分它们。 处理遗留代码是很正常的事情。通常,人们会理所当然地认为别人的公司不需要处理遗留代码。但在技术大会上与那些大公司的人交流过之后,我发现,他们和我们的处境是一样的。有遗留代码是很正常的,相比从头开发 App,学会如何处理好遗留代码将会让你学到更多的东西,因为你会接触到更多你之前没有接触过的概念。
做到足够好就可以了。代码质量“好”到一定程度,它给我们带来的收益是递减的。代码不需要完美,只要维护起来不像是一场灾难就可以了。通常情况下,有点啰嗦的代码读起来反而更容易理解。而且,“好代码”与“它看起来就像是我写出来的代码”是两码事。 看清整体架构比对细节吹毛求疵更重要。少量有问题的代码可以加以改进,而架构方面的问题会导致更大的问题。我想我在一开始就应该更加关注应用程序的整体结构,而不是代码的细节。 代码质量很重要,但请注意,代码质量并不是指我以前所认为的那些东西,比如 linting、格式化,等等。
有时候注释也会撒谎。有人把注释当成了万灵丹。“我们需要注释!”不要因为写注释很难,就认为完全不值得这么去做,我只是认为要用正确的方式给需要注释的地方加上注释。错误的过度注释只会给后面修复代码 bug 的人添加更多的麻烦。 在适当的情况下用自动化代替注释。自动化测试代码通常不太会出现不同步的情况。我开始专注于编写清晰的测试代码,当其他人在阅读我的代码时就可以知道这些代码是干什么用的。
不完美的代码不一定就是技术债务。一些看起来不是那么好的代码并不意味着它就是技术债务。技术债务会以某种形式阻碍项目的进展,或者让你很难对项目做出变更。如果代码有点美中不足,就放过它们吧,花太多时间清理它们可能不值得。 有点技术债务是正常的。有时候我们不得不走捷径,因为时间紧迫。有一点技术债务是没有问题的,只要记得回过头来把这些债务还掉。如果你想让你的项目零技术债务,那么你很可能把代码本身凌驾在交付价值之上。我之前就是这样的!
高级工程师除了编程,还需要发展其他技能。与我已经掌握的技能相比,我还欠缺的技能简直就是一个天文数字。从通信、依赖管理到共享上下文、项目管理、估算,以及与非开发人员合作。这些技能是不太好量化的,所以需要更多的试错才能获得。 不是每个人都能成为“高级开发者”。资历是多年经验积累的结果,但这也只是必要条件,而非充要条件。而且你的经验还得是用得上的,你要把它们内化了,并可以用来解决问题。有时候,一些很重要的经验需要一年甚至更长的时间才能显化出来。 在某些领域,我们仍然很嫩。不管你的经验多么丰富,总有很多东西是你不懂的。承认自己的“无知”是第一步,然后向更有经验的人学习,争取把中间的差距弥补起来。
本版积分规则 发表回复 回帖并转播 回帖后跳转到最后一页
QQ咨询|关于我们|Archiver|手机版|小黑屋|( 辽ICP备15012455号-4 ) Powered by 期权论坛 X3.2 © 2001-2016 期权工具网&期权论坛 Inc.
下载期权论坛手机APP