Design and coding in software Engineering/__ Code

GF often said that I eat at home and the hearts of others.

Father is often the mother such "scold", this is my family's fate.

It used to be a person who developed, from ideas, to the final release to the web.

and are very small tool software, therefore, did not realize the importance of design.

Because like programming, in this aspect of the article to see more natural more, know a kind of saying is: Software engineering 70% Design, write code accounted for only 30%.

Recently, because 5 people in the development of a small project, only a few pages early, due to the late things, in order to consider later, the business layer is written very complex, the real thing is basically a one-to-one mapping into class/set and so on.

In fact, a few pages, a few people to fix, but why, we are not yet completed.

Not the project manager did not work hard, and not the members were lazy.

Who's going to take responsibility?

This is not a problem, who is responsible for the future projects are good. No.

Find the cause of this situation and avoid making this mistake again in future projects.

Design..

is designed.

At one of the project meetings I attended, I remembered that someone had asked the question, which was the kind of feeling that made the problem feel like something was not right.

Indeed, he felt it, and raised it--"the design was slightly rougher".

Now, we pay the price, Monday should be tested, but we add 2 days on weekends, still do not see the dawn.

Today Tuesday, where the dawn is, I still do not see.

That's what we've been doing for so long.

The project manager, is the most tired, everyone can see.

Can say "hair all want white", this word to describe, too apt.

What about the other 4 people.

In the internal friction. Notice here that "internal friction" is neutral meaning. Not derogatory.

Because there is no detailed design phase should come out of the document, the members only have nothing to do with the details of the project manager for communication.

You think, in exchange for who, again good temper, again good self-restraint also will be crazy.

4 people, each day to ask n a question. N>20. The person asked, not specifically answer the question, he still "think white hair" in thinking, how to design.

How many processes he will be running at the same time, and there are 4 of irregular interrupt events coming in to make the request. Computers have to crash, not to mention the people.

In this case, the design of things, of course, is not good, the allocation of tasks will not be very appropriate.

So members will spend a lot of time guessing and looking for the data they need, from which class, by which method to take out. If there is a little unclear, first you want to (all can not bear to disturb the project manager), spent more than n time, did not solve, and then to find the project manager.

Even so, progress has been slow. Quality is not high. And everyone finds it hard.

Just like this vicious circle, slow progress, tight time, "hair white" thought out, business layer design, comments and instructions on as little as possible, save time. Cause, other people do not understand, but also embarrassed to stimulate the eldest brother frequently, only oneself think, really can't think of to stimulate eldest brother again.

If the boss in the instead focusing stage, this exchange effect must not be good, two people said half a day, do not know each other's meaning.

Okay, no more nagging. This is not a detailed design on the negative situation of the start.

If. Let's summarize, plus if. At least in the future, it can be done by "if". I'm just trying to imagine, as I've said before, that I'm used to being developed by myself. No experience in team development. If there is any mistake, please testify.

A project, large or small, that is not developed by a single person requires that each participant be knowledgeable about the project, especially to understand how it is designed. Which class, which method, is what. This is the minimum requirement.

But in the absence of a design document, while developing, while defining classes, interfaces, and taking time as the basis for not writing clearly, this defines what these things are for. How to use.

People will spend more time guessing what this thing is for and how to use it. Waste of time, more than others write from the database to the presentation layer.

In the design phase, we have several developers working on N-time discussions (or meetings) and what to do.

From the use case discussion to the abstraction, from the interface layer's button placement to the data table's field definition. and form a document.

The document is detailed to the attributes that each class and class should have, methods.

So what each method returns, what functionality is implemented, is OK.

And there is a benefit is: to avoid in the beginning of the real code, found that there is no point, that is not appropriate, so adjust it, will find, changed here a problem, there are more problems.

This will be the early design of the unrecognizable--(to use a word, really will "not even know his mother").

If at design time, we discuss and combine these details into classes and interfaces together with their goals and parameters, and if there are any irregularities, we will revise them together in the next discussion.

Correcting the document and correcting the code in actual development is not two points, right.

Here, we can really implement design 70% (everyone discussed together, the atmosphere is very good, not nervous and feel disturbed to each other).

In the code, you can draw a gourd from the document, easy and simple, no longer frequent to disturb the other members of the train of thought.

Coding really becomes a physical life, not often see the case of a broken head. Some just listen to music while playing the keyboard gracefully.

So a project is done in a relaxed and cohesive context.