A summary of the development of the pair project (additional question)

A summary of the development of the pair project (additional question)

The task of this add-on is to disrupt and reassemble the independent UI and core modules written by two groups into a new app.

Our group chose the Great God Liu Hu Group to cooperate with us in exchange. Once I get the core code of the dry God, I have to say, the dry God is a dry God, code out, directly put me down, all kinds of parameters can not understand what to do? How do I write the UI?

Fortunately, our comrade-in-the-Lord has provided us with help. Documentation, which describes the role of each parameter, is summarized as follows:

for the value of the calculated expression (Calc mode): Answerget (strings) where S is the given calculation, ending with an equal sign. When invoking the generator, use: PublicGenerateexp (BOOLHasnegative/*Negative number*/,            BOOLHasmultdiv/*Multiplication Method*/,            BOOLHasbrack/*brackets*/,            BOOLHasfrac/*score*/,            intOpcount/*maximum number of operators*/,            intExercisecount/*Maximum Quantity*/,            intLeftrange/*left Domain*/,            intRightrange/*Right Domain*/,            ref intFactcount/*actual generated value*/the actual value of this thing you can define casually, the original is to deal with the error. If this does not produce as much as expected, an exception is thrown to Toomanyexception (); When the Inspector is invoked, it is used as follows: Checkanswer.grade (Exepath,answerpath);

With this parameter, it is equivalent to give us three function call interface, we just need to design a UI, collect the user's input data, in the background to pass these three functions, get the result to display on the screen.

Let's take a look at the final effect (without spending too much effort on the GUI, because most of the time is spent on the core bug debug, Beg pardon ...) ）

The interface is also relatively simple (chou) clean (Lou).

Given the small amount of code in the UI and the basic understanding of the parameters, I don't think it's necessary to focus on the design details of the UI, just to cut some of the code here:

Private voidButton1_Click (Objectsender, EventArgs e) {            BOOLHasnegative =checkbox1.checked; BOOLHasmultdiv =checkbox2.checked; BOOLHasbrack =checkbox3.checked; BOOLHasfrac =checkbox4.checked; intOpcount =int.            Parse (TextBox1.Text); intExercisecount =int.            Parse (TextBox2.Text); intLeftrange =int.            Parse (TextBox3.Text); intRightrange =int.            Parse (Textbox4.text); intFactcount =0; NewWindowsFormsApplication2.Calc.GenerateExp (hasnegative, Hasmultdiv, HASB                Rack, Hasfrac, Opcount, Exercisecount, Leftrange, Rightrange,reffactcount); MessageBox.Show ("Build Complete"); }

OK, here's a question about the two-group modules we've been working on together.

1, our two groups are first in the group to develop their own UI and core, because the teacher's software requirements are not particularly clear (the actual situation, there is no 100% clear user requirements description), so in some of the features of the trade-offs of our two groups of strategies are different, for example, the Calc mode, Our team supports arithmetic processing of decimal and fractional blending, and we define the number of decimal places for the final result, while the Liu Hu team tends to convert all of the data into fractions, preserving accurate results. This causes our own UI to remove the number of decimal digits in the Calc form, and to make sure that the input of the data is in fractional form. For example, the Liu Hu Group considered very carefully, they think that when the number of problems generated is larger and the range of values is relatively small, because the software requirements can not generate a duplicate calculation, then there may not be enough to generate a calculation of the situation, so they define a factcount variable to record how many formulas actually generated, Throws an exception when the generated formula is not sufficient. When we think of this extreme situation in UI design, we don't specifically define the behavior for the exception, causing the program to crash sometimes.

2, the purpose of this additional problem is to let us understand the loose coupling program design method. I've already explained the loose coupling in another blog post, and it's not easy to do that in real programming development. In some cases, we will need to refer to some local variables of another module in designing a separate module, which leads to the implementation of a module function that relies on the specifics of another module and does not satisfy the principle of loose coupling. specifically to our module splicing, the Liu Hu Group's core module has such a line of code:

New FileStream (Mainform.path, FileMode.Create);

The mainform actually refers to the main form file in the UI design of their group, so Mainform.path refers to the directory where the main form file of their group is located, so we can not even compile it in our code.

We analyze the reason, according to loosely coupled design principles, the code in the core module should not directly refer to the data in the UI module, otherwise it will lead to one-way dependency, not conducive to core porting.

We revise as follows:

New FileStream (path, filemode.create);

Where path is the parameter of the function in which this code is located, that is, path is passed through the parameters, you can pass in the specific path to create the file, so as to ensure the independence of the core code.

This should be our first real-world team programming-independently developing a module, then stitching and overall testing. In the splicing process, two groups of code appeared "incompatible" phenomenon let me understand a truth: Unified specifications, unified parameter description, detailed help document is how important, in fact, these three points reflected in the process of development of the contract. In actual development, we do not have so much energy to carefully analyze the meaning of each other's lines of code, we need some instructions to quickly know the other side of a function block, according to its interface to use it. I think of the two years I wrote the program is always only to understand, without any help documents, very few comments, and sometimes even after a period of time I can not understand. Look at Microsoft's professional software companies, each of which has a detailed help manual for each of the software they develop, and often has more comments in its open source than the code. I think that to progress from a low-level programmer to a senior engineer, you should start with reading, writing help documents and comments.

Finally, it is not simple to say that the dry God, every line of code is excellence, from which you can see a software engineer's feelings. Emulate, that's what we should do.

A summary of the development of the pair project (additional question)