建站技术网专注分享网站建设技术,网站建设教程,真正帮你学会做网站技术,轻松解决网站建设过程中遇到的常见问题,为广大站长服务。 网站地图 | 收藏本站 | 订阅
域名投资,就来找米网,认准网址:www.zhaomi.cc 专业仿站,就到仿站网:www.fangzhan.org
  站内公告: ·帝国cms教程内容已更新,欢迎关注     ·建站技术网采用阿里云服务器,备案已通    
您当前的位置:建站技术网 > 开发语言 > PHP教程

每个程序员都该知道的10大编程格言

时间:2019-09-05 12:00:23  来源:网络收集  整理: 建站技术网 www.jzjsw.com     点击:0次

  每个程序员都该知道的10大编程格言(Kevin Pang):

  编程格言1:无风不起浪 (There is no smoke without fire)

  编程格言2:预防为主,治疗为辅(An ounce of prevention is worth a pound of cure:)

  编程格言3:不要把鸡蛋都放在一个篮子(Don't put all your eggs in one basket)

  编程格言4:种瓜得瓜,种豆得豆(As you sow,so shoul you reap)

  编程格言5:欲速则不达(Great haste makes great waste)

  编程格言6:三思而后行( Look before you leap。Think first, Program later)

  编程格言7:当你仅有的一把工具是锤子,所有的东西看起来都像是钉子(When the only tool you have is a hammer, everything looks like a nail)

  编程格言8:沉默就是赞同 (Silence is construed as approval)

  编程格言9:双鸟在林不如一鸟在手(A bird in the hand is worth two in the bush)

  编程格言10:能力越大责任越大(With great power comes great responsibility)

  1.无风不起浪(There is no smoke without fire):

  设计糟糕的代码通常表现以下 的一些现象:

  巨大的类或者方法

  大区块注释的代码

  重复的逻辑

  过多 if/else 层次嵌套


  Poorly designed code tends to manifest itself through some common tell-tale signs. Some examples of these are:

  Giant classes and/or functions

  Large blocks of commented out code

  Duplicated logic

  Deeply nested if/else blocks

  Developers often refer to these as code smells, but personally, I think the term "code smoke" or "code fumes" is more appropriate as it implies a higher sense of urgency. If you don't address the underlying problem it will come back to burn you later on.

  2. 预防为主,治疗为辅(An ounce of prevention is worth a pound of cure)磨刀不误砍柴工

  程序员经常错误地认为高效率编码就是快速编码,很多程序员不经思索和设计就直接编写代码。很不幸地是,这种 Leeroy Jenkins鲁莽做法将会编写出槽糕的代码,结果导致需要不断维护和修改代码,甚至有可能这些槽糕的代码将会被替换掉。因此,编码效率不仅以编码的时间,而且还有调试代码的时间。

  捡了芝麻丢了西瓜。磨刀不误砍柴工。

  原文:


  Toyota's assembly line of the 1980s was famously efficient due to its revolutionary approach towards defect prevention. Each member of the assembly line was given the ability to halt production when they noticed a problem in their sector. The idea was that it was better to halt production and fix the problem as early on as possible than to continue producing faulty units that would be tougher and more costly to fix/replace/recall later on.

  Developers often make the faulty assumption that productivity = cranking out code quickly. Many programmers dive straight into coding without a second thought towards design. Unfortunately, this Leeroy Jenkins approach towards software development tends to lead to sloppy, fragile code that will need to be constantly monitored and patched — perhaps even replaced altogether down the line. Ultimately, productivity must be measured not only in how much time is spent writing it, but also by how much time is spent debugging it. A short term gain may prove to be a long term loss if one isn't careful.

  3. 不要把所有鸡蛋放在一个篮子 (Don't put all your eggs in one basket)不要过度依赖某个人

  一个软件项目开发团队的公共要素(bus factor)是指那些会影响整个项目进程的核心开发人员的总数。比如某人被车撞了或某人生孩子或某人跳槽了,项目可能就会无序,甚至会搁置。

  换言之,如果团队的关键成员突然流失,项目将会怎么办?业务仍继续还是停止呢?

  因此我们在项目开发中, 每位开发人员最好能最熟悉软件系统非自己所擅长的部分。

  原文:

  A software team's bus factor is defined as "the total number of key developers who would if incapacitated, as by getting hit by a bus, send the project into such disarray that it would not be able to proceed".

  In other words, what happens if you suddenly lost a key member of your team? Would business continue as usual or would it grind to a halt?

  Unfortunately, most software teams fall into the latter category. These are the teams that turn their programmers into "domain experts" who only deal with requests that fall into their area of expertise.. At first, this appears to be a fairly reasonable approach. It works for the automaking assembly lines, why not for software development teams? After all, it's unreasonable to expect each member of the team to be intimately familiar with each and every nuance in the application, right?

  The problem is that developers cannot be easily substituted and replaced. And while the pidgeon-hole approach works fairly well when everybody is available and accounted for, it quickly falls apart when "domain experts" suddenly become unavailable due to turnover, sickness, or even freak bus accidents. It is imperative that software teams have some sort of redundancy built in. Code reviews, pair programming, and communal code go a long way to foster an environment where each developer is at least superficially familiar with parts of the system outside their comfort zone.

  4.种瓜得瓜,种豆得豆 (As you sow, so shall you reap)

  《注重实效的程序员》一书中有这样一段话解释“破窗理论”:

  不要留着“破窗户”(不良的设计、错误的决策或者糟糕的代码)不修。发现一个就修一个。如果没有足够的时间进行适当的修复,就先把它保留起来。或许你可 以把出问题的代码放到注释中,或是显示“未实现”消息,或用虚拟数据加以替代。采取一些措施,防止进一步的恶化。这表明局势尚在掌控之中。

  我们见过整洁良好的系统在出现“破窗”之后立马崩溃。虽然促使软件崩溃的原因还有其他因素(我们将在其他地方接触到),但(对“破窗”)置之不理,肯定会更快地加速系统崩溃。

  简而言之,好的代码会促生好的代码,糟糕的代码也会促生糟糕的代码。别低估了习惯的力量。没人想去整理糟糕的代码,同样没人想把完美的代码弄得一团糟。写好你的代码,它才更可能经得住时间的考验。

  原文:


  The Pragmatic Programmer has this to say about the Broken Window theory:

  Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. Take some action to prevent further damage and to show that you're on top of the situation.

  We've seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we'll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.

  In short, good code begets good code and bad code begets bad code. Do not underestimate the power of inertia. No one wants to be the one who has to clean up sloppy code, but neither does anyone want to be the one that makes a mess out of beautiful code. Write it right and your code will have a far better chance at standing the test of time.

  5 .欲速则不达(Great haste makes great waste)

  经理、客户和程序员正日益变得急躁。一切都需要做的事,都需要马上就做好。正因如此,快速修复问题变得非常急迫。

  没时间对一个新功能进行适当的单元测试?好吧,你可以先完成一次测试运行,然后你就可以随时回来继续测试它。

  当访问Y属性时,会不会碰到奇怪的对象引用错误?无论怎样,把代码放到try/catch语句块中。我们要钓到大鱼啦!

  是不是似曾相识呢?这是因为我们在以前已经都做到了。并且在某些情况下、它是无可非议的。毕竟,我们有最后期限,还得满足客户和经理。但不要过于频繁操 作,否则你会发现你的代码不稳定,有很多热修复、逻辑重复、未测试的方案和错误处理。最后,你要么是把事情草草做完,要么是把事情好好做完。

  原文:

  Managers, clients, and programmers are getting more impatient by the day. Everything needs to be done and it needs to be done now. Because of this, the temptation to throw together hacks and quick-fixes becomes very tough to resist.

  No time to properly unit test a new feature? Oh well, it works for the one test run you put it through. You can always come back to it later!

  Mysterious object referencing error when you try to access property Y? Whatever, just throw a try/catch block around the code. We've got bigger fish to fry!

  Sound familiar? It's because we've all done it at some point in time. And in certain instances, it is justifiable. After all, we have deadlines to meet and clients/managers to satisfy. But do it too often and you'll soon find yourself with a very unstable code base full of hotfixes, duplicated logic, untested solutions, and porous error handling. In the end, you have to strike a balance between getting things done and getting things done right.

  6. 三思而后行( Look before you leap)

  “敏捷开发”这个词最近被频繁滥用,经常被程序员用来掩饰他们在软件开发过程中的糟糕规划/设计阶段。我们是设计者,看到产品朝正当方向有实质进展,我们理应高兴。但意外的是,UML图和用例分析似乎并不能满足我们的愿望。所以,在不知自己做什么的情况下或者不知自己身处何处时,我们开发人员经常就稀里糊涂地写代码了。

  这就好比你要去吃饭,但你根本没有想好去哪里吃。因为你太饿了,所以你迫不及待地找个餐馆,定个桌位。然后你上车开车后沿途在想(找地方吃饭)。只是,这样会耗费更多的时间,因为你要过较多的U型弯道,还在餐馆前停车,也许最后因等待时间过长而不吃了。确切地说,你最后应该能找到地方吃饭,但你可能 吃的饭并不是你想吃的,并且这样花费的时间,可能比你直接在想去的餐馆订餐所花的时间更长。

  原文:

  The term "Agile Development" is used and abused frequently these days, often as a way for programmers to justify ignoring the dreaded planning/designing phase of software development. We are creators, and as such we derive pleasure from seeing actual progress made towards a finished product. Surprisingly, UML diagrams and use case analysis just don't seem to satisfy that desire. So, we developers often start off coding without any idea of what we are doing or where we are going. It's like heading out for dinner when you haven't yet decided where you want to go. You're hungry so you don't want to waste time finding a restaurant and booking a table. Instead, you just hop in your car and figure you'll think of something along the way. Only, it ends up taking you longer because you have to make a bunch of U-turns and stops at restaurants that end up having too long of a wait. True, you'll probably find your way to food eventually, but you probably didn't end up with the meal you wanted and it probably took a lot more time and hassle than it would have had you just called and booked a reservation at a restaurant you wanted to go to.

  7.当你仅有的一把工具是锤子,所有的东西看起来都像是钉子(When the only tool you have is a hammer, everything looks like a nail)

  看见了吧?我早就说过动态记录在这个项目中很有效

  程序员有一种倾向,当一谈到他们工具时,其视野就变狭窄了。一旦某种方法在我们的一个项目上“行得通”,我们就会在接下来所有的项目上都用到它。学习新东 西仿佛是一种煎熬,有时候甚至会心神不定。从始至终都在想“如果我用之前的方法做、这个就不会这么麻烦了”。一定要摒弃这种想法,按我们所知道的去做,即使那不是最完美的解决方法。

  坚持自己所知很简单,不过从长远的角度讲,选择一个适合这项工作的工具要容易得多。否则,就会与你的职业生涯格格不入。

标签:程序员  编程  格言
文章标题:每个程序员都该知道的10大编程格言
文章网址:http://www.jzjsw.com/yuyan/PHP/11498.html
上一篇:php提示undefined index的几种解决方法
下一篇:返回列表
来顶一下
返回首页
返回首页
相关文章
推荐资讯
我是如何通过开源项目月入 10 万的?
我是如何通过开源项目
如何通过SEO优化排名赚钱?SEO赚钱方法
如何通过SEO优化排名赚
seo优化教程:网站seo内容优化
seo优化教程:网站seo
SEO细节:企业SEO如何快速为新站做出效果
SEO细节:企业SEO如何
最新文章
栏目更新
栏目热门