库克的格言随意收集……

The hardest language to learn is your second. The hardest OS to learn is your second one - especially if your first was an IBM mainframe. Once you've learned several seemingly different languages, you finally realize that all programming languages are the same - just minor differences in syntax. Although one can be quite productive and marketable without having learned any assembly, no one will ever have a visceral understanding of computing without it. Debuggers are the final refuge for programmers who don't really know what they're doing in the first place. No OS will ever be stable if it doesn't make use of hardware memory management. Low level systems programming is much, much easier than applications programming. The programmer who has a favorite language is just playing. Write the User's Guide FIRST! Policy and procedure are intended for those who lack the initiative to perform otherwise. (The Contractor's Creed): Tell'em what they need. Give'em what they want. Make sure the check clears. If you don't find programming fun, get out of it or accept that although you may make a living at it, you'll never be more than average. Just as the old farts have to learn the .NET method names, you'll have to learn the library calls. But there's nothing new there. The life of a programmer is one of constantly adapting to different environments, and the more tools you have hung on your belt, the more versatile and marketable you'll be. You may piddle around a bit with little code chunks near the beginning to try out some ideas, but, in general, one doesn't start coding in earnest until you KNOW how the whole program or app is going to be layed out, and you KNOW that the whole thing is going to work EXACTLY as advertised. For most projects with at least some degree of complexity, I generally end up spending 60 to 70 percent of the time up front just percolating ideas. Understand that programming has little to do with language and everything to do with algorithm. All of those nifty geegaws with memorable acronyms that folks have come up with over the years are just different ways of skinning the implementation cat. When you strip away all the OOPiness, RADology, Development Methodology 37, and Best Practice 42, you still have to deal with the basic building blocks of: assignments conditionals iterations control flow I/O

一旦你能真正地把自己包围起来，你最终会到达你想要的那个点 看(从编程的角度来看)编写库存应用程序之间的差别很小 一个汽车零部件公司，一个图形实时TCP性能分析仪，一个数学模型 一个恒星核心，或者一个约会日历。

初级程序员处理小块代码。随着经验的积累， 他们处理越来越大的代码块。 随着经验的增加，他们开始处理小块代码。

如果开发人员写不出清晰、简洁、语法正确的注释，那么他们就应该回去补习英语。

我们有开发人员和(可怕的)架构师不能连贯地编写。当他们的文件被审查时，他们会说“哦，不要担心语法错误或拼写错误——那不重要”。然后他们想知道为什么他们复杂的垃圾文档变成了复杂的bug代码。

我告诉我所指导的实习生，如果你不能口头或书面表达你的伟大想法，那就不如没有它们。

只有一种设计模式:封装

例如:

工厂方法:您已经封装了对象创建 策略:封装了不同的可变算法 迭代器:您封装了按顺序访问集合中的元素的方法。

异常应该只在真正异常的情况下使用

在我最近参与的项目中，异常的使用似乎非常猖獗。

这里有一个例子:

我们有拦截网络请求的过滤器。筛选器调用筛选器，筛选器的任务是检查请求是否具有某些输入参数并验证这些参数。你设置了要检查的字段，并且抽象类确保参数不为空，然后调用一个由你的特定类实现的screen()方法来进行更多的扩展验证:

public boolean processScreener(HttpServletRequest req, HttpServletResponse resp, FilterConfig filterConfig) throws Exception{           
            // 
            if (!checkFieldExistence(req)){
                    return false;
            }
            return screen(req,resp,filterConfig);
    }

checkFieldExistance(req)方法从不返回false。如果所有字段都不缺少，则返回true，如果缺少字段则抛出异常。

我知道这是一种糟糕的设计，但部分问题在于，这里的一些架构师认为，每次遇到意外情况时都需要抛出异常。

此外，我知道checkFieldExistance(req)的签名确实抛出了一个异常，这只是我们几乎所有的方法都这样做-所以我没有想到这个方法可能会抛出一个异常而不是返回false。直到我翻遍代码才发现。

如果语言已经公开了实际类型，就不要为基本类型使用关键字。在c#中，这将指bool (Boolean)， int (Int32)， float (Single)， long (Int64)。'int'， 'bool'等不是语言的实际部分，而只是实际类型的'快捷方式'或'别名'。不要使用不存在的东西!在我看来，Int16, Int32, Int64，布尔值等比'short'， 'long'， 'int'更有意义。

代码即设计:Jack W. Reeves的三篇文章

任何软件的源代码都是其最准确的设计文档。其他的一切(规格，文档，有时还有注释)要么是不正确的，过时的，要么是误导性的。

肯定会让你在任何地方被炒。