没有合适的资源?快使用搜索试试~ 我知道了~
首页《代码阅读:开源视角》——提升编程技艺
《代码阅读:开源视角》——提升编程技艺
需积分: 9 10 下载量 91 浏览量
更新于2024-08-01
收藏 7.08MB PDF 举报
"《代码阅读:开源视角》是由Diomidis Spinellis撰写的一本关于如何阅读和理解开源代码的专业书籍。这本书由Addison Wesley出版社于2003年5月出版,共有528页,ISBN号为0-201-79940-5。"
在软件开发领域,阅读代码是每个程序员必不可少的技能。无论是为了修复问题、检查性能,还是为了学习和改进现有代码,都需要掌握有效的代码阅读技巧。《代码阅读:开源视角》针对这一主题进行了深入探讨,作者Diomidis Spinellis通过超过600个实际案例,帮助读者提高代码理解和分析能力。
书中的内容涵盖了以下几个关键知识点:
1. **代码审查策略**:书中讨论了如何高效地开始阅读大规模的代码库,例如在面对一个34,000行的程序时,如何快速定位并理解新功能的添加位置(第333页)。
2. **理解复杂代码**:当遇到难以理解的代码片段时,应如何逐步解析并简化它(第39页)。这包括识别代码结构、模式和潜在的优化点。
3. **处理复杂的构建过程**:在面对复杂的构建流程时,如何找到入手点进行解构和梳理(第167页),以确保项目的可维护性和可构建性。
4. **并发编程的理解**:面对看似同时执行多个任务的代码,如何理清其执行逻辑和并发控制机制(第132页),这对于理解和优化多线程或异步代码至关重要。
5. **代码质量评估**:书中教导读者如何区分优质和劣质代码,以及如何从中学习,提升自己的编码实践(第39页)。长期阅读优秀的代码可以潜移默化地提升个人编码习惯(摘自书中的事实陈述)。
6. **代码重构与改进**:通过学习他人的代码,读者将学会如何应用这些知识来改进自己的代码,使其更清晰、更健壮、更易于维护。
《代码阅读:开源视角》是一本对程序员极具价值的指南,它提供了一套系统的方法论,帮助读者提升代码阅读效率,增强代码分析能力,并促进个人编码水平的提高。无论是新手程序员还是经验丰富的开发者,都能从本书中获益良多。
[ Team LiB ]
Foreword
We're programmers. Our job (and in many cases our passion) is to make things happen by writing code. We don't meet our user' s
requirements with acres of diagrams, with detailed project schedules, with four-foot-high piles of design documentation. These are al l
wishes—expressions of what we'd like to be true. No, we deliver by writing code: code is reality .
So that's what we're taught. Seems reasonable. Our job is to write code, so we need to learn how to write code. College courses teach
us to to write programs. Training courses tell us how to code to new libraries and API s. And that's one of the biggest tragedies in the
industry.
Because the way to learn to write great code is by reading code. Lots of code. High-quality code, low-quality code. Code in assembler,
code in Haskell. Code written by strangers ten thousand miles away, and code written by ourselves last week. Because unless we do
that, we're continually reinventing what has already been done, repeating both the successes and mistakes of the past.
I wonder how many great novelists have never read someone else's work, how many great painters never studied another's brush
strokes, how many skilled surgeons never learned by looking over a colleague's shoulder, how many 767 captains didn't first spend time
in the copilot's seat watching how it's really done.
And yet that's what we expect programmers to do. "This week's assignment is to write...." We teach developers the rules of syntax and
construction, and then we expect them to be able to write the software equivalent of a great novel.
The irony is that there's never been a better time to read code. Thanks to the huge contributions of the open-source community, we now
have gigabytes of source code floating around the 'net just waiting to be read. Choose any language, and you'll be able to find source
code. Select a problem domain, and there'll be source code. Pick a level, from microcode up to high-level business functions, and you'll
be able to look at a wide body of source code.
Code reading is fun. I love to read others' code. I read it to learn tricks and to study traps. Sometimes I come across small but precious
gems. I still remember the pleasure I got when I came across a binary-to-octal conversion routine in PDP -11 assembler that managed to
output the six octal digits in a tight loop with no loop counter.
I sometimes read code for the narrative, like a book you'd pick up at an airport before a long flight. I expect to be entertained by clever
plotting and unexpected symmetries. Jame Clark's gpic program (part of his GNU groff package) is a wonderful example of this kind of
code. It implements something that's apparently very complex (a declarative, device-independent picture-drawing language)in a compact
and elegant structure. I came away feeling inspired to try to structure my own code as tidily.
Sometimes I read code more critically. This is slower going. While I'm reading, I'm asking myself questions such as "Why is this written
this way?" or "What in the author's background would lead her to this choice?" Often I'm in this mode because I'm reviewing code for
problems. I'm looking for patterns and clues that might give me pointers. If I see that the author failed to take a lock on a shared data
structure in one part of the code, I might suspect that the same might hold elsewhere and then wonder if that mistake could account for
the problem I'm seeing. I also use the incongruities I find as a double check on my understanding; often I find what I think is a problem,
but it on closer examination it turns out to be perfectly good code. Thus I learn something.
In fact, code reading is one of the most effective ways to eliminate problems in programs. Robert Glass, one of this book's reviewers,
says, "by using (code) inspections properly, more than 90 percent of the errors can be removed from a software product before its first
test.
[1]
In the same article he cites research that shows "Code-focused inspectors were finding 90 percent more errors than
process-focused inspectors." Interestingly, while reading the code snippets quoted in this book I came across a couple of bugs and a
couple of dubious coding practices. These are problems in code that's running at tens of thousands of sites worldwide. None were
critical in nature, but the exercise shows that there's always room to improve the code we write. Code-reading skills clearly have a great
practical benefit, something you already know if you've ever been in a code review with folks who clearly don't know how to read code.
[1]
http://www.stickyminds.com/se/S2587.asp
And then there's maintenance, the ugly cousin of software development. There are no accurate statistics, but most researchers agree
that more than half of the time we spend on software is used looking at existing code: adding new functionality, fixing bugs, integrating it
into new environments, and so on. Code-reading skills are crucial. There's a bug in a 100,000-line program, and you've got an hour to
find it. How do you start? How do you know what you're looking at? And how can you assess the impact of a change you're thinking of
making?
For all these reasons, and many more, I like this book. At its heart it is pragmatic. Rather than taking an abstract, academic approach, it
instead focuses on the code itself. It analyzes hundreds of code fragments, pointing out tricks, traps and (as importantly) idioms. It talks
about code in its environment and discusses how that environment affects the code. It highlights the important tools of the code reader's
trade, from common tools such as grep and find to the more exotic. And it stresses the importance of tool building: write code to help you
read code. And, being pragmatic, it comes with all the code it discusses, conveniently cross-referenced on a CD-ROM .
This book should be included in every programming course and should be on every developer's bookshelf. If as a community we pay
more attention to the art of code reading we'll save ourselves both time and pain. We'll save our industry money. And we'll have more fun
while we're doing it.
Dave Thoma s
The Pragmatic Programmers, LL C
http://www.pragmaticprogrammer.com
[ Team LiB ]
[ Team LiB ]
Preface
What do we ever get nowadays from reading to equal the excitement and the revelation in those first fourteen
years?
— Graham Greene
The reading of code is likely to be one of the most common activities of a computing professional, yet it is seldom taught as a subject or
formally used as a method for learning how to design and program.
One reason for this sad situation originally may have been the lack of real-world or high-quality code to read. Companies often protect
source code as a trade secret and rarely allow others to read, comment on, experiment with, and learn from it. In the few cases where
important proprietary code was allowed out of a company's closet, it spurred enormous interest and creative advancements. As an
example, a generation of programmers benefited from John Lions's Commentary on the Unix Operating System that listed and
annotated the complete source code of the sixth-edition Unix kernel. Although Lions's book was originally written under a grant from
AT&T for use in an operating system course and was not available to the general public, copies of it circulated for years as bootleg
nth-generation photocopies.
In the last few years, however, the popularity of open-source software has provided us with a large body of code we can all freely read.
Some of the most popular software systems used today, such as the Apache Web server, the Perl language, the GNU /Linux operating
system, the BIND domain name server, and the sendmail mail-transfer agent are in fact available in open-source form. I was thus
fortunate to be able to use open-source software such as the above to write this book as a primer and reader for software code. My goal
was to provide background knowledge and techniques for reading code written by others. By using real-life examples taken out of
working, open-source projects, I tried to cover most concepts related to code that are likely to appear before a software developer's
eyes, including programming constructs, data types, data structures, control flow, project organization, coding standards, documentation,
and architectures. A companion title to this book will cover interfacing and application-oriented code, including the issues of
internationalization and portability, the elements of commonly used libraries and operating systems, low-level code, domain-specific and
declarative languages, scripting languages, and mixed language systems.
This book is—as far as I know—the first one to exclusively deal with code reading as a distinct activity, one worthy on its own. As such I
am sure that there will be inevitable shortcomings, better ways some of its contents could have been treated, and important material I
have missed. I firmly believe that the reading of code should be both properly taught and used as a method for improving one' s
programming abilities. I therefore hope this book will spur interest to include code-reading courses, activities, and exercises into th e
computing education curriculum so that in a few years our students will learn from existing open-source systems, just as their peer s
studying a language learn from the great literature .
[ Team LiB ]
[ Team LiB ]
Supplementary Material
Many of the source code examples provided come from the source distribution of Net BSD . Net BSD is a free, highly portable Unix-like
operating system available for many platforms, from 64-bit AlphaServers to handheld devices. Its clean design and advanced features
make it an excellent choice for both production and research environments. I selected Net BSD over other similarly admirable and very
popular free Unix-like systems (such as GNU /Linux, Free BSD , and Open BSD ) because the primary goal of the Net BSD project is to
emphasize correct design and well-written code, thus making it a superb choice for providing example source code. According to its
developers, some systems seem to have the philosophy of "if it works, it's right," whereas Net BSD could be described as "it doesn't work
unless it's right." In addition, some other Net BSD goals fit particularly well with the objectives of this book. Specifically, the Net BSD project
avoids encumbering licenses, provides a portable system running on many hardware platforms, interoperates well with other systems,
and conforms to open systems standards as much as is practical. The code used in this book is a (now historic) export-19980407
snapshot. A few examples refer to errors I found in the code; as the Net BSD code continuously evolves, presenting examples from a
more recent version would mean risking that those realistic gems would have been corrected.
I chose the rest of the systems I used in the book's examples for similar reasons: code quality, structure, design, utility, popularity, and a
license that would not make my publisher nervous. I strived to balance the selection of languages, actively looking for suitable Java and
C++ code. However, where similar concepts could be demonstrated using different languages I chose to use C as the least common
denominator.
I sometimes used real code examples to illustrate unsafe, nonportable, unreadable, or otherwise condemnable coding practices. I
appreciate that I can be accused of disparaging code that was contributed by its authors in good faith to further the open-source
movement and to be improved upon rather than merely criticized. I sincerely apologize in advance if my comments cause any offense to
a source code author. In defense I argue that in most cases the comments do not target the particular code excerpt, but rather use it to
illustrate a practice that should be avoided. Often the code I am using as a counterexample is a lame duck, as it was written at a time
when technological and other restrictions justified the particular coding practice, or the particular practice is criticized out of the context.
In any case, I hope that the comments will be received with good humor, and I openly admit that my own code contains similar, and
probably worse, misdeeds.
[ Team LiB ]
[ Team LiB ]
Acknowledgments
A number of people generously contributed advice, comments, and their time helping to make this book a reality. Addison-Wesley
assembled what I consider a dream team of reviewers: Paul C. Clements, Robert L. Glass, Scott D. Meyers, Guy Steele, Dave Thomas,
and John Vlissides graciously read the manuscript in a form much rougher than the one you hold in your hands and shared their
experience and wisdom through thoughtful, perceptive, and often eye-opening reviews. In addition, Eliza Fragaki, Georgios Chrisoloras,
Kleanthis Georgaris, Isidor Kouvelas, and Lorenzo Vicisano read parts of the manuscript in an informal capacity and contributed many
useful comments and suggestions. I was also lucky to get advice on the mechanics of the production process from Bill Cheswick,
Christine Hogan, Tom Limoncelli, and Antonis Tsolomitis. Furthermore, George Gousios suggested the use of Tom-cat as Java
open-source software material and explained to me details of its operation, pointed me toward the ant build tool, and clarified issues
concerning the use of the DocBook documentation format. Stephen Ma solved the mystery of how vnode pointers end up at the operating
system device driver level (see Section 9.1.4 ). Spyros Oikonomopoulos provided me with an overview of the reverse engineering
capabilities of UML -based modeling tools. Panagiotis Petropoulos updated the book references. Konstantina Vassilopoulou advised me
on readability aspects of the annotated code listings. Ioanna Grinia, Vasilis Karakoidas, Nikos Korfiatis, Vasiliki Tangalaki, and George
M. Zouganelis contributed their views on the book's layout. Athan Tolis located the epigram for Chapter 5 in the London Science
Museum library.
Elizabeth Ryan and the folks at ITC patiently designed and redesigned the book until we could all agree it had the right look.
My editors, Ross Venables and Mike Hendrickson at Addison-Wesley, handled the book's production with remarkable effectiveness. In
the summer of 2001, a week after we first established contact, Ross was already sending the manuscript proposal for review; working
with a seven-hour time zone difference, I would typically find any issues I raised near the end of my working day solved when I opened
my email in the morning. Their incredible efficiency in securing reviewers, answering my often naive questions, dealing with the book's
contractual aspects, and coordinating the complex production process was paramount in bringing this project to fruition. Later on,
Elizabeth Ryan expertly synchronized the Addision-Wesley production team; Chrysta Meadowbrooke diligently copy-edited my (often
rough) manuscript, demonstrating an admirable understanding of its technical content; ITC handled the demanding composition task;
and Jennifer Lundberg patiently introduced me to the mysteries of book marketing.
The vast majority of the examples used in this book are parts of existing open-source projects. The use of real-life code allowed me to
present the type of code that one is likely to encounter rather than simplified toy programs. I therefore wish to thank all the contributors of
the open-source material I have used for sharing their work with the programming community. The contributor names of code that
appears in the book, when listed in the corresponding source code file, appear in Appendix B .
[ Team LiB ]
剩余504页未读,继续阅读
牛牛顶牛
- 粉丝: 0
- 资源: 3
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- 单片机串口通信仿真与代码实现详解
- LVGL GUI-Guider工具:设计并仿真LVGL界面
- Unity3D魔幻风格游戏UI界面与按钮图标素材详解
- MFC VC++实现串口温度数据显示源代码分析
- JEE培训项目:jee-todolist深度解析
- 74LS138译码器在单片机应用中的实现方法
- Android平台的动物象棋游戏应用开发
- C++系统测试项目:毕业设计与课程实践指南
- WZYAVPlayer:一个适用于iOS的视频播放控件
- ASP实现校园学生信息在线管理系统设计与实践
- 使用node-webkit和AngularJS打造跨平台桌面应用
- C#实现递归绘制圆形的探索
- C++语言项目开发:烟花效果动画实现
- 高效子网掩码计算器:网络工具中的必备应用
- 用Django构建个人博客网站的学习之旅
- SpringBoot微服务搭建与Spring Cloud实践
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功