Лучшие практики для комментариев к фиксации кода
Посмотрев на эту функцию, я могу себе представить, что сбой, который вы видите, - это CollectionView, прокручивающий вперед, а затем резиновый / телепортирующийся назад.
Я думаю, это может произойти, потому что вы пытаетесь запустить две анимации одновременно. Ваша первая анимация, UIView.animate (), анимирует прокрутку к новому вставленному элементу; однако, когда вы вызываете collectionView? .scrollToItem (), вы также анимируете это (см. ниже)
self.collectionView?.scrollToItem(..., animated: true) <--
. Вероятно, поэтому оно не работает; Вы пытаетесь оживить анимацию. Попробуйте установить для animated значение false и посмотрите, исправит ли это.
11 ответов
Here are my thoughts... all these will be open to interpretation depending on your particular development methodologies.
- You should be committing fairly often, with a single focus for every commit, so based on that, comments should be short and detail what the focus of the commit was.
- I'm a fan of posting the what in your comment, with the why and the how being detailed elsewhere (ideally in your bug tracking). The why should be the ticket, and upon closing the ticket, you should have some kind of note about how that particular issue was addressed.
- A reference to your bug tracking system is good if it isn't handled otherwise (TRAC/SVN interaction, for example). The reason for this is to point other developers in the right direction if they're looking for more information on the commit.
- Don't include specific file names unless the fix really complex and detail is needed. Even still, complex details probably belong in bug tracking with your implementation notes, not in version control. Files edited, diff details, etc, should hopefully be included with version control, and we don't want to spend time duplicating this.
Given these ideas, an example commit comment for me would be something like
Req3845: Updated validation to use the new RegEx validation developed in Req3831.
Short, communicates what was changed, and provides some kind of reference for others to get more info without hunting you down.
If you use a bug tracking system, include relevant ticket numbers.
You do not need to mention changed files, or your name. The source repository can figure that out by itself. Describing the changes also only makes sense if it is not non-trivially obvious from the diff.
Make sure you have a good first line, because this frequently appears in the change history view, and people need to find things by this (the bug tracking ticket number should go there, for example).
Try to commit related changes in a single changeset (and split unrelated changes into two commits, even if to the same file).
Проблема больше связана с Java, чем с чем-либо еще. Вы не можете изменить тип экземпляра во время выполнения (во время выполнения), поэтому hibernate не предусматривает такого рода сценариев (в отличие, например, от rails).
Если вы хотите исключить пользователя из сеанса, вы будете должны выселить связанные лица. У вас есть несколько вариантов:
- Сопоставить объект с помощью evict = cascade (см. Session # evict javadoc)
- Вручную удалить все связанные объекты (это может быть громоздким)
- Очистить сеанс, таким образом, исключая все сущности (конечно, вы потеряете локальный кеш сеанса)
У меня была похожая проблема в grails, и мое решение аналогично решению Григория . Я копирую все поля экземпляра, включая связанные сущности, затем удаляю старую сущность и пишу новую. Если вы не
I try to follow the same rule as for code comments:
Explain the WHY, not the HOW.
IMO a comment should contain a reference to the issue (task tracker, or requirement). Which files are affected is already available from the version control system. Apart from that, it should be as short as possible, but still readable.
I try to keep my fixes in separate check-ins.
I don't use an actual template, but a mental one, and it's like this.
Issue - dev level summary of issue.
The issue tracker has all the management details, and the changes/diffs can be reviewed for code changes, so the comment is for dev's to understand the why/what of the issue.
Вот что я видел успешно использованное:
- Ссылка на номер ошибки или идентификатор функции
- Краткое описание изменения. Что было изменено.
- Рецензент кода (чтобы убедиться, что он у вас есть), если он не обрабатывается системой проверки.
- Имя тестировщика или описание того, какие тесты были запущены (если процесс запаздывает и вы проявляете особую осторожность)
Я использую простую технику, описанную Хаосбеном в блоге JEDI для Windows API .
Для быстрого просмотра изменения, внесенные в хранилище, мы Предлагаю написать краткое лаконичное комментарии, начинающиеся с каждой строки по одному из этих символов:
- + , если вы добавили функцию / функцию /…
- - , если вы удалили функцию / функцию / ошибку /…
- # , если вы что-то изменили
Делая это таким образом, другие разработчики могут найти нужную версию гораздо лучше.
Keep in mind that if someone needs details of what changed, they can get a diff. That said, I just usually write a sentence or two for each major change, and then lump any minor fixes at the end.
Во-первых, коммиты должны решить одну проблему (отдельные коммиты для логически отдельных изменений). Если вы не знаете, что написать в сообщении коммита, или сообщение comit слишком длинное, это может означать, что у вас есть несколько независимых изменений в вашем коммите, и вы должны разбить его на более мелкие элементы.
Я думаю, что коммит Соглашения о сообщениях, ожидаемые и используемые git , имеют большой смысл:
- В первой строке сообщения о фиксации должно быть краткое описание
- Если это уместно, префикс упомянутой выше итоговой строки с префиксом подсистемы, например, «docs: "или" contrib: "
- В следующем абзаце или параграфах опишите изменения, объяснив, почему и как
There is no hard and fast rule as its plain english. I try to explain the work done in minimum words possible. Anybody looking for history of changes just want to know what happened in a particular change. If anybody is after more details then its there in the code.
Second thing I follow is if there is any bug associated then stick that in or if its related to any dev task then associate that with the change.
Если два файла были изменены по разным причинам, они должны быть в разных коммитах. Единственный раз, когда вы должны зафиксировать более одного Файл кода за раз состоит в том, что все они принадлежат одному и тому же исправлению / изменению