如何做自己的广告网站,网站开发的开题报告模板,如何网站建设网页,肇庆城乡建设门户网站我是一个倾向于生活在规则下的人。 现在#xff0c;这些规则大部分是我本人为自己设立的#xff0c;但它们依然是规则。 我发现为自己创建规则可以让我过得更好#xff0c;因为这样做可以提前决定一些事情#xff0c;而不是要在匆忙中做出所有的决定。 我今天早上应该去健身… 我是一个倾向于生活在规则下的人。 现在这些规则大部分是我本人为自己设立的但它们依然是规则。 我发现为自己创建规则可以让我过得更好因为这样做可以提前决定一些事情而不是要在匆忙中做出所有的决定。 我今天早上应该去健身房吗 我的规则告诉我说我要在周三前往健身房今天是周三因此我要去健身房就这么办了 这周当我正在思考那些对我施加有影响的规则时我想到了去制定一系列软件开发者都应该遵守的规则我认为这可能是一个好主意。 现在我承认这里面的大多数规则比那些“指导方针”要求的要多它们是 1: 技术是用来让你获取解决方案的但它本身并不是解决方案 Technology is how you get to the solution, it is not THE solution. 我们带来了最新的JavaScript框架IoC容器编程语言或者甚至是操作系统但是所有这些并没有实际解决我们作为一个尝试解决问题的程序员的问题取而代之的是更简单的工具帮助我们解决问题。 我们对于特定的技术必须非常谨慎不要太疯狂不是我们碰巧喜欢或者碰巧现在很流行而是要考虑运行他们所带来的风险要思考这个问题是不是就是那个钉子而我们是不是碰巧拿着锤子那么我们就要学习它。 2: 对代码而言“聪明”是“清晰”的敌人 Clever is the enemy of clear. 在写代码的时候我们应努力保持书写的代码清晰易懂。 可以明确Clear表明自身意图的代码永远要比那些晦涩的代码更有价值——无论那些晦涩的代码被构建得多么聪明Clever。 虽然情况并不总是这样但一般来说“聪明”是“清晰”的敌人。 一种经常出现的情况是当我们写出一段“聪明”的代码时这段代码并不是特别的“清晰”。 这条规则非常重要尤其是当我们思考我们要做一些特别“聪明”的事情时。 有时候我们写出了“聪明”的代码它们同时也是清晰的但是其他情况也会时有发生。 如果你对写出简洁的代码感兴趣我高度推荐你用下面这本书上描写的规则来检验Robert C. Martin的《干净的编码者专业程序员的行为守则》The Clean Coder: A Code of Conduct for Professional Programmers 3: 只在逼不得已的情况下才写代码 Only write code if you absolutely have to. 这条可能会有些争议毕竟作为程序员我们的工作不就是写代码吗 嗯。。。这个看你怎么说了。 写代码的确是我们工作的一部分但是我们要尽可能努力的去用最少的代码来解决问题。 所谓“最少的代码”并不是说我们只能用一个字母的变量名或者其它方式来压缩我们的代码。“最少的代码”指的是我们应该只写为了实现功能而必不可少的代码。 我们常常添加一些“酷”的功能来让代码“健壮”和“灵活”让代码能够处理“所有”可能的使用情况。我们企图猜测那些可能会被用到的功能。总之我们常常花费时间去解决一些头脑中臆想出来的可能的情况。 我们这么做是错的。 不能否认这些多余的代码能会带来些好处。然而这些代码同样的会有很多危害。我们写的代码越多就越有可能引入错误我们写的代码越多将来的维护工作就越繁杂。 好的软件工程师只写绝对需要的代码。 伟大的软件工程师会把没用的代码统统都删掉。 4: 注释是魔鬼 Comments are mostly evil. 我并不是很热衷于写注释。当我跟Bob Martin在一起时他说 “你写的每个注释都代表着你表达能力的欠缺“ 《整洁代码敏捷软件艺术手册》 这并不是说一点注释也不写但通常我们可以通过一种更好的方式——命名来避免。 注释仅在命名不能有效表示变量或方法的意图时才真正需要。此时的注释表达了不能用代码表达的真实意图。 例如注释能够告诉你在代码中某些奇怪的操作顺序并不是错误的它是由于底层系统的某一bug而有意为之的。 但通常注释不仅没有必要有时它们还会撒谎。 注释没有随着代码更新的倾向而这是很危险的因为它们会将你带入歧途。 你会检查每条注释和与之对应的代码确保代码是在做注释说的事么如果是的话写注释还有什么用如果不是你怎么相信注释说的是对的 真他妈麻烦所以最好还是尽量别写注释了。 5: 永远要在你开始写代码前考虑好它是做什么的 Always know what your code is supposed to do before you start writing it. 这一条看上去显而易见然而事实并非如此。 想想你有多少次并没有完全想好就坐下来写代码而这段代码确实实现了你要做的功能 比之我乐于承认这个思路的正确性我行动了更多次这是一条我需要经常去品读的规则。 练习测试驱动开发Test Driven DevelopmentTDD在这里会有所帮助因为你在写出代码前必须逐字的了解它们会做些什么但是这依然无法阻止你去做错的事情。因此在构建一个特性或功能前保证自己百分之百地理解需求也是很重要的。 6: 在交付之前测试你的代码 Test your sh—code before you ship it. 别把你的代码直接扔给QA然后指望着所有人来浪费时间为你服务。 事实上你自己认真的运行一下测试案例是完成代码之前必不可少的一步。 这并不是说一定让你自己找到代码中所有的问题但是你至少得把那些愚蠢得令人尴尬的错误找出来吧 很多软件工程师都觉得测试代码是QA的工作。这个想法绝对是大错特错。保证代码的质量是每个人的工作 7: 每天学点新东西 Learn something new every day. 如果你每天都不学新知识你就在退步因为我可以保证你会忘记一些东西。 每天学一些新东西并不会花去你太多的时间。 试着花15分钟去读一本书——我去年读了一大堆书平均每天要花45分钟在阅读上。 每天的小进步随着时间的推移会积少成多并在很大程度上重塑你的未来。如果你想在未来获取回报你现在就需要开始投资了。 此外今天的技术变化非常之快如果你不能做到不断提高已有技能并学会新的技能你会很快掉队。 8: 写代码是件快乐的事 Writing code is fun. 诚然你最开始进入这个行业可能只是因为它待遇优厚。 我是说为了良好的待遇找工作没有任何错误但是医生或律师可能会是更好的选择。 你之所以成为了一名软件开发人员是因为你爱写代码。因此不要忘记你在做你所热爱的事情。 写代码有很多乐趣我希望我能写更多的代码。 我这几天经常忙于写代码并试图让它占据我更多的时间这也是我为什么如此清晰地记得它有多么的有趣。 也许你已经忘记了写代码的乐趣也许是时候你应该再次记起写代码是多么的有趣了——通过开始一个边角的项目或是仅仅改变你的心态意识到你开始写代码了并为之付出。但愿如此 9: 你无法完全了解它 You can’t know it all. 无论你学了多少知识都会有大量你所不知道的东西。 认识这一点非常重要因为你可以驾驭你的那些想要去学会所有东西的发狂的想法。 没能获取所有问题的答案这挺好的。 在自己不理解某事时寻求帮助或说出来这也挺好的。 在很多情况下你可以相当接近地了解到你想知道的事情——相信我我一直在这样做。 我的观点是不要总想着学会一切——如果这是个不可能完成的任务。相反你应该重点学习那些你需要去知道的东西并且提升那些可以让自己学习速度加快的能力。 10: 最佳实践要因地制宜 Best practices are context dependent. 测试驱动开发是你最拿手的编程方式么? 我们应该一直采用结对编程? 不使用IOC容器你就不好编了? 这些问题的答案是“看情况吧”。 具体情况具体分析。 人们会将所谓的“最佳实践”强推给你并且他们经常说这些很实用——你应该经常这样做或那样做——但这是不对的。 当我写代码时我会遵循很多”最佳实践“但有时我也会背离它们。 原则是永恒的最佳实践是变通的。 11: 力求精简 Always strive to simplify. 所有问题都可以进行分解。 最佳的解决方案往往是最简单的。 但简单并不容易简化事情需要付出努力。 本文目的在于简化复杂的软件开发和人生。 相信我这并不容易。 傻瓜为问题提出复杂的解决方案。简化解决方案需要更多的精力和耐心但这没有错。 花点时间。多点努力。力求精简。 你遵守什么规则 上面是我遵守的规则那你呢 你个人遵守什么规则 你认为什么是应该天天都记住的转载于:https://www.cnblogs.com/idmask/p/4708077.html
