"An algorithm gives you the instructions directly. A heuristic tells you how to discover the instructions for yourself, or at least where to look for them." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"At the software-architecture level, the complexity of a problem is reduced by dividing the system into subsystems. Humans have an easier time comprehending several simple pieces of information than one complicated piece." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"Because successful programming depends on minimizing complexity, a skilled programmer will build in as much flexibility as needed to meet the software's requirements but will not add flexibility - and related complexity - beyond what's required." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"By far the most common project risks in software development are poor requirements and poor project planning, thus preparation tends to focus on improving requirements and project plans."(Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"Complexity in all forms - complicated algorithms, large data sets, intricate communications protocols, and so on - is prone to errors. If an error does occur, it will be easier to find if it isn't spread through the code but is localized within a class. Changes arising from fixing the error won't affect other code because only one class will have to be fixed - other code won't be touched. If you find a better, simpler, or more reliable algorithm, it will be easier to replace the old algorithm if it has been isolated into a class. During development, it will be easier to try several designs and keep the one that works best." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"Design is sloppy because a good solution is often only subtly different from a poor one." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"Encapsulation says that, not only are you allowed to take a simpler view of a complex concept, you are not allowed to look at any of the details of the complex concept. What you see is what you get - it's all you get!" (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"From time to time, a complex algorithm will lead to a longer routine, and in those circumstances, the routine should be allowed to grow organically up to 100–200 lines. (A line is a noncomment, nonblank line of source code.) Decades of evidence say that routines of such length are no more error prone than shorter routines. Let issues such as the routine's cohesion, depth of nesting, number of variables, number of decision points, number of comments needed to explain the routine, and other complexity-related considerations dictate the length of the routine rather than imposing a length restriction per se." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"If you're passing a parameter among several routines, that might indicate a need to factor those routines into a class that share the parameter as object data. Streamlining parameter passing isn't a goal, per se, but passing lots of data around suggests that a different class organization might work better." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"In software, consultants sometimes tell you to buy into certain software-development methods to the exclusion of other methods. That’s unfortunate because if you buy into any single methodology 100 percent, you’ll see the whole world in terms of that methodology. In some instances, you’ll miss opportunities to use other methods better suited to your current problem." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"[...] inheritance is a powerful tool for reducing complexity because a programmer can focus on the generic attributes of an object without worrying about the details. If a programmer must be constantly thinking about semantic differences in subclass implementations, then inheritance is increasing complexity rather than reducing it." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"Inheritance is the idea that one class is a specialization of another class. The purpose of inheritance is to create simpler code by defining a base class that specifies common elements of two or more derived classes. The common elements can be routine interfaces, implementations, data members, or data types. Inheritance helps avoid the need to repeat code and data in multiple locations by centralizing it within a base class. When you decide to use inheritance, you have to make several decisions: For each member routine, will the routine be visible to derived classes? Will it have a default implementation? Will the default implementation be overridable? For each data member (including variables, named constants, enumerations, and so on), will the data member be visible to derived classes?" (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"Modularity's goal is to make each routine or class like a 'black box': You know what goes in, and you know what comes out, but you don't know what happens inside." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"The concept of modularity is related to information hiding, encapsulation, and other design heuristics. But sometimes thinking about how to assemble a system from a set of black boxes provides insights that information hiding and encapsulation don't, so the concept is worth having in your back pocket." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"The underlying message of all these rules is that inheritance tends to work against the primary technical imperative you have as a programmer, which is to manage complexity. For the sake of controlling complexity, you should maintain a heavy bias against inheritance." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"One of the main differences between programs you develop in school and those you develop as a professional is that the design problems solved by school programs are rarely, if ever, wicked." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"Programming assignments in school are devised to move you in a beeline from beginning to end. You'd probably want to tar and feather a teacher who gave you a programming assignment, then changed the assignment as soon as you finished the design, and then changed it again just as you were about to turn in the completed program. But that very process is an everyday reality in professional programming." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don't improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software development techniques you use determine how many errors testing will find. If you want to lose weight, don't buy a new scale; change your diet. If you want to improve your software, don't test more; develop better." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction", 1993)
"The more independent the subsystems are, the more you make it safe to focus on one bit of complexity at a time. Carefully defined objects separate concerns so that you can focus on one thing at a time. Packages provide the same benefit at a higher level of aggregation." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"The most challenging part of programming is conceptualizing the problem, and many errors in programming are conceptual errors." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)
"Even when you have skilled, motivated, hard-working people,
the wrong team structure can undercut their efforts instead of catapulting them
to success. A poor team structure can increase development time, reduce
quality, damage morale, increase turnover, and ultimately lead to project
cancellation." (Steve McConnell, "Rapid Development", 1996)
"Motivation is undoubtedly the single greatest influence on
how well people perform. Most productivity studies have found that motivation
has a stronger influence on productivity than any other factor."
"It's better to wait for a productive programmer to become
available than it is to wait for the first available programmer to become
productive." (Steve McConnell, "Software Project Survival Guide", 1997)
"Software projects fail for one of two general reasons: the
project team lacks the knowledge to conduct a software project successfully, or
the project team lacks the resolve to conduct a project effectively."
"The default movement on a software project should be in the
direction of taking elements of the software away to make it simpler rather
than adding elements to make it more complex."
"The job of the average manager requires a shift in focus
every few minutes. The job of the average software developer requires that the
developer not shift focus more often than every few hours."
"Trying to apply formal methods to all software projects is
just as bad as trying to apply code-and-fix development to all projects." (Steve
McConnell, "After the Gold Rush: Creating a True Profession of Software
Engineering", 1999)
"A brute force solution that works is better than an elegant solution that doesn't work." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)
"Building software implies various stages of planning, preparation and execution that vary in kind and degree depending on what's being built." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)
"Design patterns provide the cores of ready-made solutions that can be used to solve many of software’s most common problems. Some software problems require solutions that are derived from first principles. But most problems are similar to past problems, and those can be solved using similar solutions, or patterns." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)
"In addition to their complexity-management benefit, design patterns can accelerate design discussions by allowing designers to think and discuss at a larger level of granularity." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)
"In software, the chain isn't as strong as its weakest link; it's as weak as all the weak links multiplied together." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)
"Design is heuristic. Dogmatic adherence to any single methodology hurts creativity and hurts your programs." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)
"On small, informal projects, a lot of design is done while the programmer sits at the keyboard. 'Design' might be just writing a class interface in pseudocode before writing the details. It might be drawing diagrams of a few class relationships before coding them. It might be asking another programmer which design pattern seems like a better choice. Regardless of how it’s done, small projects benefit from careful design just as larger projects do, and recognizing design as an explicit activity maximizes the benefit you will receive from it." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)
"Simplicity is achieved in two general ways: minimizing the amount of essential complexity that anyone's brain has to deal with at any one time, and keeping accidental complexity from proliferating needlessly." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)
"A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)
"Be sure you understand whether you're presenting
uncertainty in an estimate or uncertainty that affects your ability to meet a
commitment."
"Don't expect better estimation practices alone to
provide more accurate estimates for chaotic projects. You can't accurately
estimate an out-of-control process."
"Don't intentionally underestimate. The penalty for
underestimation is more severe than the penalty for overestimation. Address
concerns about overestimation through planning and control, not by biasing your
estimates."
"Not all estimation methods are equal. When looking for
convergence or spread among estimates, give more weight to the techniques that
tend to produce the most accurate results."
"Treat estimation discussions as problem solving, not
negotiation. Recognize that all project stakeholders are on the same side of
the table. Everyone wins, or everyone loses."
"The primary purpose of software estimation is not to predict a project's outcome; it is to determine whether a project's targets are realistic enough to allow the project to be controlled to meet them." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)
No comments:
Post a Comment