the proverb is to communicate life proverbs and universal truths in a concise and easy way to help you deal with life and work. It is for this reason that I have sorted out 10 programming proverbs, and every developer should remember them and arm themselves.
[b] 1. no wind and no waves [/b]
don't be nervous, this may be just a fire drill
code design is bad, from some places can be seen. For example,
a. superlarge or superlarge function
b. blockbusters are annotated with
c. logic repeating
d. If/else nested deep
programmers usually call them code odors (Code Smell), but I personally think the name "code alarm" is more suitable because it has a higher urgency. The meaning of the sense. The improper handling of the fundamental problem will eventually lead to fire.
Translation: the Chinese translation of Code Smell is generally called "code smell" or "code taste". It is a hint that there is a mistake somewhere in the prompt code. The developer can chase the problem in the code through this smell.
[b] 2. prevention mainly, the treatment is supplemented by [/b]
well, I believe!
1980s, Toyota Corporation's streamline line has become famous and efficient because of its innovation in defect prevention. Every member who finds problems in his department has the right to suspend production. This method is intended to identify problems and solve problems immediately after finding problems, and can not be caused by their continued production, resulting in more difficult and more costly repair / replacement / recall issues.
programmers always make productivity errors that are equivalent to fast coding. Many programmers will go straight to code design without thinking. Unfortunately, this kind of Leeroy Jenkins reckless approach can cause the software development to be slovenly, and bad code needs to be constantly monitored and modified - and can be completely replaced. In the end, the factors involved in productivity are not just the time spent on writing code, but also the time needed for debugging. A little careless will "pick up sesame and lose the watermelon". (because of a small loss.)
Translation: Leeroy Jenkins behavior: in WOW game, a player disregards everyone to be alone and meets the enemy.
[b]3. does not throw in a single throw of [/b] (overdepending on someone)
the common element of a software development team (bus factor) refers to the total number of core developers that will affect the entire project process. For example, if someone is hit by a car or a child or someone is jumping from job to job, the project may be out of order or even shelved.
Translation: bus factor refers to public elements, which describe some common factors in the development process. If the more factor is squeezed into bus, the more unstable the bus will be, so we must control the bus factor so as not to cause problems.
in other words, if your team suddenly loses a main member, what will you do? Does business continue or do it stop?
unfortunately, most software teams are caught up in the latter case. These teams develop their developers into "domain experts" who only deal with their own professional fields. At first, this seemed to be a more reasonable method. It is very applicable to automobile manufacturing assembly line, but why can't the software development team be able to do so? After all, it's not possible for every member to master the nuances of the program, right?
the problem is that developers are not easy to replace easily. While each member is available, the "drawer method" is very effective, but if the "domain expert" is suddenly unable to work because of personnel changes, diseases, or accidents, the drawer method is disintegrated. Therefore, it is essential for software teams to have seemingly redundant but important reserve forces. Code review, pair programming, and common code can be used successfully to create an environment in which each developer is at least familiar with the part of the system that is not good at the field.
[b] 4. kinds of melons, beans [/b]
[url=http://www.lupaworld.com/data/attachment/portal/201010/31/105323gkb1ruztdbbq6sj5.jpg:33i2jvfz]
[/url: 33i2jvfz] "practical programmer" There is a word in the book that explains the "broken window theory": don't leave "broken windows" (inferior design, wrong decision, or bad code). Find one to repair one. If there is not enough time for proper repairs, keep it first. Maybe you can put the problem code in the annotation, or display the "unrealized" message, or replace it with virtual data. Some measures have been taken to prevent further deterioration. This shows that the situation is still in control. we have seen neat and tidy systems collapse immediately after "broken windows". Although there are other factors that cause the collapse of the software (we are going to be in touch elsewhere), it is sure to speed up the collapse of the system faster by ignoring the "broken window".
in short, good code will promote good code, and bad code will also lead to bad code. Do not underestimate the power of inertia. No one wants to sort out bad code, and no one wants to mess up the perfect code. If you write your code, it will be more likely to stand the test of time.
Translation: Pragmatic Programmer, author Andrew Hunt / David Thomas. The book goes straight to programming, through the growing specifications and technical barriers in software development, to examine the core process - that is, to create code that users are willing to accept, work and easy to maintain according to the requirements. This book contains content from personal responsibility to career development until the code technology is flexible and adaptable to reuse. From this book, you will learn to prevent software deterioration, eliminate the trap of replicating knowledge, write flexible, dynamic and easy to adapt code, avoid the same design, contract, assertion, and exception to code protection.
Translation: Broken Window Theory: a kind of understanding about the environment's suggestive or inductive influence on people's psychology. The "broken window effect" theory means that if someone breaks the window glass of a building, and the window can not be repaired in time, others may be subjected to some suggestive connivance to break more windows. The problem is to be corrected and remedied in time.