编程格言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
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)不要过度依赖某个人
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)
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)
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）
See? I told you Active Record would work for this project!
Programmers have a tendency to get tunnel vision when it comes to their tools. Once something “just works” for us on one project, we tend to insist on using it for every project therafter. It can be a pain to learn something new and, at times, highly unsettling. The entire time we’re thinking “it would have been easier had I just done it the old way!”. Enough of these moments and we will simply go with what we know, even if it isn’t a perfect fit for the task.
It’s easy to stick with what you know, but in the long run it’s much easier to pick the right tools for the job. Otherwise you will be fitting square pegs into round holes for the rest of your career.
8. 沉默就是赞同（Silence is construed as approval）
I see nothing! Nuh-thing!
This ties in with the theory on broken windows and programming inertia, only on a larger scale.
The programming community is just that, a community. Each programmer is a reflection on the craft. The more bad code that is released into the wild, the more it becomes the status quo. If you don’t make an effort to write good, clean,SOLID code, you will find yourself having to work with it on a day-to-day basis.
Likewise, if you see poorly designed code written by someone else, you should make the effort to bring it up with the creator. I should note, however, that tact ought to be employed in such a situation. In general, programmers are willing to admit that they do not know everything there is to know about software development and will appreciate the gesture. We all benefit when we help each other out. Turning a blind eye to problems only perpetuates them.
9.双鸟在林不如一鸟在手（A bird in the hand is worth two in the bush）
如果可以讨论系统架构和重构，那么就差找个时间把事情做完。为了使正常运作的东西更加简洁而做改动，权衡改动的利弊很重要。当然了，简洁是一个理想目标， 但总会有可以通过重构改进的代码。在编程世界中，为了代码不过时，会频繁简单改动代码。但有时候你又必须保证代码对客户有价值。那么，你面临一个简单窘 境：你不能一石二鸟。你在重构旧代码上所发时间越多，你编写新代码的时间就越少。在及时改进代码和维护程序之间，也需要找到平衡点。
There is a time and place to discuss system architecture and refactoring opportunities, and a time to just get things done. It is important to weigh the pros and cons of revamping something that already works just to make it cleaner. It’s an admirable goal, of course, but there will always be code that you want to restructure. The programming world simply changes too frequently for code to not get outdated. But at some point you have to provide value to your customers. The simple fact remains: you can’t do two things at once. The more time you spend refactoring old code, the less time you spend creating new code. Striking a balance is critical to enhancing as well as maintaining your application in a timely manner.
10.能力越大责任越大（With great power comes great responsibility）
Software has undoubtedly become an integral and vital part of our lives. Because of this, practicing good software development is more crucial than ever. It’s one thing to have a bug in a game of Pong, it’s another to have one in the guidance system of a space shuttle or air traffic control system. Slashdot recently posted an article describing how a minor glitch in Google News singlehandedly evaporated $1.14 billion in shareholder wealth. Events such as these demonstrate how much power we wield. It’s a little frightening to think that the code you write today, whether you intend it to or not, may one day be recycled and depended upon for mission-critical applications. Write accordingly.
Do you have any proverbs you feel should be added to this list? Feel free to let me know in the comments!