Home > Industries > Software
Read the catalogue:
Recently, there has been a new understanding of software development, which is derived from the book "UML and Pattern Application","lean and agile development of large-scale application ", which has read two books of Craig Larman in succession. And the company's current project situation these two things collided with the perception of the cause.
First of all, why would you want to see Craig Larman Master Books. In fact, I have collected thousands of books, in various e-commerce platforms have accounts, the purpose is only one is the collection of good books. The house is piled up a lot, nothing to browse the new book is My greatest pleasure now. I believe that I am not alone in this kind of feeling and hobby, and it is normal for the IT industry to pile up dozens of books at home.
Many books sometimes do not know what to see is also very normal, my principle is to adjust at any time to see the current dilemma. Based on my previous experience, it is easiest for you to have new insights and improvements to find answers in the face of practical problems. I believe that the book has its own gold house, the book has its own Yanruyu, in the right time to read the book, White is in confusion when you go to find the answer to this book. Why should look at Craig Larman Master's book, is because the recent work content has many oneself do not understand the place, hoped can pass the master's guidance to have the sentiment, indeed benefited greatly.
legacy code , technical debt , Span style= "text-decoration:underline;" > Project management , Project quality , , rapid development , refactoring , , Agile development , scrum , XP , you may be a little confused, some things are repetitive, such as project management contains project quality, development progress, such as agile development and scrum and XP, it seems that I am in a large concept of disassembly into a number of small repetition concept. The reason I do this is because I want to emphasize the difference between these concepts and the real interaction, from the artistic perspective of software craftsmen to really look at these concepts. For example, does the quality of the project have anything to do with code, is there a relationship between development progress and legacy code, project management has something to do with technical debt, and so on, the nature of these issues is completely different, As a technician, especially the application development of technical personnel must emphasize the concept, must understand the different concepts of the essential meaning, if you do not emphasize the concept I think your code is not good, the understanding of the business will not be profound.
Recently I have set my technical career goal as "software craftsman", in fact, I do not care about the title, I only care about their work content is what. Software craftsmen do not have boundaries, as long as the software development is related to the content of the craftsmen need to go to the field of research. If a craftsman leaves the tool, it loses the true value of the craftsman, so never give up writing code. Whether you are an architect or a development manager, the code is always the final design of the product, and once you get away from it, the quality of the product is getting farther and further behind, I'll also explain why the code is so important.
2. Project management, quality, measurement, progressThe title of this section is unwelcome, do you know why. Technical staff are able to understand, have a 5-10-year development of the birth of the manager is also able to understand, the only thing not to understand is not too much development experience of managers, or those who do not like the development of managers, those who evade the development of managers, because they are far from the real product realization, They are too far away from the real problem of software development, management once ignore the code quality problems will slowly find you, your project the quality of the more uncontrollable, the measurement, development progress will encounter bottlenecks.
say a present phenomenon, I engaged in the development of the first-line for several years, and continue to see a lot of people transferred to management , but you will find that the people who do the management are generally technical people. , or people who don't have much to pursue with technology, it's even more exaggerated that managers in some small companies may not have written code.
Why this phenomenon occurs, in fact, there are two main reasons, the first is the personal career planning, is the company's value-oriented. First of all, the value-oriented, often write code of the value of people without the value of project management, which in some small and medium-sized companies are still very common, real science and technology companies such problems almost no. And career planning is completely acceptable, after all, everyone's interest and pursuit of different, this is understandable, should respect everyone's choice. But the problem here is that once a technician without too much technical knowledge sits on the project manager's post, the technical understanding is 360-degree turn. This is not true, the success or failure of the project can not be neglected technology.
Do not continue to discuss this topic, this is not the focus of this article, Rengeyouzhi, the choice is normal, but to understand that the essence of choice is not value-oriented, but interest-oriented, which will not let you neglect another angle, because the ultimate success of a software product is to rely on project management and software engineering joint efforts, Indispensable.
Here to talk about the three important aspects of project management, quality, measurement, progress. First of all, I am not a professional project manager, but I am a professional software engineer, I do not know what the specific content of project management, but I know that the ultimate goal of project management and software engineering goals are consistent, are for the project high-quality completion.
The success or failure of the project is not solved by project management, if you can not appear "Software Engineering","design originally" . To ensure that the real success of the software project is required to support the development of engineering, and management is to develop the organization, coordination, communication, which is two levels of two angle interaction. There is no design, abstraction, maintainability, etc. in project management.
Here is especially to discuss the quality of software projects, it seems to measure the quality of the software project ignores the quality of the code, customer acceptance, functional completion, stable on-line, no delay, this is the completion of a project, we have neglected one is the quality of the code, why should care about the quality of the code.
Metrics, metrics are data visualizations of all occurrences within the development cycle, number of bugs, release returns, number of lines of code (more special), number of requirements changes, and so on, some of which I'm not too clear about metrics, and there should be a lot of it. The purpose of the measure is to be able to improve the quality of all aspects of the project and to control the various unstable aspects after the data has been released.
Development progress, "quality" in a paragraph I finally threw out a question "why care about the quality of the code"because he directly determines the progress of your project, and when your code quality is getting worse, you lose control of the progress of the project. Your metrics are meaningless, even if you can count the number of bugs to rise, but you can't control the number of bugs, because you're too far off the normal route, even if you can control the speed and number of changes, but you can't control the speed and frequency of the code that adapts to the change. Changes are unavoidable, and your code cannot face these complex changes because your code is not designed but is stacked. Finally, the quality of your project is not very good assurance.
(Figure 1: The integration of project management and software engineering is the complete software development)
Recently, the book "The Art of Code Change ", by Michael C. Feathers, has been a great sensation. It said that when we face the legacy code, how much time and effort is needed to add a new feature, how high is the probability of an obvious bug, and how likely the hidden bug will be. Legacy code directly determines the aspects of the above three project management. Michael C. Feathers has emphasized a lot about the relationship between project management and code quality that I've talked about, and this book is worth seeing.
In fact, the development of software development is the software engineering, development methodology, project management is only auxiliary to software engineering in time and space effective implementation.
Here is the difference between project management and team management, these two things are not the same. Project management basically does not require software engineering support, but team management in some areas requires software engineering support to do better.
3. Software development is a design activity rather than a building activityThe software design and architecture is described in the book "Lean and Agile development large-scale application practice":
1: "The software architecture draws on the architecture of the building, but the results confirm that this is an inappropriate analogy and that it has interesting side effects on software development." The building is hard, because in this field, the design is carried out only once before construction, and then the building or design is almost permanent. Note that architects and construction workers are different. But software is not a building, software is soft, and programming is not the process of construction, "software Architecture" is just a lot of metaphor list can choose a less perfect analogy only ".
2: "... The only software document that really seems to meet the engineering requirements is the source code.
3: "I realized that charts and documents are not real designs, and that the source code is the real design." Reiterate again "... The only software document that really seems to meet the engineering requirements is the source code.
These words are enough to prove that software development is a very complex process, a mind-intensive mental activity, and is embodied in every coding process. In many project management is that software development is a very simple activity, the main architecture design good coding is relatively simple, is it really so, we look at the book How to say:
1: "Source code is the real blueprint".
2: "Where is the true architecture, whether good or bad, intentional or accidental?" In a document maintained by the architecture team? Or is it in tens of thousands of files? Obviously the latter, the source code is the real design, and its sum reflects the real large design or architecture. Architecture is architecture, not someone's will. "
now many developers have a clear technical understanding error is that "write code" is a relatively simple activity. The complex is the software architecture, as long as the architecture is designed to write code should be a programmer's business, there is obviously a wrong value, that people write code is cheap, do not have any design and create new. This is actually a very unprofessional view. Really think that a simple ppt, a Word document in the schema diagram represents the schema. In fact, this idea is very naïve and superficial. In the words of the master Craig Larman , in the entire software lifecycle, the complex is to write code, and the code is the schema, so the architecture is code. Your original understanding of the architecture is the real difficult place is actually the code is really difficult place, not floating on the surface, so as to be more grounded gas can be truly valuable.
Architects should go deep into the first line to participate in some development, then will find a lot of problems, and then bring the problem to the location of the architecture, with architectural perspective design, in person to bring this solution to the front line, this is the framework of a technical solution to the right way.
Software development is a design activity, not a building activity, the software is constantly changing, and once the building is finalized, it will not change.
4. Rapid development (simple system architecture and complex business models)I'd like to talk about rapid development in this section. The understanding of rapid development in the circle is largely aligned with the rapid development framework and feels that there should be a framework to support rapid development. Rapid development can be done with a single framework. Such views or ideas are in fact wrong, and the understanding of rapid development is too narrow.
"Design originally" author, computer science giant Frederick P. Brooks said, there is no shot for software development, there is no so-called to use simple hair method to develop complex systems. The more complex the system is not easy to develop, the complexity of developing a system for 100 people to use and developing a system that satisfies 1000 people is completely different. Quantitative change caused by qualitative change, when the volume of business, traffic, data, and so on these software indicators beyond a certain extent, and the original design completely different, design ideas are completely different.
Back to the present. I now often face such a problem, I am now engaged in the business is more complex, the design requirements for the system is very high. If the dosage to the analogy, in fact, I now face the volume of business is relatively large, business volume of business complexity in fact, compared to the amount of traffic, data volume in the design method is much more difficult. Usually architects will only consider concurrency, traffic, and neglect the volume of business, such as business variability, business scalability, the complexity of the business itself, especially in the postgraduate examination of the design ability, test abstract ability. It doesn't really matter what kind of database you use in any programming language. You use OO, entity relationships in your head, and design thinking that doesn't matter with a specific technical framework.
The volume of business is much higher for writing code, and it is hard to land on several other quantities. The amount of traffic and concurrency can be solved by tuning the infrastructure to optimize the upgrade, while the business volume of the problem domain is the business logic, is the domain model, the business domain currently facing, any small business needs to be reflected in the code.
Recently I have been doing some work on system refactoring, just two days ago I reconstructed a piece of code, not the basic code, is the business logic code. That's probably the case.
There is an important domain concept in the system "weight", the concept of weight has a lot of business volume of qualitative change possibility, that is, it is not simply unchanged, there are changes at any time, when we expand the category immediately change.
The definition of weight is this: weight = single piece weight x number, it looks like very simple appearance, in fact, it is not, the single-piece weight here will change, sometimes it is reserved 3 decimal places sometimes is reserved 6 decimal places. And this weight of business logic is needed in more than n places, look at the code down about dozens of places are repeating the "weight" of the business logic.
I later reconstructed the business model with the help of my co-workers, why I don't use business logic to describe my refactoring work, because I think business is not a process, if the "business logic" to think about the business will create an illusion is "procedural" code structure. So I think of any business is "model-driven development" approach, the business to be abstracted as a model to reuse, extend, anti-variability. This is actually the essence of ooa/d. Business logic is just a small piece of a small piece of concrete action in the model, it is used within the scope of the model, and can not be a business logic, business logic is too small and easy to abstract.
(Figure 2: Weight, one-piece weight model)
I used the model above to reconstruct the weight business model. The concept of weight, single-piece weight, and different type of single-piece weight, which is very important, is presented to ensure that these important domain models are not overwhelmed by procedural code. And the business logic of creating weight and single-piece weight is encapsulated in two factories. After doing so, our model has a resistance to variability, and later, if there is any change in the creation logic of the weight, we can process it in weightfactory, If there is a new category expansion, we need to deal with one-piece heavy-related processing we only need to extend the next itemcategory and Pieceweightfactory two models. If you need to be fully configured, the model is more valuable at this time. For example, we can take iitemcategory out and automatically generate the relevant type when the category expands, and if you think this is not perfect, we can further pieceweightfactory the " Create Pieceweight (Decimal) according to Itemcategory, and make the "mapper model" in the configuration.
Here you will find a very wonderful place is that once the model of the business changes caused by the qualitative change can be through the gradual reconstruction model, extraction model, the essence of the model to solve.
Therefore, the simple system structure is unable to represent the complex business model, if possible, the OO language will not develop into today's like this. Complex business can not be solved by simple system structure or the so-called simple rapid development Framework and other things.
5. The business understanding of the technician and the final business model of the product manager's business understandingMost of the time we are emphasizing "more about the business, more familiar with the business", in a business-driven company This is necessary, any role in the company's units need to be familiar with the company's business scope. This is no problem, I want to say that the different roles for the business understanding of the final business model is different.
Whether in the traditional software enterprises or Internet enterprises, we have to use software to serve us or customers, of course, here is the business system. Business system is the core of business, the spirit of the system is the business model and the relationship between the model.
What I want to say in this section is that the technician goes after the business and the product manager to understand what the final business model is after the business. The technician and the product manager are different roles, with different professional backgrounds, different knowledge structures and professional degrees. There is a common understanding that the technical staff understand the business after the business with the product manager understand the final model is the same, what is it? It is impossible to abstract the business, presumably the business, the scene of the business, not landing into the system of business. At this point, the technician did not use their professional degree to abstract and model the business, and did not directly bring real value, but in the conversation and understanding the need to feel the value of the illusion.
Technical personnel can not be business technology in fact, the company said, "when the technical staff to understand the value of the business is huge" is not accurate.
5.1. Business understanding of the product (business process, data flow and scenario)Product understanding of the business as a whole, including business processes, data flow, scenarios, in their brains is the real business scenario, is the business scenario that must be restored, not be able to have any other models in mischief. If the product uses any other knowledge to abstract and enforce understanding of the business, there will be problems.
The final model of a product for a business is a business process, a data flow, and a scenario that does not require performance.
(Figure 3: Business understanding of the product final model-business flowchart)
Because the data flow chart is relatively simple, the current example will only have "orders" of the data entity, draw out a little meaning, I just draw a business flow chart to express the meaning can be.
To this extent, it is impossible to directly drop the flowchart on the system, it is a process to actually write software to evolve, and the following part of the process is the technical staff to understand the value and role of the business to play.
5.2. Business understanding of technical staff (domain model, design model, abstract modeling)Technical knowledge of the business to be focused on, you understand the business and product understanding of the business is not the same, the technical staff need to end the business of technology. The final business model of the technician is to have the correct model to refer to, take "create order" this process, waiting for the technician to extract and abstract things are more complex, need to combine a lot of knowledge to carry out design activities.
For example, you need to combine the "four-color prototype" model to extract "order" models, including "Order type", "Order tracking", need to combine design patterns to abstract "Create order Logic", according to "different order types to create different final orders." There is also the need to abstract the design model, such as creating orders, how each object interacts, and what the inputs and outputs of each interaction are. These require a technician to understand the business model that should be available after the business, and if the model needs to be linguistically, it needs to be modeled in conjunction with UML.
If the technician understands the business and the product Manager understands the business after the result is the same, then the technician has to understand what the value is. Technical staff understand the business to systematize the various business models to the specific field or sub-service subsystem, and then the various systems and services are how to interact, the logical attribution in the end which side. Finally, the code you write is the code model that satisfies the business, and the core competitive business system is different from the non-core competitiveness of the system gap.
When a technician understands the business, it starts by creating a domain model sketch for different business scenarios, and then creating a design model sketch based on the domain sketch, which is, of course, an agile iterative process.
(Figure 4: "Create order" related domain model)
With the domain model, you need to create a design model, which is a collaborative relationship between the various models. It is also emphasized that this is a fast iterative process and does not regard it as a waterfall dependent process. The essence of the domain model is also endless, when the design model of the process will have a complementary inspiration to the domain model, at this time can not be dogmatic, to fast the essence of the domain model and then the process of design model.
(Figure 5: "Create order" related design model)
Based on domain model, the object collaboration model is created in the design model, and the design model is not only a collaboration model but also other. The collaboration model is necessary and most important. With the collaboration model, we can walk through a scenario that satisfies the business action of creating an order. When sorta, you can go into the writing code phase and make a quick build code model, because there will still be problems, and only if there is no problem in the code model is really not.
I'm just assuming a simple business scenario as an example, in order to introduce a technician that differs from the product to the final model after the business understanding is different. Technical personnel must have a perfect business technology to the knowledge structure, so that the real value of the business to play.
6. Technical debt (rotten legacy code)technical debt is unavoidable, a variety of reasons, time schedule, demand changes, market urgency and so on, forcing research and development began to accumulate technical debt, code gradually began to rot, we as a technical staff only complain and shirk responsibility. Here I have some personal views, these personal views may be different from your understanding, you may say I am too idealistic, but I want to say is: " as a technician must have feelings, must have the pursuit." "With my most respected good friend Feng teacher said:" Write code must be elegant. Even when the time is tight, you can write first, but remember that your work is not fully completed.
I am from the development to achieve the architecture, experienced a lot of project discipline, but also know that in the project time is more urgent when you write code in a state of mind, I have also done everywhere copy code paste code, overtime to 12 points, the eye is basically difficult to see the code, The speed at which the code is knocked is not as fast as the feature delivery. I can only say that there is no way, the market determines the progress of the project. We can spit out the groove, but we can't complain, not even negative.
In fact, the reality of our development is basically in this rhythm work, but how I deal with this problem. First write good code is a personal pursuit of technology and professional quality of the problem, if you do not have the beauty of the code to write good code, your code will leave a bad taste everywhere, long time is rotten legacy code, serious technical debt, research and development all day, all kinds of complaints, spit groove, This is actually not good, the team has the pursuit of technical staff will be lost.
To tell the truth, when I wrote the code at 12 o'clock this evening to submit the test, but my work is not completed, I usually wake up early in the morning, I will come to the company to reconstruct and comb their own code, the morning is the brain particularly awake, at this time you do code collation is very good, And this time the company generally do not have any people, especially quiet, when you re-construct the code comfortable and comfortable to tidy up their own every morning to the other business.
You may say that it is your personal problem, I will not be able to get up so early the next morning, even if I came to the company will not be the next day of the code to organize, because it is already online has been completed function, I should continue the next requirement.
In my view of the values, in fact, your work is only half done, you do not have the quality and quantity of the completion of the work, your software delivery is finished at the product level, but you have a technical level is incomplete. You have brought a lot of technical debt to the software, and you have brought the beginning of a rotten code to an object.
This is my current company is very good, the company's top management of the project's chief requirement is to know the technology.
I'll be fine with my good friend and good colleague. Feng Teacher Exchange technology, mutual review Code, comments, in each other to reconstruct, learn from each other. We have a common barbs, is to write code has the pursuit of people to control the project is very good, can be quality and quantity of the completion of the function, of course, is not the light said to write code ability on OK, need comprehensive. In fact, to let a skilled person in the business to become proficient in the software should be good. (The technology described here refers to the mastery of application development, not to technical experts, technical experts at the system level)
As an application developer, always remember that you should have professional professionalism, write code, and remember what the code means to you.
To be Continued ...
King Qingyue Culture
Source: http://www.cnblogs.com/wangiqngpei557/
This article is copyrighted by the author and the blog Park, welcome reprint, but without the consent of the author must retain this statement, and on the article page
Software Engineering-thinking project development Those things (i)
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
