程序员的八大核心能力
在 The Pragmatic Programmer 的第三章, 作者总结了程序员的八大核心能力, 各位看看你们同意么, 还要补充什么?
1. 使用纯文本的能力
不要动不动就 word, rtf, 学会使用纯文本. 用纯文本有很多好处, 比如可移植性, 可读性, 易操作性等等.
顺便广告几个简单实用性的,
wiki,用的比较广泛,但文本状态下,可读性不太理想.
Asciidoc,非常优秀 (http://www.methods.co.nz/asciidoc/)
a9text,(在下自己玩的,js写的 http://a9text.sourceforge.net/)
2. Shell
所谓一行 shell 胜过千行C代码, 用 Shell 可以快速的完成一些临时的需要很快完成的任务, 提升生产率
3. 编辑器使用
最好有一个包打天下的, 能够完成编码 调试 编译等一起的编辑器, 使得能够专注于这个编辑器, 不会在程序里面来回切.
4. 源代码版本控制系统的使用
这个大家都知道是什么
5. Debug
学会使用 gdb 等, 会debug的基本技能
"在我的老文程序员的成长从开窍开始系列
一、如何摆脱低级错误的困扰<http://www.tinydust.net/prog/diary/2007/12/blog-post.html>
http://www.tinydust.net/prog/diary/2007/12/blog-post.html中，我其实就是试图，把调试解决Bug的能力，以及写出清晰代码的能力，作为一个程序员从初学者到真正的程序员这一开窍过程中的第一步。自动测试，我认为可以算作
"在写代码的过程中，应该为以后调试--不仅为了方便自己调试，同时也可以方便别的开发人员快速debug到需要的信息。
应该考虑好之后调试的事情。比如，添加一些输出有用信息的的函数，在调试的时候可以通过
set debug_*()来进行调用，对代码的可维护性和可读性都有很好的提高。当然，你知道，对于
一般大型程序的阅读很少直接去读代码的，大多都是先break到感兴趣的部分，再***的。"
6. 文本处理
基本的查找替换, 正则表达式, 简单的 sed awk 等等
7. 代码生成
不要每行代码都自己写, 用工具生成代码. 等等.
8. 自动测试框架
more:
9. 写简洁准确的注释和文档
10. performance profiler
11. 程序文档的编写能力"*
用原作者的话说，就是
1) Treat English as Just Another Programming Language
2) Build Documentation In, Don't Bolt It On
具体一些的话，就是The Element of Style和Doxygen之类的东西
12. 关注细节
1、关心你的技艺
Care About Your Craft
除非你在乎能否漂亮地开发出软件，否则其它事情都是没有意义的。
2、思考！你的工作
Think!About Your Work
在你做某件事情的时候思考你在做什么。不间断地思考，实时地批判你的工作。这将占据你的一些宝贵时间，酬劳则是更为活跃地参与你喜爱的工作、感觉到自己在掌握范
3、提供各种选择，不要找蹩脚的借口
Provide Options,Don't Make Lame Excuses
不要说事情做不到；要说明能够做什么来挽回局面。不要害怕提出要求，也不要害怕承认你需要帮助。
4、不要容忍破窗户
Don't Live With Broken Windows
不要留着“破窗户”（低劣的设计、错误的决策、或者糟糕的代码）不修。发现一个就修一个。如果没有足够的时间进行适当的修理，采取某种行动防止进一步的破坏，并
如果你发现你所在团队和项目的代码十分漂亮——编写整洁、设计良好，并且很优雅，你不会想成为第一个弄脏东西的人。
5、做变化的催化剂
Be a Catalyst for Change
你不能强迫人们改变。相反，要向他们展示未来可能会怎样，并帮助他们参与对未来的创造。
设计出你可以合理要求的东西，好好开发它。一旦完成，就拿给大家看，让他们大吃一惊。然后说：“要是我们增加...可能就会更好。”假装那并不重要。坐回椅子上
6、记住大图景
Remember the Big Picture
如果你抓一只青蛙放进沸水里，它会一下子跳出来。但是，如果你把青蛙放进冷水里，然后慢慢加热，青蛙不会注意到温度的缓慢变化，会呆在锅里，直到被煮熟。
不要像青蛙一样。留心大图景。要持续不断地观察周围发生的事情，而不只是你自己在做的事情。
7、使质量成为需求问题
Make Quality a Requirements Issue
你所制作的系统的范围和质量应该作为系统需求的一部分规定下来。让你的用户参与权衡，知道何时止步，提供足够好的软件。
8、定期为你的知识资产投资
Invest Regularly in Your Knowledge Portfolio
让学习成为习惯。
持续投入十分重要。一旦你熟悉了某种新语言或新技术，继续前进，学习另一种。
是否在某个项目中使用这些技术，或者是否把它们放入你的简历，这并不重要。学习的过程将扩展你的思维，使你向着新的可能性和新的做事方式拓展。思维的“异花授粉
如果你自己找不到答案，就去找出能找到答案的人。不要把问题搁在那里。
9、批判地分析你读到的和听到的
Critically Analyze What You Read and Hear
不要被供应商、媒体炒作、或教条左右。要依照你自己的看法和你的项目的情况去对信息进行分析。
10、你说什么和你怎么说同样重要
It's Both What You Say and the Way You Say It
作为开发者，我们必须在许多层面上进行交流。我们的时间有很大部分都花在交流上，所以我们需要把它做好。
如果你不能有效地向他人传达你的了不起的想法，这些想法就毫无用处。
知道你想要说什么；了解你的听众；选择时机；选择风格；让文档美观；让听众参与；做倾听者；回复他人。
交流越有效，你就越有影响力。
11、DRY原则——不要重复你自己
DRY - Don't Repeat Yourself
系统中的每一项知识都必须具有单一、无歧义、权威的表示。与此不同的做法是在两个或更多地方表达同一事物。如果你改变其中一处，你必须记得改变其它各处。这不是
12、让复用变得容易
Make it Easy to Reuse
你要做的是营造一种环境，在其中要找到并复用已有的东西，比自己编写更容易。如果复用很容易，人们就会去复用。而如果不复用，你们就会有重复知识的风险。
13、消除无关事物之间的影响
Eliminate Effects Between Unrelated Things
我们想要设计自足（self-contained）的组件：独立，具有单一、良好定义的目的。如果组件是相互隔离的，你就知道你能够改变其中一个，而不用担心其
你得到两个主要好处：提高生产率与降低风险。
14、不存在最终决策
There Are No Final Decisions
没有什么永远不变——而如果你严重依赖某一事实，你几乎可以确定它将会变化。与我们开发软件的速度相比，需求、用以及硬件变得更快。通过DRY原则、解耦以及元
15、用曳光弹找到目标
Use Tracer Bullets to Find the Target
曳光弹能通过试验各种事物并检查它们离目标有多远来让你追踪目标。
曳光弹代码含有任何一段产品代码都拥有的完整的错误检查、结构、文档、以及自查。它只不过功能不全而已。但是，一旦你在系统的各组件之间实现了端到端（end-
16、为了学习而制作原型
Prototype to Learn
任何带有风险的事物。以前没有试过的事物，或是对于最终系统极其关键的事物。任何未被证明的、试验性的、或有疑问的事物。任何让你觉得不舒服的东西。都可以通过
原型制作是一种学习经验，其价值并不在于所产生的代码，而在于所学到的经验教训。
17、靠近问题领域编程
Program Close to The Problem domain
计算机语言会影响你思考问题的方式，以及你看待交流的方式。用你的用户的语言进行设计和编码。
18、估算，以避免发生意外
Estimate to Avoid Surprises
在着手之前先进行估算。你将提前发现潜在的问题。
1）要选择能反映你想要传达的精确度的单位；
2）基本的估算诀窍：去问已经做过这件事情的人；
3）理解提问内容；
4）根据对问题的理解，建立粗略、就绪的思维模型骨架；
5）把模型分解为组件，找出描述这些组件怎样交互的数学规则，确定每个组件的参数；
6）给每个参数指定值，找出哪些参数对结果的影响最大，并致力于让它们大致正确；
7）进行多次计算，改变关键参数的值，然后根据那些参数表达你的答案；
8）在被要求进行估算时说的话：“我等会回答你”。
19、通过代码对进度表进行迭代
Iterate the Schedule with the Code
实行增量开发。追踪你的估算能力，提炼对迭代次数、以及在每次迭代中可以包含的内容的猜想。提炼会变得一次比一次好，对进度表的信心也将随之增长。你将给予管理
20、用纯文本保存知识
Keep Knowledge in Plain Text
保证不过时；
杠杆作用：每一样工具，都能够在纯文本上进行操作；
更易于测试；
你需要确保所有各方能够使用公共标准进行通信。纯文本就是那个标准。
21、利用命令shell的力量
Use the Power of Command Shells
GUI环境通常受限于它们的设计者想要提供的能力。当你想要快速地组合一些命令，以完成一次查询或某种其他的任务时，命令行要更为适宜。多使用你的命令shel
22、用好一种编辑器
Use a Single Editor Well
选一种编辑器，彻底了解它，并将其用于所有的编辑任务。如果你用一种编辑器进行所有的文本编辑活动，你就不必停下来思考怎样完成文本操纵：必需的键击将成为本能
23、总是使用源码控制
Always Use Source Code Control
总是。即使你的团队只有你一个人，你的项目只有一周时间；确保每样东西都处在源码控制之下。
源码控制是你的工作的时间机器——你能够回到过去。
把整个项目置于源码控制系统的保护之下具有一项很大的、隐蔽的好处：你可以进行自动的和可重复的产品构建。
24、要修正问题，而不是发出指责
Fix the Problem,Not the Blame ...
This entry was posted
on Friday, March 13, 2009 at 6:59 AM.
You can skip to the end and leave a response.
0 Comments:
Post a Comment