Comments, SVN, bug-, issue tracker and teamwork
Reflections caused by the topic "How to deal with the human factor in the implementation of software?" .
During the last almost a year, I work in a team. Before this experience in the team was not at all. I was interrupted by small freelance orders, plus more or less constant cooperation with one of the employers, for a minor refinement of the functionality of the self-hosted CMS.
At first it was very unusual to work with such products as JIRA, SVN. The same Zend at first seemed to be a tweaked monster, after the more familiar PHP Expert Editor.
')
But, after some short time, I felt all the delights of these products. SVN is the best friend and companion in team development, JIRA allows you to quite thoroughly report on the changes made and time spent, Zend is generally almost indispensable thing when working on a huge project. Only autocomplete names of classes, methods and variables (which in such a project are rather verbose, although meaningful) saves a lot of time.
The problem is not in these wonderful software products.
No, the problem is with the rest of these products.
I received the first impression about the considerable benefit of comments when working on a project when I had to restore the history of changes made by me personally at the time of the release of the next version.
This is done simply, there is nothing difficult: SVN -> Show Log (or Show History, if out of Zend) and voila: the date of the commit, the list of files and the comment of each commit. But it was then that surprise awaited me. In the long and impressive list of commits there were quite considerable lacunas in the comments. It looked something like this:
Some comments are more voluminous, and when choosing a specific revision we get a detailed description of the nature of the changes. As a result, I restored the history of my changes in about fifteen minutes. The remaining changes and their character could only be guessed by the tasks created in JIRA.
Maybe it doesn't matter at all. Probably, for many, it is so, but when the number of tasks begins to amount to hundreds, it is problematic even to just remember what kind of changes were made in one or another audit.
Say, there is JIRA to describe the work done. :) Yes, she is. Unfortunately, most of the tasks end up with a general description of the problem (in most cases, compiled by the manager or client) and the verdict “Fixed”. And we all know how often a client has a problem from the category “URGENT! Nothing works!".
And in the end, we have taskki:
About the same sites which it does not work, and how this bug manifests - only the client knows (but can not clearly explain what is in principle clear - he is often not an expert in XML import or ajax requests to the sites of the galactic confederation) , and a brave Jedi developer who figured out this problem (but only the developer will not remember this for long - a week, maximum a month, if the problem is specific and unusual). On the nature of the changes and the work carried out there will be no comment.
Are these brave, but lazy Jedi not aware of those benefits that promise a banal mention of accomplishment? No, just they are aware - for when they disassemble a task with comments, they quickly get to the heart of the problem and solve it, or the consequences of previous accomplishments of the same client. But writing comments yourself is beyond their power.
And one more small example for completeness: raised inside the office a local Wikipedia, accessible only to the computers of our local network, where the base of access to the most frequently used clients actually was. This was done in order not to constantly write letters asking for access, or not to rummage in JIRA with the search for that very first client where there were secret access. Business: got access to the client, looked at the Wiki, if not - added. All - use.
As a result, after a couple of months, it was found that only I and the coder, who quickly got tired of it, scored access there, because they were taking care of him personally anyway, asking him to look at the accesses in his local .doc files. Although I don’t understand what can be difficult, type in the browser: 192.168.0.XXX/wikipedia/, especially since any browser can bookmark this page.
Sadly that's all. And it is not clear how to change this?
During the last almost a year, I work in a team. Before this experience in the team was not at all. I was interrupted by small freelance orders, plus more or less constant cooperation with one of the employers, for a minor refinement of the functionality of the self-hosted CMS.
At first it was very unusual to work with such products as JIRA, SVN. The same Zend at first seemed to be a tweaked monster, after the more familiar PHP Expert Editor.
')
But, after some short time, I felt all the delights of these products. SVN is the best friend and companion in team development, JIRA allows you to quite thoroughly report on the changes made and time spent, Zend is generally almost indispensable thing when working on a huge project. Only autocomplete names of classes, methods and variables (which in such a project are rather verbose, although meaningful) saves a lot of time.
The problem is not in these wonderful software products.
No, the problem is with the rest of these products.
I received the first impression about the considerable benefit of comments when working on a project when I had to restore the history of changes made by me personally at the time of the release of the next version.
This is done simply, there is nothing difficult: SVN -> Show Log (or Show History, if out of Zend) and voila: the date of the commit, the list of files and the comment of each commit. But it was then that surprise awaited me. In the long and impressive list of commits there were quite considerable lacunas in the comments. It looked something like this:
...
...
1984 janson: ...
1983 1:
1982 1:
1981 2:
1980 2:
1979 2:
1978 1:
1977 :
1976 2:
1975 janson: ...
1974 janson: -.
1973 1:
1972 1:
1971 1:
1970 2:
1969 janson: .
1968 :
1967 :
...
Some comments are more voluminous, and when choosing a specific revision we get a detailed description of the nature of the changes. As a result, I restored the history of my changes in about fifteen minutes. The remaining changes and their character could only be guessed by the tasks created in JIRA.
Maybe it doesn't matter at all. Probably, for many, it is so, but when the number of tasks begins to amount to hundreds, it is problematic even to just remember what kind of changes were made in one or another audit.
Say, there is JIRA to describe the work done. :) Yes, she is. Unfortunately, most of the tasks end up with a general description of the problem (in most cases, compiled by the manager or client) and the verdict “Fixed”. And we all know how often a client has a problem from the category “URGENT! Nothing works!".
And in the end, we have taskki:
:
.
:
Fixed.About the same sites which it does not work, and how this bug manifests - only the client knows (but can not clearly explain what is in principle clear - he is often not an expert in XML import or ajax requests to the sites of the galactic confederation) , and a brave Jedi developer who figured out this problem (but only the developer will not remember this for long - a week, maximum a month, if the problem is specific and unusual). On the nature of the changes and the work carried out there will be no comment.
Are these brave, but lazy Jedi not aware of those benefits that promise a banal mention of accomplishment? No, just they are aware - for when they disassemble a task with comments, they quickly get to the heart of the problem and solve it, or the consequences of previous accomplishments of the same client. But writing comments yourself is beyond their power.
And one more small example for completeness: raised inside the office a local Wikipedia, accessible only to the computers of our local network, where the base of access to the most frequently used clients actually was. This was done in order not to constantly write letters asking for access, or not to rummage in JIRA with the search for that very first client where there were secret access. Business: got access to the client, looked at the Wiki, if not - added. All - use.
As a result, after a couple of months, it was found that only I and the coder, who quickly got tired of it, scored access there, because they were taking care of him personally anyway, asking him to look at the accesses in his local .doc files. Although I don’t understand what can be difficult, type in the browser: 192.168.0.XXX/wikipedia/, especially since any browser can bookmark this page.
Sadly that's all. And it is not clear how to change this?
Source: https://habr.com/ru/post/77663/
All Articles