"A system that is comprehensively tested and passes all of its tests all of the time is a testable system. That’s an obvious statement, but an important one. Systems that aren’t testable aren’t verifiable. Arguably, a system that cannot be verified should never be deployed." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)
"Any comment that forces you to look in another module for the meaning of that comment has failed to communicate to you and is not worth the bits it consumes." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)
"Clean code is focused. Each function, each class, each
module exposes a single-minded attitude that remains entirely undistracted, and
unpolluted, by the surrounding details."
"Clean code is not written by following a set of rules. You
don’t become a software craftsman by learning a list of heuristics. Professionalism
and craftsmanship come from values that drive disciplines." (Robert C Martin, "Clean
Code: A Handbook of Agile Software Craftsmanship", 2008)
"Code formatting is important. It is too important to ignore
and it is too important to treat religiously. Code formatting is about
communication, and communication is the professional developer’s first order of
business."
"Duplication is the primary enemy of a well-designed system.
It represents additional work, additional risk, and additional unnecessary
complexity."
"Every system is built from a domain-specific language
designed by the programmers to describe that system. Functions are the verbs of
that language, and classes are the nouns."
"Good software designs accommodate change without huge
investments and rework. When we use code that is out of our control, special
care must be taken to protect our investment and make sure future change is not
too costly."
"If the discipline of requirements specification has taught
us anything, it is that well-specified requirements are as formal as code and
can act as executable tests of that code!"
"In an ideal system, we incorporate new features by extending the system, not by making modifications to existing code." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)
"Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. [… Therefore,] making it easy to read makes it easier to write." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)
"It is a myth that we can get systems 'right the first time'. Instead, we should implement only today’s stories, then refactor and expand the
system to implement new stories tomorrow. This is the essence of iterative and
incremental agility. Test-driven development, refactoring, and the clean code
they produce make this work at the code level."
"It is not enough for code to work. Code that works is often
badly broken. Programmers who satisfy themselves with merely working code are
behaving unprofessionally. They may fear that they don’t have time to improve
the structure and design of their code, but I disagree. Nothing has a more
profound and long-term degrading effect upon a development project than bad
code."
"It is unit tests that keep our code flexible, maintainable,
and reusable. The reason is simple. If you have tests, you do not fear making changes
to the code! Without tests every change is a possible bug."
"Nothing has a more profound and long-term degrading effect
upon a development project than bad code. Bad schedules can be redone, bad
requirements can be redefined. Bad team dynamics can be repaired. But bad code
rots and ferments, becoming an inexorable weight that drags the team down."
"One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. Professionals use their powers for good and write code that others can understand." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)
"One of the best ways to ruin a program is to make massive
changes to its structure in the name of improvement. Some programs never
recover from such “improvements.” The problem is that it’s very hard to get the
program working the same way it worked before the 'improvement'."
"Refactoring is a lot like solving a Rubik’s cube. There are
lots of little steps required to achieve a large goal. Each step enables the
next."
"Standards make it easier to reuse ideas and components,
recruit people with relevant experience, encapsulate good ideas, and wire
components together. However, the process of creating standards can sometimes
take too long for industry to wait, and some standards lose touch with the real
needs of the adopters they are intended to serve."
"The majority of the cost of a software project is in
long-term maintenance. In order to minimize the potential for defects as we
introduce change, it’s critical for us to be able to understand what a system
does. As systems become more complex, they take more and more time for a
developer to understand, and there is an ever greater opportunity for a
misunderstanding. Therefore, code should clearly express the intent of its
author. The clearer the author can make the code, the less time others will
have to spend understanding it. This will reduce defects and shrink the cost of
maintenance."
"The problem isn’t the simplicity of the code but the implicity of the code (to coin a phrase): the degree to which the context is not explicit in the code itself." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)
"There are two parts to learning craftsmanship: knowledge and work. You must gain the knowledge of principles, patterns, practices, and heuristics that a craftsman knows, and you must also grind that knowledge into your fingers, eyes, and gut by working hard and practicing." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)
"We do not want to expose the details of our data. Rather we
want to express our data in abstract terms. This is not merely accomplished by
using interfaces and/or getters and setters. Serious thought needs to be put
into the best way to represent the data that an object contains. The worst option
is to blithely add getters and setters."
"When people look under the hood, we want them to be impressed with the neatness, consistency, and attention to detail that they perceive. We want them to be struck by the orderliness. We want their eyebrows to rise as they scroll through the modules. We want them to perceive that professionals have been at work. If instead they see a scrambled mass of code that looks like it was written by a bevy of drunken sailors, then they are likely to conclude that the same inattention to detail pervades every other aspect of the project." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)
"Whether you are designing systems or individual modules, never forget to use the simplest thing that can possibly work." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)
"Yet attentiveness to detail is an even more critical
foundation of professionalism than is any grand vision. First, it is through
practice in the small that professionals gain proficiency and trust for
practice in the large. Second, the smallest bit of sloppy construction, of the
door that does not close tightly or the slightly crooked tile on the floor, or
even the messy desk, completely dispels the charm of the larger whole. That is
what clean code is about."
"You should choose a set of simple rules that govern the format of your code, and then you should consistently apply those rules. If you are working on a team, then the team should agree to a single set of formatting rules and all members should comply." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)
"Acceptance tests are not unit tests. Unit tests are written by programmers for programmers. They are formal design documents that describe the lowest level structure and behavior of the code. The audience is programmers, not business. Acceptance tests are written by the business for the business (even when you, the developer, end up writing them). They are formal requirements documents that specify how the system should behave from the business’ point of view. The audience is the business and the programmers." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)
"Coding is an intellectually challenging and exhausting
activity. It requires a level of concentration and focus that few other
disciplines require. The reason for this is that coding requires you to juggle
many competing factors at once."
"Following the principle of 'late precision', acceptance tests should be written as late as possible, typically a few days before the feature is implemented. In Agile projects, the tests are written after the features have been selected for the next Iteration or Sprint." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)
"For some reason software developers don’t think of debugging time as coding time. They think of debugging time as a call of nature, something that just has to be done. But debugging time is just as expensive to the business as coding time is, and therefore anything we can do to avoid or diminish it is good." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)
"One of the most common communication issues between programmers and business is the requirements. The business people state what they believe they need, and then the programmers build what they believe the business described. At least that’s how it’s supposed to work. In reality, the communication of requirements is extremely difficult, and the process is fraught with error." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)
"One of the worst symptoms of a dysfunctional team is when
each programmer builds a wall around his code and refuses to let other
programmers touch it."
"Programming is an act of creation. When we write code we are creating something out of nothing. We are boldly imposing order upon chaos. We are confidently commanding, in precise detail, the behaviors of a machine that could otherwise do incalculable damage. And so, programming is an act of supreme arrogance." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)
"Software development is a marathon, not a sprint. You can’t win the race by trying to run as fast as you can from the outset. You win by conserving your resources and pacing yourself. A marathon runner takes care of her body both before and during the race. Professional programmers conserve their energy and creativity with the same care." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)
"The cost of automating acceptance tests is so small in comparison to the cost of executing manual test plans that it makes no economic sense to write scripts for humans to execute. Professional developers take responsibility for their part in ensuring that acceptance tests are automated." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)
"The fact that bugs will certainly occur in your code does
not mean you aren’t responsible for them. The fact that the task to write
perfect software is virtually impossible does not mean you aren’t responsible for
the imperfection."
"The fundamental assumption underlying all software projects is that software is easy to change. If you violate this assumption by creating inflexible structures, then you undercut the economic model that the entire industry is based on." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)
"The purpose of acceptance tests is communication, clarity, and precision. By agreeing to them, the developers, stakeholders, and testers all understand what the plan for the system behavior is. Achieving this kind of clarity is the responsibility of all parties. Professional developers make it their responsibility to work with stakeholders and testers to ensure that all parties know what is about to be built." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)
"The second best way to learn is to collaborate with other people. Professional software developers make a special effort to program together, practice together, design and plan together. By doing so they learn a lot from each other, and they get more done faster with fewer errors." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)
"The true professional knows that delivering function at the expense of structure is a fool’s errand. It is the structure of your code that allows it to be flexible. If you compromise the structure, you compromise the future." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)
"True professionals work hard to keep their skills sharp and ready. It is not enough to simply do your daily job and call that practice. Doing your daily job is performance, not practice. Practice is when you specifically exercise your skills outside of the performance of your job for the sole purpose of refining and enhancing those skills." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)
"Unfortunately, all too many projects become mired in a tar pit of poor structure. Tasks that used to take days begin to take weeks, and then months. Management, desperate to recapture lost momentum, hires more developers to speed things up. But these developers simply add to the morass, deepening the structural damage and raising the impediment." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)
"When you cannot concentrate and focus sufficiently, the code you write will be wrong. It will have bugs. It will have the wrong structure. It will be opaque and convoluted. It will not solve the customers’ real problems. In short, it will have to be reworked or redone. Working while distracted creates waste." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)
"[…] you should not agree to work overtime unless (1) you can personally afford it, (2) it is short term, two weeks or less, and (3) your boss has a fall-back plan in case the overtime effort fails." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)
"Function or architecture? Which of these two provides the
greater value? Is it more important for the software system to work, or is it
more important for the software system to be easy to change?"
"Getting software right is hard. It takes knowledge and
skills that most young programmers haven’t yet acquired. It requires thought
and insight that most programmers don’t take the time to develop. It requires a
level of discipline and dedication that most programmers never dreamed they’d need.
Mostly, it takes a passion for the craft and the desire to be a professional."
"Software architects are, by virtue of their job description, more focused on the structure of the system than on its features and functions. Architects create an architecture that allows those features and functions to be easily developed, easily modified, and easily extended." (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)
"The bigger lie that developers buy into is the notion that
writing messy code makes them go fast in the short term, and just slows them
down in the long term. Developers who accept this lie exhibit the hare’s
overconfidence in their ability to switch modes from making messes to cleaning
up messes sometime in the future, but they also make a simple error of fact.
The fact is that making messes is always slower than staying clean, no matter
which time scale you are using."
"The goal of software architecture is to minimize the human
resources required to build and maintain the required system."
"What is OO? There are many opinions and many answers to this
question. To the software architect, however, the answer is clear: OO is the
ability, through the use of polymorphism, to gain absolute control over every
source code dependency in the system. It allows the architect to create a
plugin architecture, in which modules that contain high-level policies are
independent of modules that contain low-level details. The low-level details
are relegated to plugin modules that can be deployed and developed
independently from the modules that contain high-level policies."
"When software is done right, it requires a fraction of the human resources to create and maintain. Changes are simple and rapid. Defects are few and far between. Effort is minimized, and functionality and flexibility are maximized." (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)
"When we talk about software architecture, software is recursive and fractal in nature, etched and sketched in code. Everything is details. Interlocking levels of detail also contribute to a building’s architecture, but it doesn’t make sense to talk about physical scale in software. Software has structure - many structures and many kinds of structures-but its variety eclipses the range of physical structure found in buildings. You can even argue quite convincingly that there is more design activity and focus in software than in building architecture - in this sense, it’s not unreasonable to consider software architecture more architectural than building architecture!" (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)
No comments:
Post a Comment