How to Write 15 principles of good quality software-from MVM

Writing good software is the goal and dream of every software developer, but we always write for ourselves for various reasons and reasonsCodeOpen. However, I believe that we are all trying to change this issue and hope that these principles will give us some thought.

1. Use of your project team Source code Is the management tool available?
2. Have your project team used the defect management system?
3. Are your test groups still using word to write test cases?
4. Have you set up a portal for your project team?
5. Have you purchased the best tools for your project team?
6. Yours Program Are employees working in a quiet environment?
7. does each of your employees have a phone number?
8. Do you all know who to look?
9. Someone said, "I thought ..." ?
10. Are all people in your project team sitting together?
11. Does your schedule reflect the latest development progress?
12. do you estimate your workload by yourself?
13. Did your developers work overtime from the very beginning of the project?
14. Is the buffer time added after each small task in your project plan?
15. It is worthwhile to spend more time, from 95% to 100%.
16. Have the reproduction steps been written during registration of new defects?
17. Will known defects be solved before new code writing?
18. Do you have any prior agreements on priority of defects?
19. Do you have any defect in the Three Kingdoms meeting?
20. Are all defects closed by the registrants?
21. Do your programmers hate to modify old code?
22. Does your project team have a team morale activity?
23. Do your project team have their own logo?
24. Do your employees have T-shirts with company logos?
25. The general manager shall attend at least one project group meeting every month.
26. do you open a branch for each Dev?
27. Does someone keep checking-in code for a long time?
28. Have you filled in comments when checking-in code?
29. Have you set the daily check-in deadline?
30. Can you compile all source code into an installation file at once?
31. Do your project team perform daily compilation?
32. Have your company accumulated a project risk list?
33. The simpler the design, the better.
34. Use existing products, technologies, and codes whenever possible
35. Will you stop and consolidate the code after a while?
36. Do everyone in your project team write a daily report?
37. Will your project manager issue a weekly report?
38. Do your project team have at least one plenary meeting every week?
39. Are there records of meetings and discussions in your project team?
40. Do other departments know what your project team is doing?
41. all formal communication via email
42. Create multiple mailing groups for the project team
43. Does everyone know where to find all the documents?
44. Did you tell everyone the reason when you made decisions and made changes?
45. Stay agile and keep CT change
46. Do you have any full-time Software testers?
47. Do you have a general plan for testing to determine what to do and how to do it?
48. Did you write test case before testing?
49. Will you create test cases for various input combinations?
50. Can your programmers see test cases?
51. Do you need to take some people for usability testing?
52. Are you expecting automatic testing?
53. Is your performance test performed only after all functions are developed?
54. Have you noticed the Pesticide Effect in the test?
55. Can someone in your project team tell you about the overall quality of the product?
56. Do you have a unit test?
57. Did your programmers throw the wall after writing the code?
58. Do all the functions in your program have input checks?
59. Does the product have a unified error handling mechanism and Error Reporting interface?
60. Do you have unified code writing specifications?
61. do each of you understand the commercial significance of the project?
62. Are the interfaces and operation habits of various products consistent?
63. Is there any cool feature that can serve as a promotional highlight?
64. Shorten the product startup time as much as possible
65. Do not focus too much on internal quality and ignore the first-eye external impression
66. do you develop according to the detailed product function manual?
67. Have you carefully reviewed the functional design before you start development and testing?
68. Do everyone always think about the whole image?
69. Is the division of Dev work purely vertical or horizontal?
70. Do your programmers write program design instruction documents?
71. Did you ask him to write a program during the interview?
72. Do you have any technical exchange lectures?
73. Can your programmers focus on one thing?
74. Will your programmers exaggerate the time required to complete a job?
75. Try not to use virtual heads