2015-05-26 628 Code-Tuning Techniques
——Even though a particular technique generally represents poor coding practice, specific circumstances might make it the best one to use.
——One key to writing effective loops is to minimize the work done inside a loop. If you can evaluate a statement or part of a statement outside a loop so that only the result is used inside the loop, do so.
——The sentinel technique can be applied to virtually any situation in which you use a linear search—to linked lists as well as arrays. The only caveats are that you must choose the sentinel value carefully and that you must be careful about how you put the sentinel value into the data structure.
——When you have nested loops, think about which loop you want on the outside and which you want on the inside.
——Changes in data types can be a powerful aid in reducing program size and improving execution speed.
——One example of using a supplementary index can be found in the different string-storage strategies. Visual Basic length byte is an example of augmenting a data type with an index to make certain operations—like computing the length of a string—faster.
2015-05-27 634 Code-Tuning Techniques
——Sometimes it's more efficient to manipulate an index to a data than it is to manipulate the data type itself. If the items in the data type are big or hard to move, sorting and searching index reference is faster than working with the data directly.
——Caching means saving a few values in such a way that you can retrieve the most commonly used values more easily than the less commonly used values.
——If you're using a named constant or a magic number in a routine call and it's the only argument, that's a clue that you could precompute the number, put it into a constant, and avoid the routine call.
——System routines are expensive and provide accuracy that's often wasted. Typical system math routines, for example, are designed to put an astronaut on the moon within 2 feet of the target.
2015-05-28 643 Code-Tuning Techniques
——Most of the so-called "transcendental" functions are designed for the worst case—that is, they convert to double-precision floating point internally even if you give them an integer argument. If you find one in a tight section of code and don't need that much accuracy, give it your immediate attention.
——Use named constants and literals that are the same type as the variables they're assigned to. When a constant and its related variable are different types, the compiler has to do a type conversion to assign the constant to the variable.
——If you find an expression that's repeated several times, assign it to a variable and refer to the variable rather than recomputing the expression in several places.
——Small, well-defined routines save space because they take the place of doing jobs separately in multiple places. They make a program easy to optimize because you can refactor code in one routine and thus improve every routine that calls it.
——Modern machines—and "modern" means any machine you're ever likely to work on—impose virtually no penalty for calling a routine. You're as likely to degrade performance by keeping code inline as to optimize it.
——One long-standing piece of conventional wisdom that shouldn't be left unmentioned is the advice that when you run into a performance bottleneck, you should recode in a low-level language.
2015-05-29 649 Code-Tuning Techniques
——The effect of each code tuning is affected by the programming language, compiler, compiler version, code libraries, library versions, and compiler settings, among other things.
——I have found that insisting on measurable improvement is a good way to resist the temptation to optimize prematurely and a good way to enforce a bias toward clear, straight forward code.
——The impact of unmeasured code tuning on performance is speculative at best, whereas the impact on readability is as certain as it is detrimental.
——Code tuning is a little like nuclear energy. It's a controversial, emotional topic. Some people think it's so detrimental to reliability and maintainability that they won't do it at all. Others think that with proper safeguards, it's beneficial. If you decide to use the techniques, apply them with care.
2015-06-01 655 How Program Size Affects Construction
——If you've been accustomed to working on small projects, your first medium-to-large project can rage riotously out of control, becoming an uncontrollable beast instead of the pleasant success you had envisioned.
——The more communication paths you have, the more time you spend communicating and the more opportunities are created for communication mistakes. Larger-size projects demand organizational techniques that streamline communications or limit it in a sensible way.
问题：为什么说文档化是提高交流效率的典型方法？
——The number of errors increases dramatically as project size increases, with very large projects having up to four times as many errors per thousand lines of code as small projects.
——Productivity on small projects can be 2-3 times as high as productivity on large projects, and productivity can vary by a factor of 5-10 from the smallest projects to the largest.
——Construction becomes less predominant because as project size increases, the construction activities—detailed design, coding, debugging, and unit testing—scale up proportionately but many other activities scale up faster.
2015-06-03 657 How Program Size Affects Construction
问题：哪些活动在项目规模增长时有非线性的增长率？
——Regardless of the size of a project, a few techniques are always valuable: disciplined coding practices, design and code inspections by other developers, good tool support, and use of high-level languages.
——Lines of code and team size aren't the only influences on a project's size. A more subtle influence is the quality and the complexity of the final software.
——Development of a system is more complicated than development of a simple program because of the complexity of developing interfaces among the pieces and the care needed to integrate the pieces.
——Programmers who use their experience in building a program to estimate the schedule for building a system product can underestimate by a factor of almost 10.
——Methodologies are used on project of all sizes. On small projects, methodologies tend to be casual and instinctive. On large projects, they tend to be rigorous and carefully planned.
——While it may be true that a programmer hasn't selected a methodology consciously, any approach to programming constitutes a methodology, no matter how unconscious or primitive the approach is.
2015-06-04 661 How Program Size Affects Construction
——The documentation is a tangible side effect of the real work you do as you plan and construct a software system. If you feel as though you're going through the motions and writing generic documents, something is wrong.
——You'll usually do better if you start your methods small and scale up for a large project than if you start with an all-inclusive method and pare it down for a small project.
——Some software pundits talk about "lightweight" and "heavyweight" methodologies, but in practice the key is to consider your project's specific size and type and then find the methodology that's "right-weight".
——As project size increases, communication needs to be supported. The point of most methodologies is to reduce communications problems, and a methodology should live or die on its merits as a communicatin facilitator.
——Activities that are taken for granted on small projects must be carefully planned on larger ones. Construction becomes less predominant as project size increases.
——Scaling up a lightweight methodology tends to work better than scaling down a heavyweight methodology. The most effective approach of all is using a "rightweight" methodology.
2015-06-04 661 How Program Size Affects Construction
——The documentation is a tangible side effect of the real work you do as you plan and construct a software system. If you feel as though you're going through the motions and writing generic documents, something is wrong.
——You'll usually do better if you start your methods small and scale up for a large project than if you start with an all-inclusive method and pare it down for a small project.
——Some software pundits talk about "lightweight" and "heavyweight" methodologies, but in practice the key is to consider your project's specific size and type and then find the methodology that's "right-weight".
——As project size increases, communication needs to be supported. The point of most methodologies is to reduce communications problems, and a methodology should live or die on its merits as a communicatin facilitator.
——Activities that are taken for granted on small projects must be carefully planned on larger ones. Construction becomes less predominant as project size increases.
——Scaling up a lightweight methodology tends to work better than scaling down a heavyweight methodology. The most effective approach of all is using a "rightweight" methodology.
2015-06-05 665 Managing Construction
——Programmers tend to view managers as being at a lower level of technical evolution, somewhere between single-celled organisms and the woolly mammoths that died during the Ice Age, and if there are going to be programming standards, programmers need to buy into them.
——If your group resists adopting strict standards, consider a few alternatives: flexible guidelines, a collection of suggestions rather than guidelines, or a set of examples that embody the best practices.
问题：有哪些方法可以鼓励好的编程实践同时避免僵硬的代码标准？
——The mechanisms for teaming two people can range from pair programming to mentor-trainee pairs to buddy-system reviews.
——In addition to providing a safety net in case the original programmer leaves the project, reviews improve code quality because the programmer knows that the code will be read by others.
——A big part of good management is communicating your objectives clearly. One way to communicate your objectives is to circulate good code to your programmers or post it for public display.
——Although it is the result of their work, code is part of the project and should be freely available to anyone else on the project who needs it. It should be seen by others during reviews and maintenance, even if at no other time.
——If you give an award to a programmer everyone else knows does bad work, you look like Homer Simpson trying to run a nuclear reactor. It doesn't matter that the programmer has a cooperative attitude or always comes to work on time.
问题：什么是配置管理？
——Configuration management is the practice of identifying project artifacts and handling changes systematically so that a system can maintain its integrity over time. Another name for it is "change control".
——If changes aren't handled systematically, you're taking random steps in the fog rather than moving directly toward a clear destination. Without good change control, rather than developing code you're wasting your time thrashing.
2015-06-08 668 Managing Construction
——The surest way to stop car accidents is to prevent everyone from driving, and one sure way to prevent software-development problems is to stop all software development. Although that's one way to control changes, it's a terrible way to develop software.
——During development, you're bound to be bristling with ideas about how to improve the system. If you implement each change as it occurs to you, you'll soon find yourself walking on a software treadmill—for all that the system will be changing, it won't be moving closer to completion.
——It's tempting to implement easy changes as ideas arise. The problem with handling changes in this way is that good changes can get lost. Some of the best changes can slip through the cracks merely because you thought them later rather than sooner.
问题：解决上面问题的方法是什么？
——Let all the interested parties know that software is intricately interwoven and that time estimation is necessary even if the change appears small at first glance.
——Backing up to work on requirements or architecture might seem expensive, but it won't be nearly as expensive as construction the software more than once or throwing away code for features that you really didn't need.
——Change-control boards are considered a best practice for prioritizing and controlling requirements changes; however, they are still fairly uncommon in commercial settings.
——Lack of disciplined change control is one of the biggest management problems facing the software industry today. A significant percentage of the projects that are percieved to be late would actually be on time if they accounted for the impact of untracked but agreed-upon changes.
——Version control is indispensable on team projects. It becomes even more powerful when version control, defect tracking, and change management are integrated.
2015-06-09 675 Managing Construction
——Many companies have experienced good results from creating standardized development machine configurations. A standardized disk image greatly streamlines setting up new machines compared to having to install each piece of software individually.
——Your backup plan should include making backups on a periodic basis and periodic transfer of backups to off-site storage, and it should encompass all the important materials on your project—documents, graphics, and notes—in addition to source code.
——When you finish a project, make a project archive. Save a copy of everything: source code, compilers, tools, requirements, design, documentation—everything you need to re-create the product. Keep it all in a safe place.
——Do you view major changes as a warning that requirements development isn't yet complete.
——Managing a software project is one of the formidable challenges of the twenty-first century, and estimating the size of a project and the effort required to complete it is one of the most challenging aspects of software-project management.
——Rushed estimates are inaccurate estimates. If you're estimating a large project, treat estimation as a miniproject and take the time to miniplan the estimate so that you can do it well.
——It's hard to find an area of software development in which iteration is not valuable. Estimation is one case in which iteration is useful.
——Estimates created early in a project are inherently inaccurate. As the project progresses, estimates can become more accurate. Reestimate periodically throughout a project, and use what you learn during each activity to improve your estimate for the next activity.
2015-06-10 681 Managing Construction
——One survey of over 300 software projects concluded that delays and overruns generally increase toward the end of a project. Projects don't make up lost time later; they fall further behind.
——According to Fred Brook's law, adding people to a late software project makes it later. He points out that the fact that one woman can have a baby in nine months does not imply that nine women can have a baby in one month.
——Adding people to software projects in which the tasks can't be divided and performed independently doesn't help. But if a project's tasks are partitionable, you can divide them further and assign them to different people, even to people who are added late in the project.
——When you plan the product initially, partition the product's capabilities into "must haves," "nice to haves," and "optionals." If you fall behind, prioritize the "optionals" and "nice to haves" and drop the ones that are the least important.
——For any project attribute, it's possible to measure that attribute in a way that's superior to not measuring it at all.
——If data is to be used in a scientific experiment, it must be quantified.To evaluate software-development methods, you must measure them. Statement like "This new method seems more productive" aren't good enough.
——Abnormal measurements in a routine are a warning sign that you should reexamine that routine, checkting for unusually low quality.
——Be sure that you ask for only as much information as is feasible to obtain, and keep in mind that data collection will always take a back seat to deadlines.
——The most successful technical companies combine elements of high-tech and high-touch. Programmers are more than organic reflections of their silicon alter egos.
2015-06-11 684 Managing Construction
——Talent and effort among individual programmers vary tremendously, as they do in all fields.
——Although specific ratios such as 25 to 1 aren't particularly meaningful, more general statements such as "There are order-of-magnitude differences among programmers" are meaningful and have been confirmed by many other studies of professional programmers.
——Good programmers tend to cluster, as do bad programmers, an observation that has been confirmed by a study of 166 professional programmers from 18 organizations.
——If you have to pay more to get a top-10-percent programmer rather than a bottom-10-percent programmer, jump at the chance. You'll get an immediate payoff in the quality and productivity of the programmer you hire, and you'll get a residual effect in the quality and productivity of the other programmers your organiztion is able to retain because good programmers tend to cluster.
——Managers of programming projects aren't always aware that certain programming issues are matters of religion. If you're a manager and you try to require compliance with certain programming practices, you're inviting your programmers' ire.
——The details of a specific standard are often less important than the fact that some standard exists. Don't set standards for your programmers, but do insist they standardize in the areas that are important to you.
——Conformity in minor matters of style in any area probably won't produce enough benefit to offset the effects of lower morale. If you find indiscriminate use of gotos or global variables, unreadable styles, or other practices that affect whole projects, be prepared to put up with some friction to improve code quality.
2014-06-12 689 Managing Construction
——Physical environment makes a big difference in productivity. The programmers who performed in the top 25 percent had bigger, quieter, more private offices and fewer interruptions from people and phone calls.
——In summary, if your workplace is a bottom-25 percent environment, you can realize about a 100 percent improvement in productivity by making it a top-25 percent environment.
——The spirit of the book is diametrically opposed to Machiavellian manipulation, however, and one of Carnegie's key points is the importance of developing a genuine interest in other people. Carnegie has a keen insight into everyday relationships and explains how to work with other people by understanding them better.
——Technically competent, technical current managers are rare. If you work for one, do whatever you can to keep your job. It's an unusual treat.
——"Managing your manager" means that you need to tell your manager what to do rather than the other way around. The trick is to do it in a way that allows your manager to continue believing that you are the one being managed.
——Good coding practices can be achieved either through enforced standards or through more light-handed approaches.
——Configuration management, when properly applied, makes programmers' jogs easier. This especially includes change control.
——Good software estimation is a significant challenge. Keys to success are using multiple approaches, tightening down your estimates as you work your way into the project, and making use of data to create the estimates.
——Measurement is a key to successful construction management. You can find ways to measure any aspect of a project that are better than not measuring it at all. Accurate measurement is a key to accurate scheduling, to quality control, and to improving your development process.
——Programmers and managers are people, and they work best when treated as such.
2015-06-15 696 Integration
——The term "integration" refers to the software-development activity in which you combine separate software components into a single system.
——The topic of integration is intertwined with the topic of construction sequence. The order in which you build classes or components affects the order in which you can integrate them—you can't integrate something that hasn't been built yet.
——If you construct and integrate software in the wrong order, it's harder to code, harder to test, and harder to debug. If none of it will work until all of it works, it can seem as though it will never be finished.
——One problem with phased integration is that when the classes in a system are put together for the first time, new problems inevitably surface and the causes of the problems could be anywhere.
——When the classes are finally combined and errors suface by the score, programmers immediately go into panicky debugging mode rather than methodical error detection and correction.
——In incremental integration, you write and test a program in small pieces and then combine the pieces one at a time.
——As you add pieces to it, the system grows and gains momentum in the same way that a snowball grows and gains momentum when it rolls down a hill.
——In phased integration, you integrate so many components at once that it's hard to know where the error is. It might be in any of the components or in any of their connections. In incremental integration, the error is usually either in the new component or int the connection between the new component and the system.
——Integration-order strategies come in a variety of shapes and sizes, and none is best in every case. The best integration approach varies from project to project, and the best solution is always the one that you create to meet the specific demands of a specific project.
问题：什么是自顶向下的集成？
——An important aspect of top-down integration is that the interfaces between classes must be carefully specified. The most troublesome errors to debug are not the ones that affect single classes but those that arise from subtle interactions between classes.
——In spite of these advantages, pure top-down integration usually involves disadvantages that are more troublesome than you'll want to put up with. It's not unusual for a low-level problem to bubble its way to the top of the system, causing high-level changes and reducing the benefic of earlier integration work.
2014-06-23 702 Integration
——The rigidity in pure top-down integration is completely arbitrary. It's hard to imagine anyone going to the trouble of using pure top-down integration.
——A good alternative to pure top-down integration is the vertical-slice approach. In this approach, the system is implemented top-down in sections, perhaps fleshing out areas of functionality one by one and then moving to the next area.
——In bottom-up integration, you write and integrate the classes at the bottom of the hierarchy first. Adding the low-level classes one at a time rather than all at once is what makes bottom-up integration an incremental integration strategy.
——The main problem with bottom-up integration is that it leaves integration of the major, high-level system interfaces until last. If the system has conceptual design problems at the higher levels, construction won't find them until all the detailed work has been done.
——Bottom-up integration requires you to complete the design of the whole system before you start integration. If you don't, assumptions that needn't have controlled the design might end up deeply embedded in low-level code, giving rise to the awkward situation in which you design high-level classes to work around problems in low-level ones.
问题：什么是三明治集成？
——Sandwich integration avoids the rigidity of pure bottom-up or top-down integration. It integrates the often-troublesome classes first and has the potential to minimize the amount of scaffolding you'll need.
问题：什么是面向风险的集成？什么是面向特性的集成？什么是T型集成？
——In T-shaped integration, you build and integrate a deep slice of the system to verify architectural assumptions, and then you build and integrate the breadth of the system to provide a framework for developing the remaining functionality.
——Like software-design approaches, they are heuristics more than algorithms, and rather than following any procedure dogmatically, you come out ahead by making up a unique strategy tailored to your specific project.
2014-06-24 706 Integration
问题：什么是每日构建和冒烟测试？
——Every file is compiled, linked, and combined into an executable program every day, and the program is then put through a "smoke test," a relatively simple check to see whether the product "smokes" when it runs.
——Treat the daily build as the heartbeat of the project. If there's no heartbeat, the project is dead.
——Different developers' code is allowed to get a little out of sync between these pulses, but every time there's a sync pulse, the code has to come back into alignment.
——The smoke test should be thorough enough that if the build passes, you can assume that it is stable enough to be tested more thoroughly.
——If the smoke test isn't kept current, the daily build can become an exercise in self-deception, in which a fractional set of test cases creates a false sense of confidence in the product's quality.
——Frequent integration sometimes forces you to break the construction of a single feature into multipel episodes. That overhead is an acceptable price to pay for the reduced integration risk, improved status visibility, improved test-ability, and other benefits of frequent integration.
——Make it clear from the beginning that keeping the build healthy is one of the project's top priorities. A broken build should be the exception, not the rule. Insist that developers who have broken the build stop all other work until they've fixed it.
——It might be more macho to start smoke tesing at the end of the day and call people in the middle of the night when you find problems, but it's harder on the team, it wastes time, and in the end you lose more than you gain.
问题：问什么在时间压力条件下，项目更需要每日构建？
——Under stress, developers lose some of their discipline. They feel pressure to take construction shortcuts that they would not take under less stressful circumstances. They review and test their own code less carefully than usual. The code tends toward a state of entropy more quickly than it does during less stressful times.
2015-06-25 709 Integration
——The larger the project, the more important incremental integration becomes.
——They aim to integrate each change with the latest build every couple of hours. For most projects, I think literal continuous integration is too much of a good thing.
——On medium-sized and large projects, there is value in letting the code get out of sync for short periods. Developers frequently get out of sync when they make larger-scale changes. They can then resynchronize after a short time.
——Specifying interfaces isn't an integration task, but verifying that they have been specified well is.
——Do developers check in their code frequently—going no more than a day or two between check-ins?
——A system's "physical design"—its hierarchy of files, directories, and libraries—significantly affects a development team's ability to build software. If you don't pay attention to the physical design, build times will become long enough to unermine frequent integration.
——The construction sequence and integration approach affect the order in which classes are designed, coded, and tested.
——The best integration approach for any specific project is usually a combination of top-down, bottom-up, risk-oriented, and other integration approached. T-shaped integration and vertical-slice integration are two approached that often work well.
——Daily builds can reduce integration problems, improve developer morale, and provide useful project management information.
2015-06-26 716 Programming Tools
——Use of a leading-edge tool set—and familiarity with the tools used—can increase productivity by 50 percent or more.
——Graphical design tools generally allow you to express a design in common graphical notations: UML, architecture block diagrams, hierarchy charts, entity relationship diagrams, or class diagrams.
——A design tool can enable you to move between higher and lower levels of abstraction. A design tool will check the consistency of your design, and some tools can create code directly from your design.
——Make templates available to the whole team at the beginning of the project, and the team will use them because they make its job easier—you get the consistency as a side benefit.
——A class-hierarchy generator produces information about inheritance trees. This is sometimes useful in debugging but is more often used for analyzing a program's structure or modularizing a program into packages or subsystems.
——Lint is a picky syntax and semantics checker you can find in many C/C++ environments.
——Some tools analyze your code and report on its quality. For example, you can obtain tools that report on the complexity of each routine so that you can target the most complicated routines for extra review, testing, or redesign.
——Refactorers make code changes quicker and less error-prone.
——A data dictionary is a database that describes all the significant data in a project. In many cases, the data dictionary focuses primarily on database schemas. On large projects, a data dictionary is also useful for keeping track of the hundreds or thousands of class definitions.
——Linkers typically can link files from multiple languages, allowing you to choose the language that's most appropriate for each part of your program without your having to handle the integration details yourself.
2015-06-29 721 Programming Tools
——The purpost of a build tool is to minimize the time needed to build a program using current versions of the program's source files. For each target file in your project, you specify the source files that the target file depends on and how to make it.
——Common build tools include the make utility that's associated with UNIX and the ant tool that's used for Java programs.
——When you build your program, the make tool checks all the dependencies you've describe and determines the files that need to be recompiled.
——Overall, build tools like make or ant substantially improve the time and reliablility of the average compile-link-run cycle.
——A good way to write high-quality code in a short amount of time is not to write it all but to find an open source version or buy it instead.
——Commonly available code generators write code for databases, user interfaces, and compilers. The code they generate is rarely as good as code generated by a human programmer, but many applications don't require handcrafted code.
——Using a code generator, you might be able to hack out a prototype in a few hours that demonstrates key aspects of a user interface or you might be able to experiment with various design approaches.
——During development, if you want to check memory fragmentation at the beginning of each routine, you can use a macro at the beginning of each routine. You might not want to leave the checks in production code, so for the production code you can redefine the macro so that it doesn't generate any code at all.
——An execution profiler watched your code while it runs and tells you how many times each statement is executed or how much time the program spends on each statement or execution path.
——Looking at the assembler code generated by your compiler shows you how efficiently your compiler translates hign-level-language code into machine code. It can tell you why high-level code that looks fast runs slowly.
——A first exposure to assembler is often a loss of innocence. When you see how much code the compiler creates—how much more than it needs to—you'll never look at your compiler in quite the same way again.
——Conversely, in some environments the compiler must generate extremely complex code. Studying the compiler output can foster an appreciation for just how much work would be required to program in a lower level language.
——The UNIX environment is famous for its collection of small tools with funny names that work well together: grep, diff, sort, make, crypt, tar, lint, ctags, sed, awk, vi, and others.
——One tribute to the success of the UNIX paradigm is the availability of tools that put a UNIX costume on other machines.
问题：为什么要构建自己的编程工具？
——Most good programmers would choose the first option one time out of a million and the second option in every other case. Building tools is part of the warp and woof of programming.
2015-07-03 729 Programming Tools
——Most medium-sized and large projects need special tools unique to the project. For example, you might need tools to generate special kinds of test, to verify the quality of data files, or to emulate hardware that isn't yet available.
——If you find yourself typing something longer than about five characters more than a few times a day, it's a good candidate for a script or batch file.
——For decades, tool vendors and industry pundits have promised that the tools needed to eliminate programming are just over the horizon. The first, and perhaps most ironic. tool to receive this moniker was Fortran.
——No matter what tools are available, programmers will have to wrestle with the messy real world; we will have to think rigorously about sequences, dependencies, and exceptions; and we'll have to deal with end users who can't make up their minds.
——As long as we have computers, we'll need people who tell the computers what to do, and that activity will be called programming.
——Good tools can reduce the more tedious aspects of software development, but they can't eliminate the need for programming, although they will continue to reshape what we mean by "programming".
2015-07-06 738 Layout and Style
——White space is of use only to human readers—your computer could interpret any of the three fragments with equal ease. Don't feel bad if you can't do as well as your computer!
——The Fundamental of Theorem of Formatting says that good visual layout shows the logical structure of a program.
——In practicing, prioritizing logical representation usually doesn't create ugly code—unless the logic of the code is ugly. Techniques that make good code look good and bad code look bad are more useful than techniques that make all code look good.
——There is a psychological basis for writing programs in a conventional manner: programmers have strong expectations that other programmers will follow these discourse rules. If the rules are violated, then the utility afforded by the expectations that programmers have build up over time is effectively nullified.
——The bottom line is that the details of a specific method of structure a program are much less important than the fact that the program is structured consistently.
——Good programmers should be open-minded about their layout practices and accept practices proven to be better than the ones they're used to, even if adjusting to a new method results in some initial discomfort.
——The best layout schmes hold up well under code modification. Modify one line of code shouldn't require modifying several others.
——Use white space to enhance readability. White space, including spaces, tabs, line breaks, and blank lines, is the main tool available to you for showing a program's structure.
——A well-written paragraph contains only sentences that relate to a particular thought. It shouldn't contain extraneous sentences. Similarly, a paragraph of code should contain statements that accomplish a single task and that are related to each other.
——Using blank lines is a way to indicate how a program is organized. You can use them to divide groups of related statements into paragraphs, to separate routines from one another, and to highlight comments.
——But regardless of how pretty it looks, six-space indentation turns out to be less readable. This is an example of a collision between aesthetic appeal and readability.
——Even experienced programmers don't answer confidently, and that's why you should use parentheses whenever there's any doubt about how an expression is evaculated.
2015-07-07 748 Layout and Style
——The controversy about formatting control structures arises in part from the fact that some languages don't require block structures. You can have an if-then followed by a single statement and not have a formal block.
——Consequently, many indentation problems are problems only because you have to compensate for poorly designed language structures.
——A good approach in languages that don't have pure blocks is to view the begin and end keywords (or { and } tokens) as extensions of the control construct they're used with. Then it's sensible to try to emulate the Visual Basic formatting in your language.
——Neither of the styles is foolproof, and each requires an occasional "reasonable and obvious" compromise.
——The layout of some program elements is primarily a matter of aesthetics. Layout of control structures, however, affects readability and comprehensibility and is therefore a practical priority.
——If you were to nest statements to two or three levels, double indentation would give you four or six levels of indentation. The layout that resulted would look more complicated than the actual code would be.
——A logical block—a group of statements that belong together—should be treated the way paragraphs in English are. Separate them from one another with blank lines.
2015-07-13 761 Layout and Style
——The discipline of putting blank lines throughout a program makes you think harder about which statements really belong together.
——One of the most vexing problems of program layout is deciding what to do with the part of a statement that spills over to the next line.
——Make it obvious that the part of the statement on the first line is only part of a statement. The easiest way to do that is to break up the statement so that the part on the first line is blatantly incorrect syntactically if it stands alone.
——When you break a line, keep things together that belong together: array references, arguments to a routine, and so on.
——In some cases you might be able to improve readability by fine-tuning the indentation or spacing, but be sure to keep the maintainability tradeoff in mind when you consider fine-tuning.
——For consistency with the other indentation guidelines as well as maintainability, treat groups of statements containing assignment operations just as you would treat other statement.
——Modern languages such as C++ and Java allwo multiple statements per line. The power of free formatting is a mixed blessing, however, when it comes to putting multiple statements on a line.
——With one statement to a line, it's easy to step through the code with line-oriented debuggers. If you have several statements on a line, the debugger executes them all at once and you have to switch to assembler to step through individual statements.
——With one to a line, it's easy to edit individual statements—to delete a line or temporarily convert a line to a comment. If you have multiple statements on a line, you have to do your editing between other statements.
——This is exactly the situation you're in when you debug a program: the code you overlook because you "recognize" it rather than read it can contain the error that's harder to find than it needs to be.
问题：代码风格的那些方面体现了不要隐藏复杂性的原则？
——Most good programmers need to think twice to understand expressions with side effects. Let them use their brain cells to understand the larger questions of how your code works rather than the syntactic details of a specific expression.
2015-07-15 772 Layout and Style
——A style that's preferable to declaring all variables in a big block is to declare each variable close to where it's first used. This reduces "span" and "live time" and facilitates refactoring code into smaller routines when necessary.
问题：C++中声明指针，*号为什么要放在变量旁而不是类型旁？
——Comments done well can greatly enhance a program's readability; comments done poorly can actually hurt it. The layout of comments plays a large role in whether they help or hinder readability.
——Unless your display space is at a premium, this is purely aesthetic judgement and you can make it accordingly. In this, as in many other areas, the fact that a convention exist is more important than the convention's specific detail.
——The endline approach is neat and aesthetically appealing. The main problem is that it takes a lot of work to maintain, and styles that hard to maintain aren't maintained.
——A class is like a chapter in a book. In a book, you start each chapter on a new page and use big print for the chapter title. Emphasize the start of each class similarly.
——In this example, so many things are highlighted with asterisks that nothing is really emphasized. The program become a dense forest of asterisks. Although it's more an aesthetic than a technical judgement, in formatting, less is more.
——Classes are a semantic language concept. Files are a physical operating-system concept. The correspondence between classes and files is coincidental and continues to weaken over time as more environment support putting code into databases or otherwise obscuring the relationship between routines, classes, and files.
——Separate each routine from other routines with at least two blank lines The blank lines are as effective as a big rows of asterisks or dashes, and they're a lot easier to type and maintain.
2015-07-16 781 Self-Documenting Code
——Code as if whoever maintains your program is a violent psychopath who knows where you live.
——A unit-development folder (UDF), or software-development folder (SDF), is an informal document that contains notes used by a developer during construction.
——The detailed-design document is the low-level design document. It describes the class-level or routine-level design decisions, the alternatives that were considered, and the reasons for selecting the approaches that were selected.
——The main contributor to code-level documentation isn't comments, but good programming style.
——Such code relies on good programming style to carry the greater part of the documentation burden. In well-written code, comments are the icing on the readability cake.
——Is the class's interface abstract enough that you don't have to think about how its services are implemented? Can you treat the class as a black box?
——Is the program written in terms of the problem domain as much as possible rather than in terms of computer-science or programming-language structures.
——Comments are easer to write poorly than well, and commenting can be more damaging than helpful.
2015-07-17 788 Self-Documenting Code
——Clearly, at some level comments have to be useful. To believe otherwise would be to believe that the comprehensibility of a program is independent of how much information the reader might already have about it.
——If you take the comment as sacred and the code as suspicious, you're in deep trouble. Actually, finding a disagreement between the comment and the code tends to mean both are wrong. The fact that some comments are bad doesn't mean that commenting is bad.
——If it's hard to comment, either it's bad code or you don't understand it well enough. Either way, you need to spend more time on the code, so the time you spent commenting wasn't wasted because it pointed you to required work.
——Poor comments are worse than no comments.
——If the code is so complicated that it needs to be explained, it's nearly always better to improve the code than it is to add comments. Make the code itself clearer, and then use summary or intent comments.
——A comment that summarizes code does just that: it distills a few lines of code into one or two sentences. Such comments are more valuable than comments that merely repeat the code because a reader can scan them more quickly than the code.
——A comment at the level of intent explains the purpose of a section of code. Intent comments operate more at the level of the problem than at the level of the solution.
——The three kinds of comments that are acceptable for completed code are information that can't be expressed in code, intent comments, and summary comments.
2015-07-21 796 Self-Documenting Code
——A commenting style that requires a lot of busy work is a maintenance headache. If the comments are hard to change, they won't be changed and they'll become inaccurate and misleading, which is worse than having no comments at all.
——The point is that you should pay attention to how you spend your time. If you spend a lot of time entering and deleting dashes to make plus signs line up, you're not programming; you're wasting time.
——Commenting done later takes more time because you have to remember or figure out what the code is doing instead of just writing down what you're already thinking about. It's also less accurate because you tend to forget assumptions or subtleties in the design.
——If you have to concentrate so hard on writing code that commenting interrupts your thinking, you need to design in pseudocode first and then convert the pseudocode to comments. Code that requires that much concentration is a warning sign.
问题：在技术浪潮前期，注释会影响性能的情况下，如何对待注释？
——If you use the Pseudocode Programming Process effectively, you'll probably end up with a comment for every few lines of code. The number of comments, however, will be a side effect of the process itself.
问题：哪两种情况下，有理由为单行代码添加注释？
——Comments should explain why the code works now, not why the code didn't work at some point in the past.
——Aside from a couple of special cases, endline comments have conceptual problems and tend to be used for code that's too complicated. They are alse diffifult to format and maintain. Overall, they're best avoided.
——Most comments in a well-documented program are one-sentence or two-sentence comments that describe paragraphs of code. They don't repeat the code—they describe the code's intent.
2015-07-22 805 Self-Documenting Code
——Another way of thinking about commenting at the level of intent is to think about what you would name a routine that did the same thing as the code you want to comment.
——If the code is good enough, it begins to read at close to the level of intent, encroaching on the comment's explanation of the code's intent. At that point, the comment and the code might become somewhat redundant, but that's a problem few programs have.
——It's nearly impossible for a comment that focuses on how an operation is done to explain the intent of the operation, and comments that tell how are often redundant.
——If this comment documents the whole block of code following the if test, it serves as a summary-level comment and it's appropriate to retain it as a section heading for the paragraph of code it references.
——Good comments tell the person reading the code what to expect. A reader should be able to scan only the comments and get a good idea of what the code does and where to look for a specific activity.
——Routines should be logically "flat," with all their activities on about the same logical level. If your code differentiates between major and minor activities within a routine, the routine isn't flat.
——If you've had to violate good programming style, explain why. That will prevent a well-intentioned programmer from changing the code to a better style, possibly breaking your code.
——Commenting tricky code is exactly the wrong approach to take. Comments can't rescue difficult code. Don't document bad code—rewrite it.
——If you have to ask yourself "Is this tricky?" it is. You can always find a rewrite that's not tricky, so rewrite the code. Make your code so good that you don't need comments, and then comment it to make it even better.
——The space before a control structure is usually a natural place to put a comment. If it's an if or a case statement, you can provide the reason for the decision and a summary of the outcome. If it's a loop, you can indicate the purpose of the loop.
——If a loop is complicated enough to need an end-of-loop comment, treat the comment as a warning sign: the loop might need to be simplified.
2015-07-23 809 Self-Documenting Code
——Coding conventions should encourage good practices; heavy routine headers do the oppposite.
——Follow the Principle of Proximity and put comments as close as possible to the code they describe. They're more likely to be maintained, and they'll continue to be worthwhile.
——The short summary statement should be present in virtually all routines except for simple Get and Set accessor routines.
问题：什么是接口假定？
——As you're writing the routine and realize that you're making an interface assumption, write it down immediately.
——Modifying global data is at least an order of magnitude more dangerous than merely reading it, so modifications should be performed carefully, part of the care being clear documentation. As usual, if documenting becomes too onerous, rewrite the code to reduce global data.
2015-07-27 819 Self-Documenting Code
——Describe the class's design philosophy, overall design approach, design alternatives that were considered and discarded, and so on.
——Can another programmer understand how to use a class without looking at the class's implementation? If not, class encapsulation is seriously at risk. The class's interface should contain all the information anyone needs to use the class.
——Class interface files should contain information needed to use the class but not information needed to implement or maintain the inner workings of the class.
——Authorship and primary responsibility for specific areas of source code becomes important on large projects.
——In the Book Paradigm, code and its documentation are organized into several components similar to the components of a book to help programmers get a high-level view of the program.
——By paying attention to the typographic principles of book design, you can get a 10 to 20 percent improvement in comprehension.
——The Book Paradigm emphasizes the importance of providing documentation that explains both the high-level and the low-level organization of your program.
——The top-level standard is ISO/IEC std 12207, Information Technology—Software Life Cycle Processes, which is the international standard that defines a life-cycle framework for developing and managing software projects.
——IEEE Software Engineering Standards Collection: the book is distillation of the expertise of hundreds of people at the top of their fields and would be a bargain at virtually any price.
——The source Forge website contains code for thousands of programs in C, C++, Java, Visual Basic, PHP, Perl, Python, and many other languages, all which you can download for free. Pragrammers can benefit from wading through the code on the website to see much larger real-world examples.
——The question of whether to comment is a legitimate one. Done poorly, commenting is a waste of time and sometimes harmful. Done well, commenting is worthwhile.
——Good code is its own best documentation. If the code is bad enough to require extensive comments, try first to improve the code so that it doesn't need extensive comments.
——Comments should say things about the code that the code can't say about itself—at the summary level or the intent level.
2015-07-28 822 Personal Character
——If you're a software engineer, your basic building material is human intellect and your primary tool is you. Rather than designing a structure to the last detail and then handing the blueprints to someone else for construction, you know that once you've designed a piece of software to the last detail, it's done.
——The whole job os programming is building air castles—it's one of the most purely mental activities you can do. Consequently, when software engineers study the essential properties of their tools and raw materials, they find they're studying people: intellect, character, and other attributes that are less tangible than wood, concrete, and steel.
——Your employer can't force you to be a good programmer; a lot of times your employer isn't even in a position to judge whether you're good. If you want to be great, you're responsible for making yourself great. It's a matter of your personal character.
——You can't do anything about your intelligence, so the classical wisdom goes, but you can do something about your character. And it turns out that character is the more decisive factor in the makeup of a superior programmer.
——Fully understanding an average program requires an almost limitless capacity to absorb details and an equal capacity to comprehend them all at the same time. The way you focus your intelligence is more important than how much intelligence you have.
——The people who are best at programming are the people who realize how small their brains are. They are humble. The people who are the worst at programming are the people who refuse to accept the fact that their brains aren't equal to the task. Their egos keep them from being great programmers.
问题：哪些好的编程实践是为了减少大脑负担？
——Empirically, however, it's been shown that humble programmers who compensate for their fallibilities write code that's easier for themselves and others to understand and that has fewer errors.
2015-07-30 825 Personal Character
——In the development of a superior programmer, curiosity about technical subjects must be a priority. The relevant technical information changes continually.
——The more aware you are of the development process, whether from reading or from your own observations about software development, the better position you're in to understand changes and to move your group in a good direction.
——If your workload consists entirely of short-term assignments that don't develop your skills, be dissatisfied. If you're working in a competitive software market, half of what you now need to know to do your job will be out of date in three years. If you're not learning, you're turning into a dinosaur.
——If you can't learn at your job, find a new one.
——One effective way to learn about programming is to experiment with programming and the development process.
——You're better off working with a short program to test a concept than you are writing a larger program with a feature you don't quite understand.
——One key to effective programming is learning to make mistakes quickly, learning from them each time. Making a mistake is no sin. Failing to learn from a mistake is.
——Human beings don't always discover clever problem-solving strategies themselves, even though the same strategies could readily be taught to the same people. The implication is that even if you want to reinvent the wheel, you can't count on success. You might reinvent the square instead.
——One especially good way to learn about programming is to study the work of the great programmers.
——Ask to look at the code of programmers you respect. Ask to look at the code of programmers you don't. Compare their code, and compare their code to your own. What are the differences? Why are they different? Which way is better? Why?
——Computer documentation tends to be poorly written and poorly organized, but for all its problems, there's much to gain from overcoming an excessive fear of computer-screen photons or paper products. Documentation contains the keys to the castle, and it's worth spending time reading it.
——Often the company that provides the language product has already created many of the classes you need. If it has, make sure you know about them. Skim the documentation every couple of months.
——If you read even one good programming book every two months, roughly 35 pages a week, you'll soon have a firm grasp on the industry and distinguish yourself from nearly everyone around you.
2015-07-30 829 Personal Character
——Good programmers constantly look for ways to become better. Consider the following professional development ladder.
——Level 1: Beginning A beginner is a programmer capable of using the basic capabilities of one language. Such a person can write classes, routines, loops, and conditionas and use many of the features of a language.
——Level 2: Introductory An intermediate programmer who has moved past the beginner phase is capable of using the basic capabilities of multiple languages and is very comfortable in at least one language.
——Level 3: Competency A competent programmer has expertise in a language or an environment or both. A programmer at this leel might know all theintricacies of J2EE or have the Annotated C++ Reference Manual memorized. Programmers at this level are valuable to their companies, and many programmers never move beyond this level.
——Level 4: Leadership A leader has the expertise of a Level 3 programmer and recognizes that programming is only 15 percent communicating with the computer and 85 percent communicating with people. Only 30 percent of an average programmer's time is spent working alone. Even less time is spent communicating with the computer. The guru writes code for an audience of people rather than machines. True guru-level programmers write code that's crystal-clear, and they do document it, too. They don't want to waste their valuable gray cells reconstructing the logic of a section of code that they could have read in a one-sentence comment.
——It's no sin to be a beginner or an intermediate. It's no sin to be a competent programmer instead of a leader. The sin is in how long you remain a beginner or intermediate after you know what you have to do to improve.
——How can you learn anything new if you pretend that you know everything already? You'd better off pretending that you don't know anything. Listen to people's explanations, learn something new from them, and assess whetehr they know what they are talking about.
——Remember that tesing can show only the presence of errors, not their absence. If you don't understand the program, you can't test it thoroughly. Feeling tempted to compile a program to "see what happens" is a warning sign. It might mean that you need to back up to design or that you began coding before you were sure you knew what you were doing.
——Truly excellent programmers learn how to work and play well with others. Writing readable code is part of being a team player.
2015-07-31 837 Personal Character
——Without standards and conventions on large projects, project completion itself is impossible. Creativity isn't even imaginable. Don't waste your creativity on things that don't matter. Establish conventions in non-critical areas so that you can focus your creative energies in the places that count.
——"Form is liberating," as the saying goes. Great architects work within the constraints of physical materials, time, and cost. Great artists do, too. A programming masterpiece requires just as much discipling.
——Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so that you don't have to answer so many questions about it.
——Hustle is extra, unnecessary effort. It shows that you're eager but not that you're getting your work done. It's easy to confuse motion with progress, busy-ness with being productive.
——The most important work in effective programming is thinking, and people tend not to look busy when they're thinking. If I worked with a programmer who looked busy all the time, I'd assume that he was not a good programmer because he wasn't using his most valuable tool, his brain.
——Persistence when you're stuck on a piece of new code is hardly ever a virtue. Try redesigning the class, try an alternative coding approach, or try coming back it later. When one approach isn't working, that's a good time to try an alternative.
——It's hard to know when to give up, but it's essential that you ask. When you notice that you're frustrated, that's a good time to ask the question.
——Older programmers tend to be viewed with suspicious not just because they might be out of touch with specific technology but because they might never have been exposed to basic programming concepts that became well known after they left school.
——In software, if you can't shake the habits of thinking you developed whiile using your former programming language or the code-tuning techniques that worked on your old machine, your experience will be worse that none at all.
——If a programmer hasn't learned C after a year or two, the next three years won't make much difference. This kind of "experience" has little relationship to performance.
——The bottom line on experience is this: if you work for 10 years, do you get 10 years of experience or do you get 1 year of experience 10 times? You have to reflect on your activities to get true experience.
——Those all-night programming stints make you feel like the greatest programmer in the world, but then you have to spend several weeks correcting the defects you installed during your blaze of glory.
——Good habits matter because most of what you do as a programmer you do without consciously thinking about it.
——The main way you become good or bad at what you do is by doing. What you do becomes habit, and over time your good and bad habits determine whether you're a good or a bad programmer.
——When you first learn something, learn it the right way. When you first do it, you're actively thinking about it and you still have an easy choice between doing it in a good way and doing it in a bad way. After you've done it a few times, you pay less attention to what you're doing and "force of habit" takes over.
——In programming, try to develop new habits that work. Develop the habits of writing a class in pseudocode before coding it and carefully reading the code before compiling it. You won't have to worry about losing the bad habits; they'll drop by the waytside as new habits take their places.
——Zen and the Art of Motorcycle Maintenance: Pirsig was working as a software technical writer when he wrote ZAMM, and his insightful comments apply as much to the psychology of software projects as to motorcycle maintenance.
——If programming is one of the most difficult intellectual challenges that humankind has ever faced, learning more about human mental capacities is critical to the success of the endeavor.
——The characteristics that matter most are humility, curiosity, intellectual honesty, creativity and discipline, and enlightened laziness.
——Many programmers don't actively seek new information and techniques and instead rely on accidental, on-the-job exposure to new information. If you devote a small percentage of your time to reading and learning about programming, after a few months or years you'll dramatically distinguish yourself from the programming mainstream.
——Good character is mainly a matter of having the right habits. To be a great programmer, develop the right habits and the rest will come naturally.
2015-07-31 841 Themes in Software Craftsmanship
问题：本书描述哪些管理软件复杂性的方法？
——Objected-oriented programming provides a level of abstraction that applies to algorithms and data at the same time, a kind of abstraction that functional decomposition alone didn't provide.
——The way in which people work together determines whether their abilities are added to each other or subtracted from each other. The process the team uses determines whether one people's work supports the work of the rest of the team or undercuts it.
——The process you use determines both how stable your requirements are and how stable they need to be. If you want to build more flexibility into the requirements, you can set up an incremental development approach in which you plan to deliver the software in several increments increments rather than all at once.
——My message to the serious programmer is: spend a part of your working day examining and refining your own methods. Even though programmers are always struggling to meet some future or past deadline, methodological abstraction is a wise long-term investment.
——If you rush to coding before the foundation is complete, it will be harder to make fundamental changes in the system's architecture. It's hard to throw away a bad foundation once you've started building a house on it.
——Premature optimization wastes time because you spend time polishing sections of code that don't need to be polished. Always be thinking, "Am I doing this in the right order? Would changing the order make a difference?" Consciously follow a good process.
——If you don't understand the creative process, you're not getting the most out of the primary tool you use to create software—your brain. A bad process wastes your brain cycles. A good process leverages them to maximum advantage.
2015-08-03 851 Themes in Software Craftsmanship
——You should go to the effort of writing good code, which you can do once, rather than the effort of reading bad code, which you'd have to do again and again.
——Habits affect all your work; you can't turn them on and off at will, so be sure that what you're doing is something you want to become a habit. A professional programmer writes readable code, period.
——No individual application of a technique can make the difference between a readable program and an illegible one, but the accumulation of many small readability improvements will be significant.
——Don't limit your programming thinking only to the concepts that are supported automatically by your language. The best programmers think of what they want to do, and then they assess how to accomplish their objectives with the programming tools at their disposal.
——Programming using the most obvious path amounts to programming in a langauge rather than programming into a language.
——Conventions save programmers the trouble of answering the same questions—making the same arbitrary decision—again and again.
——Having conventional ways of handling memory requests, error processing, input/ouput, and class interfaces adda meaningful structure to your code and makes it easier for another programmer to figure out—as long as the programmer knows your convetions.
——Another specific method of dealing with complexity is to work at the highest possible level of abstraction. One way of working at a high level of abstraction is to work in terms of the programming problem rather than the computer-science solution.
——Programs can be divided into levels of abstraction. A good design will allow you to spend much of your time focusing on only the upper layers and ignoring the lower layers.
——Programming is neither fully an art nor fully a science. As it's typically practiced, it's a "craft" that's somewhere between art and science.
——Exceptional performance requires working smart in addition to working hard. Lots of debugging on a project is a warning sign that implies people aren't working smart. Writing a lot of code in a day and then spending two weeks debugging it is not working smart.
——Doubt is an uneasy and dissatisfied state from which we struggle to free ourselves and pass into the state of belief.
——When you're deep into a program, pay attention to warning signs that indicate that part of the program design isn't defined well enough to code.
——If you're figuring out code instead of reading it, it's too complicated. If it's hard, it's wrong. Make it simpler.
——Projects fail because they commit themselves to a solution before exploring alternatives. Iteration provides a way to learn about a product before you build it.
——A first attempt might produce a solution that works, but it's unlikely to produce the best solution. Taking several repeated and different approaches produces insight into the problem that's unlikely with single approach.
2015-08-03 855 Themes in Software Craftsmanship
——Rather than latching on to the latest miracle fad, use a mixture of methods. Experiment with the exciting, recent methods, but bank on the old and dependable ones.
——If software development were a deterministic, algorithmic process, you could follow a rigid methodology to your solution. But software development isn't a deterministic process; it's heuristic, which means that rigid processes are inappropriate and have little hope of success.
——Adherence to a single method is also harmful in that it makes you force-fit the problem to the solutions. If you decide on the solution method before you fully understand the problem, you act prematurely.
——You have to treat the techniques as tools in a toolbox and use your own judgment to select the best tool for the job.
——A dogmatic stance conflicts with the eclectic toolbox approach to software construction. It's incompatible with the attitude needed to build high-quality software.
——Many of the inflexible approaches to software development are based on a fear of making mistakes. A blanket attempt to avoid mistake is the biggest mistake of all. Design is a process of carefullly planning small mistakes in order to avoid making big ones.
——The point is that you have to keep an open mind about all aspects of software development. You have to get technical about process as well as your product.
——Team programming is more an exercise in communicating with people than in communicating with a computer. Individual programming is more an exercise in communication with yourself that with a computer.
——The more you iterate in each development activity, the better the product of that activity will be.
——Dogmatic methodologies and high-quality software development don't mix. Fill your intellectual toolbox with programming alternatives, and improve your skill at choosing the right tool for the job.
2015-08-03 Done Where to Find More Information
——People have already made all the mistakes that you're making now, and unless you're a glutton for punishment, you'll prefer reading their books and avoiding their mistakes to inventing new versions of old problems.
——It's useful to have a core set that discusses each of the major software-development activities in depth: books on requirements, design, construction, management, testing, and so on.
——The Psychology of Computer Programming: Every manager of programmers should have his own copy. He should read it, take it to heart, act on the precepts, and leave the copy on his desk to be stolen by his programmers. He should continue replacing the stolen copies until equilibrium is established.
——Every practicing computer programmer or software engineer should have a high-level reference on software engineering. Such books survey the methodological landscape rather than painting specific features in detail.
——One of the best ways to learn more about programming is to get in touch with other programmers who are as dedcated to the profession as you are.