This article is a "programmer practicing the Road" notes the second chapter summarizes some principles and common development model of efficient programmers need to comply with, for we have a very important significance. We recommend that every programmer should learn and master these principles. If you think this valuable series of articles, we can organize a pumping activity book, encourage them to learn from the original.
DRY principle
Software development process is accompanied at all times to maintain, if the project would have a lot of duplicate code our maintenance work caused a lot of trouble. For example: a piece of code in various places, we need to be modified once to modify multiple places at the same time, if somewhere forgot modification may cause some unnecessary mistakes. Therefore, the authors propose the DRY principle - Do not repeat yourself (do not repeat yourself) .
We usually have a lot of repetitive scenes, but also to avoid duplication solutions, the following few examples.
- Code Note: We often preach to comments in the code Riga. But the comment is not possible, we should leave the Senior Notes explanation for the relatively low-level instructions in code to replace the comment. Otherwise, there is repetition of knowledge, thought to be modified modify the code each time Notes
- Code and documentation: Updated documentation is always lagging behind the code, but the code is updated frequently forget to update the document. We can use some assistive technologies or self-development techniques, such as: the API doc, tools like Java doc, code updates, documentation will be updated with
- Design repeat: Suppose there is a class in the starting coordinates and ending coordinates of the two properties, when coupled with a distance between two points on the property a little repetitive, because we can calculate the distance based on the starting and ending point
- Temporary repeat: Sometimes we do some temporary needs of the project may be used in a piece of code, we generally use directly copied, this time there are repeated. More thorough approach is that we can put some of the more commonly used calculation logic abstracted interfaces, form their own kit, direct reference when needed without the need to copy the code. For example: Some common summation, like most value required for the processing logic loop is not a reduce function can be abstracted
- Between developers repeat: this is more common repeat, if two groups while developing a project is likely to cause the same logic in small groups of two members have their own implementation, which is not very good to avoid repetition. But we can increase communication between teams, we can organize a platform to open up some of the better components. Some udf often used to process data when I do data development, the current project if I did not, I would go to the company's common platform to search the appropriate keywords, general can find ready udf. I recommend comparing different open source project code within the team, of course, the premise does not involve confidential code. I often ask students in the development of how the upstream data processing, after what logic do so on the one hand increases the cost of communication, and secondly, after all hearsay is true. So I often go against the compiled code upstream, in the future need to look at the logic does not need to ask someone else, look at the code directly save a lot of time. Of course, open source also has the advantage that we can learn from others code outstanding place.
Orthogonal principle
Orthogonality is no interdependence or decoupling. If a change occurs two or more things, and does not affect other things, these things is orthogonal. Corresponds to programming, we often say that the high cohesion and low coupling . System benefits orthogonal very much, orthogonal system can reduce the risk, when a component to modify the system, as long as the external interface remains the same, the components can be freely modified and the whole system will not be affected. Orthogonal system productivity can be improved, because the system components are decoupled, so that individual components independently, parallel development. For example, in recent years, more fire before and after the end of the separation technology is well represented, before the back-end students often need to write some code that sets the front page, front and rear end classmates code intertwined interdependent. But before and after the end of the separation, just need to determine a good agreement, front and rear side technology can be decoupled, students can develop parallel development and increase productivity. Orthogonality maintained following is a list of several
- Design: We can design systems based layered architecture components. Each layer provides an abstraction, except that each protocol / between its level abstraction provided below, layers and scalable interface is stable, change the lower assembly of the upper transparent
- Code: In order to keep the deconstruction of the code, we can develop "shy" code, do not need to open up the logic, you can control their access rights, not be referenced by other components. Avoid the use of global data, global data relates to a plurality of consumers simultaneously updated, resulting in a higher degree of coupling assembly. Similar to avoid writing function, often have similar functions duplicate code, modify the code so to simultaneously update multiple
- Test: During unit testing, if a unit involved a large part of the rest of the system, indicating that the rest of the unit and the coupling of a larger system, need to attract attention to the development of students
Revocable principle
Revocable principle is that when a certain part of the system needs to be changed, we can not well withdraw existing code and flexible to adapt to the new changes. Because the demand is changing all the time, so there has been reversibility. For chestnut: Suppose we develop a database visualization software, is based on the needs of the beginning of Mysql, if we do not do hierarchical design, all the needs of local additions and deletions to change search our direct write JDBC code. But one day we underlying data to support the MongoDB how to do, because our JDBC code is distributed in the code of each module of the project, almost can not be undone, this time the system can only be rewritten. If we designed at the beginning of the data access layer as a component of the abstract, then simply call the upper abstract interface to operate the database. The benefit of this is when you need to support other databases, only support for our database to prepare the abstract interface code to access the database, so the system will have the revocable nature. In fact, we often use the Web project ORM framework is also based on the principle of revocable, ORM can map database tables to objects, additions and deletions to check the bottom of the upper transparent, so the flexibility to adjust the underlying database.
Tracer and prototype
Often used in the dark when the need to combat military targets tracer, it leaves a trail like fireworks between the gun and the local hit, and to indicate the target trajectory to assist the shooter trajectory correction. In fact, the dark goals as we develop in the face of the unknown system. The face of the unknown system, if we make a lot of documents, list them every need, try to determine all the unknown factors, it is unknown if the target is calculated in advance and then a lot of shooting in the dark, it is clear that this situation needs to consume large amounts of computing power and not be able to hit the target. The pragmatic programmers often prefer to use tracer bullets. Tracer's core strengths is the feedback is timely. For example: We want to develop a framework to support multiple RPC serialization format is not the best start we can start with a simple system default serialization framework to build up the whole system first, let the system can be up and running. After the run we can get timely feedback consumers, the problem has been repaired, increased variety of serialization framework to continuously iterative improvement.
Introduced over tracer come to talk about the prototype, I remember learning "software engineering" in contact with the university prototype development. More like a prototype Demo, does not focus on implementation code, but can quickly able to determine the demand for a product with something. For example: We need to determine the needs of a UI system, we can use the fastest development language, develop a Demo, its code does not require standardized, interactive interface does not require too beautiful, because the prototype does not follow the actual high probability the project implementation to use.
Then briefly summarize the difference between these two modes of development. Tracer emphasized that after the clear demands, we can develop a small but perfectly formed but the system to quickly get feedback to guide us further iterations. In the tracer development model, dependent on the subsequent code is the code of the first edition. The prototype is more focused on specific needs of this stage, the rapid development of a Demo, the purpose is to be able to determine the requirements based on the prototype system. At this stage what the code does not care, do not care about the integrity of the system, robustness and accuracy, because the basic prototype code will not be used in a real system development.
Language and estimate the field
这节内容我觉得平时应用不多，理解的不深刻，因此就简单总结。领域语言我的理解就是使用（创造）一门规范的伪代码，为什么是伪代码呢？假设我们与产品沟通需求，我们可以使用文字，但我们都知道中华文字博大精深，别人表达的意思跟我们的理解可能不一致，否则的话我们也不需要这么苦逼的加班，当然直接用编程语言沟通更不可行。那么就需要一个中间层的伪代码，既能清晰的表达出需求，又能让产品或者使用不同编程语言的程序员都能看懂。
对于估算这一节，作者介绍了一些常见的预估问题（估算项目时间、流量）的一些指导性意见，但感觉比较偏理论，实操性不强。但给我印象最深的一句话是：在咖啡机旁给出的估算将像咖啡一样回来纠缠你。也就是说估算不等于不假思索的回答，我们可以用 “这个问题我现在答复不了，我回去想下” 之类的话术先应付一下，后续再详细地思考。
小结
本章主要介绍了三个原则中，这三个原则如果在开发中加以总结和利用将对我们高效地开发非常有帮助。DRY 原则避免重复劳动，正交原则避免改动一个组件时牵扯整个系统的维护，可撤销原则避免更换系统某个组件时导致系统崩溃。最后，介绍了曳光弹和原型开发两种快速开发模式，尤其是曳光弹，我比较喜欢用，先小规模、小成本搭建骨架并跑起来，后续再不断地丰富骨肉，希望以上介绍的内容对你日后开发有帮助。
欢迎关注公众号「渡码」，我将分享更多优秀书籍的内容，组织定期抽书活动
