是一段关于“程序员，你累吗？”的回复

苏飞

如何成为优秀的程序员?

1）学习应该从基础打起，不要一开始就尝试最高深的技术。

2）每看一本书，不要说这章我以前学习过了，也掌握的很好，因此我可以跳过这一章看
更重要的了。

3）对于作业，遇到不会的尽量不要立刻向别人请教。如果实在解决不了的问题，可以先
完成你会的，然后把一些特别的难点提炼出来，向高手请教。

3）不要指望书本和行家能帮你解决一切问题，因为并不是所有问题都能由别人教给你。

4）向别人请教问题应该把问题说明白。对于错误提示信息应该原样提供出来，不要按自
己理解的信息提供。因为既然你自己做不了，说明你理解一般都有问题。

5）问问题最好能带代码。

6）不要说“编译通过，可是运行时..."，因为编译错误和运行错误可能根本没有关系。
一般来说，编译是语法问题，而运行是逻辑问题。

7) 书看千遍不如做程序一遍，应该尽量尝试去写程序。

8）做程序千个不如做好程序一个。应该尽量完善你现在做的程序，而不要不断开新的计
划，而每个计划都虎头蛇尾。

9）要想到你不是一个人写程序，而是和大家一起写程序。

10）高深的技巧虽然显示了高深的本领，但是对于合作往往是有害的，应该尽量写出简
单易读的代码。

11）编制程序应该尽量做到自注释，即代码本身一读就懂，好象自己在说明自己的逻辑
一样。

12）复杂的代码如果实在做不到自注释，应该给出适量的注释。

13）注释在修改代码的时候应该相应修改，不能用陈旧的注释去误导别人。

14)代码应该尽量可重用，相同功能的代码应该由相同的函数完成，重要函数应该给出调
试信息，以便调试时及早发现问题。

15）应该尽量写小函数，每个函数尽量不要超过40行或者更少。这样不用滚动屏幕也许
就可以读完整个函数。

16）对于switch语句，尽量不要有过多的分支，如果分支太多，可以考虑用跳转表。

17）尽量少使用一些有争议的语句，如goto和三目运算符，既然有争议，它肯定有一定
的缺点。

18）对于goto，许多工程师技术高到可以合理使用，而不至于导致问题。但是你的程序
并不一定给你同水平的人看和修改，他们可不能保证合理的读和修改这些相关代码。

19)代码编写时应该有一定的格式，其基本要求是对理解代码有一定帮助。

20）如果数据是多个模块共有的，应该提供一个封装的类来管理它，并提供一个合适的
接口给各个模块。这样，如果数据内容有重大修改，则只要接口不变，基本上可以保证
程序不要很复杂的修改。

21）应该尽量考虑到数据的并发控制。

22）数据的并发控制应该封装在接口内，而不要暴露给其他模块，这样可以减少因为并
发原因导致的程序死锁。

23）数据本身结构不可以太复杂。应该尽量把不相关的数据分割成为两组数据。

24）对于数据量比较大的情况，应该考虑数据库。

25）数据库接口应该采用标准ODBC或者ADO接口，尽量不要根据实际数据库DBMS提供的接
口来处理，因为你可能在实际使用中更换DBMS。

26）小的数据可以考虑文件，文件路径应该必须设计成相对路径。

27）在一个函数中，应该尽量打开文件后使用完后立刻关闭，这样其他程序可能使用文
件。

28）不要尝试把文件全部读到内存中，应该分次处理大文件。

29）编写程序应该提供相关的测试程序，以提供测试手段。

30）应该考虑代码、函数的使用情况，不要超越函数可以使用的范围使用之。


--------------------------------------------------------------------------------


　　1. 扎实的基础。数据结构、离散数学、编译原理，这些是所有计算机科学的基础，
如果不掌握他们，很难写出高水平的程序。据我的观察，学计算机专业的人比学其他专
业的人更能写出高质量的软件。程序人人都会写，但当你发现写到一定程度很难再提高
的时候，就应该想想是不是要回过头来学学这些最基本的理论。不要一开始就去学OOP，
即使你再精通OOP，遇到一些基本算法的时候可能也会束手无策。

　　2. 丰富的想象力。不要拘泥于固定的思维方式，遇到问题的时候要多想几种解决问
题的方案，试试别人从没想过的方法。丰富的想象力是建立在丰富的知识的基础上，除
计算机以外，多涉猎其他的学科，比如天文、物理、数学等等。另外，多看科幻电影也
是一个很好的途径。

　　3. 最简单的是最好的。这也许是所有科学都遵循的一条准则，如此复杂的质能互换
原理在爱因斯坦眼里不过是一个简单得不能再简单的公式：E=mc2。简单的方法更容易被
人理解，更容易实现，也更容易维护。遇到问题时要优先考虑最简单的方案，只有简单
方案不能满足要求时再考虑复杂的方案。

