This week I spent a few days in my spare time developing a small phone book program.
Although the program is small, simple, and ugly, it is indeed the first complete and usable App that I have developed. Conception, coding, simple testing, and finally the installation package are all completed by one person. Although I have written a lot of C# and Java code (tens of thousands of lines) and countless gadgets in C and C++ before, I have either only completed a small part of a large project, or it has been boring. "Hello world!" tests the feasibility of the algorithm.
Basic information of the program:
Development tools: VS2010;
Large Small: installation package 500k;
Valid code: about 500 lines;
Architecture: .NET 4.0 Client Prifile;
Main technologies: XML reading and writing, WPF interface production;
Development time: less than 20 hours, estimated to be 15 hours Left and right;
Here are some screenshots:
Login
##Personal configuration and registration
Main interface
Although it is a small program, I have summarized some experiences and written them down, maybe they will be used in the future.
1. Be sure to prevent being greedy for more and seeking more than you can eat. The last tank battle was aborted because of this reason. I wanted to have a dazzling interface, a novel structure, and use new technologies that had never been done before, but the result was a dead end. This time I kept it in mind, simplified the functions as much as possible, and made the interface as simple as possible, and finally achieved the right results.
2. Carry out technical testing first and then carry out actual development. For this program, I wrote three or four small programs to test whether the key technologies and ideas are feasible, and then proceed to development after completion.
3. Develop in layers and blocks, and finally assemble. Ensuring the independence between each layer not only facilitates development but also facilitates future maintenance and upgrades. The separation of data logic and interface allows for separate improvements to the interface or underlying logic in the future. When developing the upper-level interface, a TestData class is used, which uses a series of static methods to provide the fake data required by the interface. A console program was used when developing the lower layer. Wait until both are almost the same before assembling them.
4. Prioritize run-through and strive for refinement step by step. At the beginning, the interface was just a few crooked buttons with the interface name written in the middle of the interface. There are only two results of clicking the button, either going to another interface, or popping up a messagebox to display the name of the button. Write out all the functions first, and do not rush to implement them. Return null or an instance of new or fake data taken out of testdata. After running through, implement them one by one. The interface is enriched little by little, and finally there are those insignificant things like adjusting the position and size.
5. I made an app but could not get the installation package. Later, I reinstalled VS and found out that the installation package is comprehensive and profound, such as encryption, installation environment monitoring, user-defined installation, and rollback. Ah, installation directory selection, pre-installation verification, data compression, installation progress tracking, detection of repair or uninstallation of previous versions...
6. Writing a program is an iteration, forever If a true value cannot be reached, it can only be stopped when the results of the two iterations differ by a small enough amount. This is considered to be a solution.
About future improvements (maybe a long time later Things have changed):
1. Data access can be improved, you can consider using the IQueryable type for reuse;
2. The interface needs to be improved
3. The controller function needs to be improved , remove BL and replace it with multiple Factories
4. Records cannot be grouped
5. Exception handling issues
6. Data access can be isolated using a common excuse. IDataAccess, the factory only calls the interface and does not call the data access class, which facilitates the expansion of data access to a variety of different storage methods
7. Import and export
That’s all for now, more will be added when the time comes.
For more articles related to the development completion and reflections of the phone book applet, please pay attention to the PHP Chinese website!
