My guiding principles after 9 of JavaScript development

栏目: IT技术 · 发布时间: 4年前

内容简介:I’m don’t claim to be an authority in software development. These are just the wisdom I earned along the way. I’m sure this list will be more mature after another 20 years.Do you have any tips or wisdom you’d like to share? I really appreciate a comment he

My guiding principles after 20 years of programming

Jan 22 ·4min read

I’ve been programming since 1999. This year I’ve officially coded for 20+ years. I’ve started with Basic but soon jumped into Pascal and C and then Delphi and C++. Then I moved to Java for 4 years before working with JavaScript for the last 9 years. I’ve worked with a wide range of businesses from robotics, fin tech, med tech to media and telecom. Sometimes I had a different hat as a researcher, TPM (technical project manager), teacher, system architect or TL (technical leader) but I’ve always been coding even for fun. I’ve worked on some products that served millions of people, and some that failed before being released. I even had my own startup. I have spent lots of time on open source projects, closed source projects and internally open source projects. I’ve worked with tiny microcontrollers all the way to mobile and desktop apps to cloud servers and lately serverless.

For my 20 years programming anniversary, I tried to list the top principles that I’ve learned over the years and have been guiding me through my career:

  1. Don’t fight the tools: libraries, language, platform, etc. Use as much native constructs as possible. Don’tbend the technology, but don’t bend the problem either. Pick the right tool for the job or you’ll have to find the right job for the tool you got.
  2. You don’t write the code for the machines, you write it for your colleagues and your future self (unless it’s a throw away project or you’re writing assembly). Write it for the junior ones as a reference.
  3. Any significant piece of software is the result of collaboration. Communicate effectively and collaborate openly. Trust others and earn their trust.
  4. Divide and conquer. Write isolated modules with separate concerns which are loosely coupled. Test each part separately and together. Keep the tests close to reality but test the edge cases too.
  5. Deprecate yourself. Don’t be the go-to person for the code. Optimize it for people to find their way fixing bugs and adding features to the code. Free yourself to move on to the next project/company. Don’t own the code or you’ll never grow beyond that.
  6. Anything significant is done by a team. Respect people more than code. Lead by example. Convert your followers to leaders.
  7. Realize that every code has a life cycle and will die. Sometimes it dies in its infancy before seeing the light of production. Be OK with letting go.
  8. Don’t attach your identity to your code. Don’t attach anyone’s identity to their code. Realize that people are separate from the artifacts they produce. Don’t take code criticism personally but be very careful when criticizing others’ code.
  9. Tech debt is like fast food. Occasionally it’s good but if you get used to it, it’ll kill the product faster than you think.
  10. When making decisions about the code always keep this priority in mind:
    Security > Usability (UX) > Maintainability > Simplicity (DX) > Brevity (code length) > Performance
  11. Bugs’ genitals is called copy & paste . That’s how they reproduce. Always read what you copy, always audit what you import. Bugs take shelter in complexity . “Magic” is fine in my dependency but not in my code.
  12. Don’t only write code for the happy scenario. Writegood errors that answer why it happened, how it was detected and what can be done to resolve it.
  13. Don’t use dependencies unless the cost of importing, maintaining, dealing with their edge cases and refactoring when they don’t satisfy the needs is significantly less than code that you own.
  14. Stay clear from hype-driven development . But learn all you can. Always have pet projects .
  15. Get out of your comfort zone. Learn every day. Teach what you learn. If you’re the master, you’re not learning. Expose yourself to other languages, technologies, culture and stay curious.
  16. Good code doesn’t need documentation, great code is well documented so that anyone who hasn’t been part of the evolution, trial & error process and requirements that led to the current status can be productive with it. An undocumented feature is a non-existing feature. A non-existing feature shouldn’t have code.
  17. Avoid overriding, inheritance and implicit smartness as much as possible. Write pure functions. They are easier to test and reason about. Any function that’s not pure should be a class. Any code construct that has a different function, should have a different name.
  18. Never start coding (making a solution) unless you fully understand the problem . It’s very normal to spend more time listening and reading than typing code. Understand the domain before starting to code.
  19. Never solve a problem that doesn’t exist. Don’t do speculative programming .
  20. Software is more fun when it’s made together. Build a sustainable community . Listen. Inspire. Learn. Share.

I’m don’t claim to be an authority in software development. These are just the wisdom I earned along the way. I’m sure this list will be more mature after another 20 years.

Do you have any tips or wisdom you’d like to share? I really appreciate a comment here or on Twitter or on Reddit .


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

零基础学Minecraft编程

零基础学Minecraft编程

Martin O''Hanlon、David Whale / 中文Minecraft Wiki翻译团队 / 人民邮电出版社 / 2015-9-7 / 79

在你体验Minecraft冒险的同时,学习宝贵的编程技能! 如果你很喜欢玩Minecraft,却被游戏中的建造耗费大量时间而困扰,并且你想要对游戏添加一些改动,那么本书就是为你而设计的。在游戏中,你可以学习许多Python编程技能,在PC、Mac或树莓派上与游戏进行互动。这些冒险不仅局限在虚拟世界——你也将会学习如何将Minecraft与电子元件连接起来,这样你的Minecraft世界就能够......一起来看看 《零基础学Minecraft编程》 这本书的介绍吧!

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

URL 编码/解码
URL 编码/解码

URL 编码/解码

XML、JSON 在线转换
XML、JSON 在线转换

在线XML、JSON转换工具