　　4. 不钻牛角尖。当你遇到障碍的时候，不妨暂时远离电脑，看看窗外的风景，听听
轻音乐，和朋友聊聊天。当我遇到难题的时候会去玩游戏，而且是那种极暴力的打斗类
游戏，当负责游戏的那部分大脑细胞极度亢奋的时候，负责编程的那部分大脑细胞就得
到了充分的休息。当重新开始工作的时候，我会发现那些难题现在竟然可以迎刃而解。

　　5. 对答案的渴求。人类自然科学的发展史就是一个渴求得到答案的过程，即使只能
知道答案的一小部分也值得我们去付出。只要你坚定信念，一定要找到问题的答案，你
才会付出精力去探索，即使最后没有得到答案，在过程中你也会学到很多东西。

　　6. 多与别人交流。三人行必有我师，也许在一次和别人不经意的谈话中，就可以迸
出灵感的火花。多上上网，看看别人对同一问题的看法，会给你很大的启发。

　　7. 良好的编程风格。注意养成良好的习惯，代码的缩进编排，变量的命名规则要始
终保持一致。大家都知道如何排除代码中错误，却往往忽视了对注释的排错。注释是程
序的一个重要组成部分，它可以使你的代码更容易理解，而如果代码已经清楚地表达了
你的思想，就不必再加注释了，如果注释和代码不一致，那就更加糟糕。

　　8. 韧性和毅力。这也许是"高手"和一般程序员最大的区别。A good programming
is 99 weat and 1?ffee。高手们并不是天才，他们是在无数个日日夜夜中磨练出来的
。成功能给我们带来无比的喜悦，但过程却是无比的枯燥乏味。你不妨做个测试，找个1
0000以内的素数表，把它们全都抄下来，然后再检查三遍，如果能够不间断地完成这一
工作，你就可以满足这一条。





# 回复：做程序员，累吗？ 2004-08-09 3:00 PM John
* 比较宽的知识面，并且能够时时补充自己的知识和完善自己的知识结构

* 耐心好，特别是在调试和学习阶段，世界上没有聪明的人只有刻苦的人。做开发其实
就两件事情学习和改错，在这两件事情中间的开发过程其实是比较简单的

* 永远记住：代码是给人看的而不是给机器运行的，计算机在执行程序时是不怕累的，
而人在看代码时是非常累的

* 良好的编码习惯，至少保证自己能够随时看懂几个月前自己所写的代码

* 尽量让你的代码能够很容易的被别人理解，写代码时想想你会不会在两个月后被别人
骂

* 不要容忍自己犯重复的错误和写重复的代码

* 知道如何做比得到代码更重要

* 尽量不要做已经有很多人已经做过的事情

* 学会尊重别人的开发成果，除非不得已不要下决定全面替换以前的系统

* 珍惜自己的时间与工作成果，尽量让别人分享自己的开发成果

* 避免假设，多思考极端情况与引起错误的可能性，努力减少低级错误

* 不要相信至少是不要轻信自己为自己所做的测试结果

* 懂得坚持自己的开发思路，并懂得理解与吸收别人的思想

* 学会与其他人保持一致，但不能放弃自己的开发特色

* 懂得向你周围的人学习，不论是开发能力上的还是开发经验上的

* 懂得软件结构的的重要性，分析代码前先分析代码的结构

* 学会总结，定期总结自己所学会的知识，看看自己前段时间因为各种原因所浪费的时
间

* 学会计划，尽量不要认为通过延长自己的工作时间来完成任务

* 学会正确估计自己的能力和工作时间

下面这些是我认为一些比较适合我自己的方面，不一定对每个人都合适：

* 多看些杂志，没事情的时候可以看看以前看过的参考书，书中很可能有你以前没有注
意到的一些细节

* 不要太早去做一些与开发无关的事情，因为学习的黄金时期是很短暂的

* 学会分析别人的系统，多看看别人所开发的系统的先进的一面。这里包括别人的开发
思路，实现时所采用的结构

* 时常感到自己将被淘汰，经常埋怨自己的不努力

* 知道自己缺少什么

* 强迫自己做一些自己不喜欢做的事情，比如说写文档

* 能够有勇气重写自己所开发的系统，但当你重做时你应该采取和前一次不同的工作方
式和方法，否则重做就没有必要

* 将问题简单化而不是复杂化

* 将维护时会产生的一部分问题转移到开发时或是设计时来解决

* 有时候也不妨问问自己：我不做开发时去做什么

* 坚持为自己做每周的开发计划，在事情没有做完以前不要轻易转移自己的注意力

* 尽可能多的将你所做的教给别人，因为你有一天可能不再负责这个系统

* 做事一定要有始有终，除非是有不得已的理由否则不要在工作完成前提前离开

* 不要将你为公司做的东西带走，你因该带走的是开发经验和对开发的认识而不是代码
和产品

* 感到累时就休息一下，给自己放个假也无妨，毕竟人不是机器

　　做程序员很累的，够你受的，加油吧！