Sand development
I like to read articles on Habré from experienced people with experience in team development, their advice, instructions. For the time being, I myself simply lead a student life, and any activity as usual is individual and short-lived. Well, of course, it happened to write custom designs, but this is more of a hobby and a passion than something more.
It happened recently at the university to develop a software complex of client-server interaction on JAVA. The final task of the special course, if I may say so.
In the design involved 10 people. That in itself makes adjustments to the organization of any activity. He took the most direct part in this by accepting responsibilities as a leader.
Of course, it all started with the idea : what would such a thing be written in the end, to pleasantly surprise the teacher and for one, deserve the exam automatically. As a result of the primary brainstorming, the project concept was put:
Let's make a network application using client-server architecture: the server contains a database with students, photos, information and quotes. The client requests information from the server and displays it to the user.
Later, more bold thoughts arose:
What followed next? Design, object-oriented modeling. Here we presented the task as building a mechanism for the interaction of objects, describing their properties and interfaces.
The easiest, but the most important part : to determine the base classes, the data, in the desired form: the student class, the list of students. Later a server student was selected as a successor to the usual one, but with an additional field of the path to the photo on the server, an interface was developed for the list (in JAVA OOP terminology) for extensibility (whether to load the list from a file, either from a database or in any other way). Classes for working with images, data.
Initially decided that the same client will exist in the console and GUI variants, and the GUI is nothing more than a frontend. The server is built to work with the selector and channels, i.e. all network operations without blocking. Mutually agreed servers, this is exactly what was called in our course. To generate a response, we again selected the interface, which was then implemented in a separate class.
Here they also distributed responsibilities in implementation, dismantled the work of the protocol, formed all the requirements for it.
Further technical means of implementation: Eclipse development environment for JAVA, SVN- server of our department to synchronize development.
Well, after the design of these parts, the development began.
First of all, I laid out an approximate framework of the project explaining the role of each class, scattered everything in packages. I posted a description of the protocol with examples, laid out the distribution of tasks, notes on working with SVN.
It was immediately discussed even earlier that it is impossible to commit uncompiled code in SVN, leave commit comments empty, climb into other classes without the need, unless it was allowed to do stubs of missing methods with TODO or FIXME. This helped to avoid conflicts in SVN to the last.
I do not want to say that someone does not have the necessary knowledge, rather experience, therefore the task model and implementation was simplified, it was not necessary to know the same design patterns , etc., so that the allotted time was not spent on reconfiguring to a new, unusual fret
What mistakes were made (in my opinion):
Yes, so I finished the gloomy part, and now to the positive:
The project went on time, although the last night was essentially sleepless for two people.
The teacher was delighted, as we are.
Of course, as it always happens, the functionality was cut down at the end, but not so much that someone else’s work was removed from the release.
I do not consider the source code to be correct, so I don’t attach it, but the program itself and the address of the publicly accessible server: always welcome.
I realize that one team project with a more or less successful end does not give the right to lift up one's nose and cherish hopes for wild success.
Without claims for objectivity and with the knowledge of little experience, expectations of practical advice for the sake of.
')
Zachin
It happened recently at the university to develop a software complex of client-server interaction on JAVA. The final task of the special course, if I may say so.
In the design involved 10 people. That in itself makes adjustments to the organization of any activity. He took the most direct part in this by accepting responsibilities as a leader.
Of course, it all started with the idea : what would such a thing be written in the end, to pleasantly surprise the teacher and for one, deserve the exam automatically. As a result of the primary brainstorming, the project concept was put:
Let's make a network application using client-server architecture: the server contains a database with students, photos, information and quotes. The client requests information from the server and displays it to the user.
Later, more bold thoughts arose:
- What if you make the ability to administer the server: remote stop, start, change configurations. Accordingly, here we add the client for the admin to steer everything.
- Application internationalization: it is always good and convenient when the program speaks the right language with you :)
Job
What followed next? Design, object-oriented modeling. Here we presented the task as building a mechanism for the interaction of objects, describing their properties and interfaces.
The easiest, but the most important part : to determine the base classes, the data, in the desired form: the student class, the list of students. Later a server student was selected as a successor to the usual one, but with an additional field of the path to the photo on the server, an interface was developed for the list (in JAVA OOP terminology) for extensibility (whether to load the list from a file, either from a database or in any other way). Classes for working with images, data.
Initially decided that the same client will exist in the console and GUI variants, and the GUI is nothing more than a frontend. The server is built to work with the selector and channels, i.e. all network operations without blocking. Mutually agreed servers, this is exactly what was called in our course. To generate a response, we again selected the interface, which was then implemented in a separate class.
Here they also distributed responsibilities in implementation, dismantled the work of the protocol, formed all the requirements for it.
Further technical means of implementation: Eclipse development environment for JAVA, SVN- server of our department to synchronize development.
Well, after the design of these parts, the development began.
First of all, I laid out an approximate framework of the project explaining the role of each class, scattered everything in packages. I posted a description of the protocol with examples, laid out the distribution of tasks, notes on working with SVN.
It was immediately discussed even earlier that it is impossible to commit uncompiled code in SVN, leave commit comments empty, climb into other classes without the need, unless it was allowed to do stubs of missing methods with TODO or FIXME. This helped to avoid conflicts in SVN to the last.
I do not want to say that someone does not have the necessary knowledge, rather experience, therefore the task model and implementation was simplified, it was not necessary to know the same design patterns , etc., so that the allotted time was not spent on reconfiguring to a new, unusual fret
A spoon of tar.
What mistakes were made (in my opinion):
- It was necessary to agree in advance on a framework for converting the data participating in the program. The result was that two people for their classes in different packages wrote the same service methods for translating the buffer into a string and back (little things, but it wastes time).
- There is never a lot of information and detail about a project. If one thing seems to me like this, it does not mean that the other person will share my opinion. In the initial stages, changes in SVN were not always consistent with the original plans.
- It is necessary to pre-set the deadlines for work with a margin. We are all people, with their concerns and problems. The deadline turned out to be slightly delayed, so everyone rushed to commit at the very end (on the 4th day of the 6 set, the development activity sharply increased).
- At the end of the work, attention is scattered, so that some things to the release look unexpected and missed. You should always choose a plan for the time for each task. If you did not have time - not to finish it right there, but to postpone it to the closest possible time after doing the others.
- You should always treat with respect to someone else's code. If something is not pleasant, then it is better to tell how it is necessary, but not to rewrite and point to a new version. You need to be interested in the opinions of all the participants, trust them in certain issues unconditionally. Thanks for the good work and all the assistance in general. After all, it is quite clear that the specifics of the project does not imply that someone will receive from him any significant material benefits. (remember open source)
- You should not try to do everything yourself, but such a desire often arises: again, because of the different approach to implementation, sampling trivia.
The fruits of labor.
Yes, so I finished the gloomy part, and now to the positive:
The project went on time, although the last night was essentially sleepless for two people.
The teacher was delighted, as we are.
Of course, as it always happens, the functionality was cut down at the end, but not so much that someone else’s work was removed from the release.
Afterword.
I do not consider the source code to be correct, so I don’t attach it, but the program itself and the address of the publicly accessible server: always welcome.
I realize that one team project with a more or less successful end does not give the right to lift up one's nose and cherish hopes for wild success.
Without claims for objectivity and with the knowledge of little experience, expectations of practical advice for the sake of.
')
Source: https://habr.com/ru/post/60937/
All Articles