[beauty of software engineering - column notes] "one question and one answer" issue 3 | 18 common software development problem-solving strategies

---

Column information

1. Columnist ： The treasure jade

2. Column publishing platform ： Geek time

---

primary coverage

---

One 、 One question and one answer

1. ask ： Every time I look at the ideas of these architectures , It is always not well combined with the actual application , The reason is that the practice of architecture design is not enough ？ Or there is too little analysis and thinking about various implementations ？

   answer ： I think it's not just about architecture practices , There are also practices in different scenarios .

   For example , You usually do enterprise application architecture , There's no traffic , There's not much data , The complexity is all in business logic , At this time, you go to see the big data 、 Articles about high concurrency , It's hard to bring into the scene .

   There are also some architectures , It's hard to understand the advantages and disadvantages of not doing it yourself , That's another reason .

   Consider the opportunity to try it yourself , Build some good architectures with a prototype program , Make a little bit of data , Pressure test with a tool , This will make you feel more .

   And practical application , On the one hand, your existing architecture may not be a big problem , There is no such urgent need to transform ; On the other hand, it may be due to the lack of practical experience , indecisive , I don't know if it really works .

2. ask ： What are the more standardized documents , What are their functions ？

   answer ： For the waterfall model , At the end of each phase , There are corresponding acceptance documents , Agile development, on the other hand, doesn't have so many rigid requirements , It's based on the needs of the project , Write the necessary documentation .

   I think the necessary documents in the project , It mainly includes these categories ：

   1. Design documents

      This kind of document is mainly used to explain 、 Discuss requirements design 、 Architecture design , Can be used to understand 、 Discuss and review , And recording the follow-up results .

   2. Description class document

      This kind of document is used for specification 、API、 To configure 、 Operation, etc , Easy to standardize and unify .

   3. Report class document

      A report and explanation of the outcome of the event , For example, the acceptance report 、 Fault report 、 Research, etc .

   And the value of these documents , It's about helping members understand the design 、 Participate in discussion , Record project results , Reduce communication costs . What matters is not how rich the documentation is , It's about whether these documents are valuable , Can you get the answers you want through these documents in time .

   So you can also compare your project with , What are some aspects of the current document that can be simplified , Where to enhance .

   for instance , Outline design / Interface design / Whether the detailed design can be combined properly , Reduce document workload ？PRD Is it detailed enough ？ It's not easy to understand , Do you want to add a prototype design document ？

3. ask ： Internet architecture , Consider the fast iteration speed of the Internet , So pay special attention to extension and so on . The enterprise architecture , Inside IT The system is relatively stable , Compare the Internet Architecture , It's simpler ？

   answer ： Good analysis . I'd like to add a few points for you ： Not only will the Internet architecture iterate faster , The user scale is usually larger , But the business will be a little bit more ; Enterprise applications usually have complex business , In particular, there will be some combination with the industry , But the user scale is much smaller . These characteristics , Will affect the choice of Architecture Design .

4. ask ： Is there a tool for managing things ？ Because if you don't write it down , And then I forgot .

   answer ： Message area McCree The classmate recommended the tick list . My personal words , Usually use the notebook that comes with the system to record , Or stick a note on the monitor . If the time span is long , I remember Calendars On , Add a reminder . Tasks at work , I'll create it as Ticket.

5. ask ： The case of checking production problems mentioned by the teacher , Rollback version first , Look at the log again . This will cause more system functions to be unavailable , If the functional difference between the two versions is not clear, roll back directly , Whether the system risk is further expanded ？

   answer ： This really depends on the specific situation , Because my daily system goes online , There will be rollback schemes , Rollback is also automated and convenient . Some are related to databases , If the database structure changes, new data will be generated , It's really impossible to rollback directly .

---

Two 、 Selected messages

1. In the absence of special requirements , More familiar technologies are preferred in the project , Because we need to be responsible for the quality and delivery time of the project , It can be controlled . And the new technology has new design ideas and powerful functions , At the same time, it is accompanied by unpredictable “ pit ”. In the time of subsequent product iterations , Targeted upgrade or choose to replace the better of similar technologies .

2. Technical debt is not all bad , Like financial debt , Need specific analysis . Frivolous & Intentional debt should be avoided . cautious & Intentional debt yields . Frivolous & Beware of unintentional debts . cautious & Unintentional debt to change . Identify debts and take precautions . According to the cost-benefit analysis , Decided to rewrite （ One time repayment ）、 maintain （ Just pay interest ） Or refactoring （ hire purchase ）. Related reading ：24 | Technical debt ： Is to continue to make do with , Or overthrow and start again ？

---

summary

Questions and answers and messages are long , Here is only a part of the excerpt .