Two questions about design documents

I have been feeling helpless recently, and there are too many things that are hard to understand. Today, when I wrote an apology letter to the manager, my heart was bleeding, and a few tears were not disappointing. I know that I did make a mistake this time, but for some reason, who can fully distinguish and understand my current feelings. The apology letter was actually written to the manager of the manager, but some words were not written in the end, because we only wanted to settle down, but hoped to make enough excellent products in the current stage, therefore, we are always wronged.

Aside from these questions, I still failed to reach an agreement with some ideas of the manager, and often "hit" the manager. Maybe this is also getting worse and worse in his eyes. Sorry, but I have some comments that it is not my style.

These problems have also plagued me for a long time. For me who lack the ability to express their language, it is difficult to describe my thoughts in the field, but I really want to get guidance from others, therefore, we have the following words, hoping to get some guidance:

Focus 1: design must be refined to enough detail

Focus 2: strictly follow the design documentCode

 

There seems to be no ambiguity between the two questions. If you ask me whether I agree with them, I agree, but please let me know.

I just agree but not totally agree.

First of all, regarding the first one, my concern is, to what extent should I fully agree that there should be design first before any coding, and there should be ideas, but should I write design documents? Must the design document cover "all" details? For example, the design document describes the class diagram, InterAction diagram, and sequence diagram of createcommand in detail, describes how it interacts with external classes, and describes the entire operation process at a time. For a similar copycommand, do I have to refine it to the degree of creatcommand?

I think that if the implementation mechanisms of these two commands are the same, they can be omitted or copycommand can be roughly outlined, so it is not necessary to refine each time until it is not refined. Unless two completely different things are described, they have different implementation mechanisms.

For the internal logic of copycommand, if the internal implementation method only needs to simply call the datamodel method, do I need to detail it in the class diagram?

My point of view is still no. Unless the implementation logic of copycommand is very complicated, I think it is necessary to describe Step 1 using a sequence diagram or other means ..., Step 2...

So, my overall point of view on the design document is that the design document is not all. This is just a tool for communication and describes how you solve the problem, solutions for all problems should be reflected in the document. Any reviewer can discuss and refine any questions about how a problem is solved. Isn't it. When everyone should be able to understand how to describe a problem in one sentence, why should we refine it to the specific 1, 2, 3...

Someone retorted that What should I do if you read a sentence that you don't understand. The reason is that I have to describe 1, 2, 3... Why? I don't think so. If you think you can leave, you can leave it empty. Why do you have to reach 10? perfection is just a cloud. Of course, if your confidence index is only five or six, you 'd better write it down. If there are points, my practice is not to write, and there is any concern in the review process. We can explain and update it to the document.

With a problem, must the design document be clear to everyone?

My point of view is still not necessary. The minimum requirement of the design document is to allow all implementers to understand and enable them to acknowledge that it can actually solve existing problems. Considering that our experience is relatively low, we should be taken into account by the impact ect review, and we must be able to understand the impact ect. As for the manager of this manager, it is okay to make it look like it is not too bad. It should not be forced to make it understandable to them.

The above question is still about degree. It is too hard to satisfy the appetite of people who are not familiar with architecture and are not familiar with technical issues. We said that the speaker should first understand the background of the audience when giving a speech. The design document should also have a specific target group, not everyone. So, it is best for everyone to understand nature at first glance, but should not be forced.

Today, when agile development is widely used, it is necessary for design to stick to all the details?

People who write design documents can really see and think about it. Will it cover all the details?

 

Secondly, my understanding of the second one is necessary, but today I am planted on this issue. Because I still have some small self-views in addition to "must", the design document must have the necessary information to reflect the author's intention. The writers should try to repeat it multiple times, A rough piece of design cannot be lost. why can it be accepted? You can say that I have never commented on it. I admit that I was wrong. I should come up and ask, but I was still lamenting the design. Today I didn't fully follow the design. I should have been approved, but can you think a little bit about who was the author.

On the other hand, if the design documents are all detailed, who can ensure that the design documents are correct and there is no difference between them? Is it necessary for us to follow the instructions in this document? Of course, you can talk about it first and then implement it. I agree but only limited to large issue. Should all the details be done like this? Have you considered communication costs?

 

Too rough design documents should not be, and everything must be detailed design must be our pursuit?