Ion APJ interface project summary

Ion (input output Network) is short for the company's logistics system. A system that took up 10 developers and completed in one year has finally come to an end. I have the honor to become the development team lead and have been working with you for a year. Let's take a look at the mistakes.
Chinese developers are not invited to participate in system development until the demand analysis is completed. At the beginning, I took over the demand. Naturally, there were vast documents, and the communication emails sent back and forth were scattered everywhere. During each meeting, we are looking for the latest version, which is inefficient and time-consuming. It is not until later that documents are moved to the source safe for unified management.
Third-hand Requirement Description. The China Development Group is added to the project only after requirement analysis. The requirements of end users are transferred to the developers only after being transferred to the business analysts, development leaders, and developers. Because each person has a different degree of understanding of the function, there are some deviations between the actually developed system functions and user expectations.
Lack of competency assessment and training for existing developers. Ion is the company's core logistics system. Errors in the code will cause huge losses to the company's production. Although each developer is required to perform unit tests in the early stage of development, the criteria for unit tests are not defined. Until the middle of the encoding phase, some developers still repeat the stupid error such as "unit test passed, but feature error.
Summary: a unified and centralized resource management tool is required for all documents of the project. For example, to classify documents and migrate them to the vs team system server resource manager, then, publish the latest documents on the Share Point Portal Server. At the same time, developers involved in the project should make a capability evaluation to quickly provide training and strengthen training results for the short board on the barrel, in order to meet the project requirements. Analyzes data streams so that each developer can understand the data processing process and the position of each module in the process.

When the project reaches the design stage, some standards need to be developed, "Game Rules ". Among them, the most undesirable one is peer review. In the development phase of the project, if you do not have a review or a symbolic review, this creates a very serious consequence: the code quality of a developer is much lower than the requirement and has not been found for a long time. Although he has implemented the function, the code is really a mess. In the end, I had to assign another employee to take over his work.
Standard definition conflict. My boss and I have defined different standards for how to handle system errors. This confused developers. Finally, there are three versions of error handling in the Code: one following the boss's error handling method, one following my error handling mechanism, and the other two following the error handling mechanism.
Over-design. The system enters the trap of "mode-oriented" when receiving external messages. Developers have spent a lot of time developing a message receiving module that is compatible with FTP and ibm mq. Finally, we found that the call was complicated and had to give up the module.
Personnel allocation policies are incorrect. Due to insufficient development staff, the bosses assigned a developer in India and three developers in Malaysia. Because I have not figured out who is responsible for the system and who are ultimately responsible for system maintenance, in terms of development standards and code quality, I only gave suggestions to developers in other regions, rather than mandatory compliance. I simply think that they are not in charge of me. What they write is none of my business. But in the end, the system is all handled by Chinese developers. We have to pay for all nonstandard code.
Risk management. The telephone communication in the boast area is time-consuming and laborious. Although there are three more developers, the communication time is huge.
Waste and the quality of some modules is out of control.
Obsolete SDS (System Design Specification ). Because SDS is not from the development team, developers generally do not agree with the system design and establish a separate portal, causing the most important documents in the design stage to be shelved and not read during development.
Conclusion: Once a game rule is developed, a good example is needed. Someone needs to take the lead and give everyone a best practice. Conflicts are not allowed in the formulation of standards, and some people need to sacrifice and compromise for the whole. The design stage requires a risk management plan, such as FMEA: defines when the peer review the code of colleagues in other regions, what if their code quality does not meet the requirements? What is an alternative plan? In the design phase, the test team should complete the writing of test cases, and the development team should carry out the design of test cases to ensure that this is a "design to meet user needs ".

Code and design synchronization. Since no one can be correct and optimized in design, the design will naturally be modified in the coding stage. Developers often forget the synchronization design document when changing the code. It is not because developers are lazy, but because of work methods and design documentation.
Conclusion: You must modify the design document before modifying the code. Ensure that a design content appears only in one document, so that a design can be avoided in multiple documents. This facilitates developers to synchronize design documents. Otherwise, the enthusiasm of developers to synchronize design documents also makes it difficult to manage design documents.

The system was finally deployed and put online. We tried to run the test run on Saturday. Wow, there were a lot of error alarms! I checked and found that the database was not synchronized! It took just half a day to figure out that the DBA synchronization development environment and production environment had time errors, and some newly modified stored procedures were inconsistent with the table structure. This is funny, and everyone is in a hurry to perform manual comparison. However, for databases with dozens of tables and hundreds of database objects, manual comparisons are inevitable. One day a week later, the system performance suddenly fell sharply, and the production line was almost shut down. In the boss's "ROAR", I quickly checked the cause. The original production environment missed 5 important indexes!
No matter how good the system is, there will inevitably be bugs. What's more, it depends on how the patch is installed. If you do not forget to update the configuration file, omit the DB script, and re-run the regression test, you should not introduce any problems. :)
In summary, there must be a clear cut off time for Database Synchronization in the deployment plan. After the cut off, all the updates are included in the patch after the release. The barriers to communication with DBAs cause a lot of trouble. I am so sorry to write this stupid question.

The system has been running for three weeks and is becoming more and more stable. Hope the next project can do better. :)