10 of the series of agile development "loose Pair programming": L-type code structure (one of the technical articles)

This article is the tenth part of the "loose Pair programming" series. (Loose Pair Programming topic directory)

Topic: how to write the same function with less code, and how the team structure can promote this.

If you want to use only 1/4 of the code at the international advanced level, you can implement the same function. Please read this article.

This article will switch the technology multiple times and manage two parallel lines, so the structure will be more complex.

Preface

I have always been interested in code validity. So after I re-deploy the function tree this morning, I carefully counted the function points and code lines, which are roughly as follows:

Line 2 of the Code, statistical data from vs (only the CS file is calculated), plus the 9883 semicolon count in cshtml (this method is less than about 1420 of vs's statistical method), and about 10% rows;

740 features, including 33 Ilf and 127 operations (no Ei/EO/EQ is distinguished, and each operation is uniformly calculated by 4 FP, which is slightly lower than the standard value) (For the calculation of function points, please refer to the http://blog.csdn.net/cheny_com/article/details/7692917 and the four articles below, which will be available in the future of Martian products ).

That is to say, 15 lines of C # code are required for each function. On QSM's website, this number for C # is about 60 (http://www.qsm.com/resources/function-point-languages-table), considering that companies that are able to provide this data (especially functional-point-based data) are not waiting for them, so the value 15 is amazing (I mentioned in the training class that it is roughly 19 ~ 23, but at that time it was not carefully organized, it was a rough value ).

Code line/function point, that is, the average number of lines of code can implement a function point, is a internationally accepted method to evaluate the effectiveness of programming efficiency.. When Ms introduced C #, in order to prove that C # is more efficient, C # compiled a Java routine petshop (also called PetStore ), the result is that only 1/4 of the Java code is used. Java was later counterattacked, rewriting petshop (http://www.clintonbegin.com/downloads/JPetStore-1-2-0.pdf) with roughly equivalent code efficiency ).

Of course, it will be mentioned later about whether less code is good or not.

Solve a basic problem first: How to make less code?

Technical Means

Technical means are not the focus of our speech today. Because technical means are limited by the level of developers, it is extremely difficult to increase the number of technical means at once. Moreover, the business itself will limit the use of technical means.

However, let's talk about the following points (others will be shared later ):

1. limit the size of each function

The Martian contains 2125 public keywords. The number of functions is roughly estimated to be about 2000. Therefore, the code in each function is less than 5 lines on average.

Small functions have some obvious advantages:

A. It is easier to extract reusable parts.

Let's take a look at the three interfaces mentioned in the Martian manual:

The following code generates these three interfaces (and more than 10 similar interfaces:

Private void prepareindexdata (INT rootid, string whats, string whattypes) {viewbag. itemtreeviewmodel = new itemtreeviewmodel ("view User story Tree", rootid, whats ?? Systemitemwhat. story, whattypes, product. productsaccessibletouserids (user. identity. name), showpopupoperationmenu: True, showmoveleftright: True, showmoveupdown: True, enableinternaldrop: True, subitemstreecolumnwidth: 290);} [urllog] public actionresult index (INT rootid, string whats, string whattypes) {prepareindexdata (rootid, whats, whattypes); // viewtester. isviewtesting = true; return view (itemtree. viewpath);} [httppost, urllog] public actionresult index (INT rootid, string whats, string whattypes, formcollection collection) {try {item. onitemdropped (Collection [mfcui. draghistories]);} catch (exception e) {modelstate. reportexception (E);} prepareindexdata (rootid, whats, whattypes); Return view (itemtree. viewpath );}

When whattypes changes, the preceding three interfaces are generated.

If the viewmodel generated in preparexxxdata is different, more than 10 interfaces are generated.
In the figure, there is an inconspicuous small function called item. onitemdropped, which can process the story tree (including the multi-seed Tree mentioned above)/Department tree/Custom Field tree/story board/Wizard ...... And so on.

B. easier reading and Maintenance

Sometimes I often hear a saying: "less code, sometimes it is not easy to understand ".

I don't know how everyone feels. I think the above Code is easier to read than the 500 lines of code in bulk. It would be easier to maintain it one day.

Of course, the next question: will it be difficult to change the underlying layer? What should I do?

In fact, if you open these functions, you will find that they are also formed by a layer, and do not need to really face 500 lines of code; and at a layer, you find the place to be maintained, you don't need to go further. In this way, you can find the layer by layer, and each maintenance may only need to look at 50 lines of code (50 lines will be used for 10-layer calls), rather than repeat the 500 lines of code.

2. Hiding information, exposing its usage, and hiding its Implementation Method

These benefits include:

A. functions can be self-interpreted.

It is often said that comments should not be written and self-explanatory code should be written.

But there is a problem. What is the code to explain? Explain what you are doing, or explain how you are doing it? If you can only select one, I will definitely select the former.

For example, the four lines of code:

            try            {                Item.OnItemDropped(collection[MFCUI.DragHistories]);            }            catch (Exception e)            {                ModelState.ReportException(e);            }            PrepareIndexData(rootID, whats, whattypes);            return View(ItemTree.ViewPath);

It looks like: Processing drag-and-drop operations. If an exception is found, the report prepares data based on the link parameters and regenerate the page.

If every function is written so cleanly, even if we don't know how it is implemented in it, it is easy to trace the problem and find the specific place and then read it slowly.

B. It is easier for new users to get started.

In this product, a similar interface, tree structure, drag and drop, or even add Ajax operations ...... If the code is 500 lines, are you sure you can get started with it? It is difficult to estimate.

But now it's much easier. A technical support engineer who has never compiled a program before, within less than a year after NLP programming (the effective working hours are converted into a 5 × 8 model, which may only be 3 ~ 4 months), I made two similar interfaces directly based on the gourd image, and helped me maintain many other details, because these work looks more likeBuild BlocksInstead of having to be familiar with software and programming.

The following is a piece of "building block code" built by him ":

Public actionresult linkproduct2team (INT focusedproductid = 0) {viewbag. itemtreeviewmodel = new itemtreeviewmodel ("product-team ing", department. departmentrootid, systemitemwhat. deaprtment, itemwhattype. deaprtmentdepartment + "_" + itemwhattype. deaprtmentteam); focusedproductid = 0? Productline. productrootid: focusedproductid; viewbag. linkitem2itemsviewmodel = new linkitem2itemsviewmodel (department. departmentrootid, systemitemwhat. deaprtment, productline. productrootid, systemitemwhat. product, focusedproductid, whattypes: itemwhattype. deaprtmentdepartment + "_" + itemwhattype. deaprtmentteam, leftpadwhattypes: itemwhattype. productproductline + "_" + itemwhattype. productproduct + "_" + itemwhattype. productedition); Return view (itemtree. viewpath );}

To generate a tree structure, you only need the first line of code. The remaining code processes the behavior of the tree structure.

If the branches are clicked on this interface, an Ajax call will occur and the style of the branches will be refreshed. I don't have time in 3 ~ 4. I teach a programmer C # + Ajax, but he does not need to learn it. Instead, he only needs to write down:

    var ajaxLink = "/MFC/LinkItem2Items/AjaxNode?currentItemID=" + Model.ID + "&leftPadFocusedItemID=" + leftPadFocusedItemID + "&leftPadRootID=" + leftPadViewModel.LeftPadRootID + "&leftPadWhat=" + leftPadViewModel.LeftPadWhat + "&leftPadWhatTypes=" + leftPadViewModel.LeftPadWhatTypes;    MvcHtmlString link = Model.Link(outerLink: ajaxLink, updateTargetId: Model.ID.ToString(), onSuccess: "refreshAll(); ");        <div id = "LinkedItem@(Model.ID)" class = "@(divclass) toggleLinkedItem @(hideclass) originalLinkedItem hovershowLinkedItemReverse">        @link     </div>

The JS scripts required for Ajax operations and refresh will be automatically generated by model. link, and the called function ajaxnode contains only nine lines of code.

Therefore, it is easier to understand and use the short and highly encapsulated code without worrying about the issues that new users cannot understand or use.

On the other hand, we can't let the experts use ABC-level junk code for writing because the novice cannot understand it? After all, it should be a newbie, not a master.

As a matter of fact, it is one thing to restrict the size of a function and conceal information. The former leads to the latter.

The technical methods mentioned above are not difficult, but the question is, why can't many teams do it? Next question:

Experts can write code like this. What about beginners? I can't ask them to do the same? This is the content of the next article (management.