Еще одно преимущество истории в Visual SourceSafe – она хранит копии всех загруженных на сервер изменений. Какие изменения произошли после блокировки и до отпуска файлов не сохраняются. В IDE большинства сред разработки промежуточные файлы создаются при каждом сохранении модуля. Опытные программисты нажимают Ctrl+S очень часто, поэтому промежуточных копий будет много и найти в них что-то полезное порой просто нереально.
Когда нужно узнать историю, можно всегда просмотреть ее с помощью встроенного редактора VSS или открыть для редактирования в соответствующем типу файла редакторе на вашей машине. Но просмотр истории – это пол дела, вы также можете сравнить два файла и увидеть, какие изменения внес определенный программист и примерно определить время этих изменений. Если над одним модулем может работать несколько программистов, то возможность визуального сравнения очень помогает определить того, кто именно наделал ошибок. Ведь чаще всего, при обнаружении ошибки, никто не сознается, кто именно допустил баг.
В Delphi иногда бывает необходимость временно установить какое-либо свойство в модуле, который не забран или не может быть забран в данный момент. Для этого достаточно только перейти в исходный код, щелкнуть правой кнопкой по закладке с именем модуля и снять свойство Read only. Тут нужно понимать, что для редактирования открывается модуль, загруженный в Delphi, а сам файл остается только для чтения. Это значит, что все изменения невозможно будет сохранить, а при попытке сделать это, увидите сообщение Is read-only file.
При работе с Fast Report в Delphi могут возникнуть проблемы. Редактор построения отчетов будет загружаться с ошибками, если модуль, на котором установлен компонент TfrxReport, открыт только для чтения. Чтобы избежать ошибок, перед открытием редактора отчетов необходимо снять Read only с модуля. С файла этот признак снимать необязательно.
Когда над проектом работает целая команда программистов, то вам просто необходима система управления исходными кодами. Она позволяет контролировать процесс работы над кодом и при правильном подходе даже гарантировать, что два человека не внесут изменения в один и тот же модуль и не помешают друг-другу. Если вы никогда не будете изменять файлы, предварительно не забрав их, то вы никогда не затрете чужие изменения.
Если есть какие-то вопросы, я всегда готов ответить. Желательно через WEB сообщения моего сайта, потому что через почту в последнее время приходит слишком много спама.
Некоторые считают, что при использовании VSS и подобных программ можно любому программисту из команды работать над любым модулем и ничего страшного не произойдет. В принципе, это верно, но только если все программисты имеют одинаковое образование, одинаково пишут код и самое главное – одинаково мыслят. Я такое могу себе представить с большим трудом. Каждый пишет и мыслит по-своему. Очень трудно встретить двух людей, которые напишут код и построят логику работы функции одинаково, если только функция не складывает два числа, а делает что-то более сложное.
Каждый программист, обратившись к коду, написанному другим человеком должен потратить время на изучение того, что уже написано, что нужно и что нужно сделать, чтобы добавить новый функционал или исправить ошибку. Если модуль маленький, то это отнимет не много времени, но если в нем 500 и более строк, то затраты на изучение уже созданного другим человеком могут быть большими.
Когда над одним модулем работает несколько человек с разными подходами, то со временем логика кода станет не читаемой, а если еще и каждый будет оформлять код по своему, то код превратиться в мусор.
Не смотря на то, что весь исходный код проекта хранится в одном большом хранилище, над каждым модулем и над каждой отдельной задачей большого проекта должен работать отдельный человек. Это реально сможет повысить производительность работы, и качество кода в отдельно взятом модуле.
Если кто-то не может решить какую-то отдельную задачу, то не стоит направлять ее другому человеку. Необходимо помочь найти решение, но не нужно перебрасывать задачи от одного программиста к другому.
Когда вы работаете в команде, очень важно, чтобы все использовали один и тот же метод именования переменный их функций. Все имена должны быть максимально понятными и наглядными. Необходимо забыть про переменные типа Str, Temp и т.д. Помните, что когда вы уйдете в отпуск, и с кодом возникнут проблемы, то с ним придется разбираться вашим же товарищам. Да и вы тоже можете оказаться в такой же ситуации.
Старайтесь использовать максимальное количество комментариев. Да, зачастую их писать не очень интересно и не хочется тратиться на это время, но зато поможет сэкономить время всей команды программистов в будущем. Через пол года, без комментариев с вашим кодом с ходу не разберется не то, что другой программист, но и вы сами.
Всем, кто работает в команде, я бы порекомендовал прочитать книгу «Совершенный код: Практическое руководство по разработке программного обеспечения» Стива Макконелла. Эту же книгу можно прочитать и программистам одиночкам, но в команде она просто необходима.
Внимание!!! Если ты копируешь эту статью себе на сайт, то оставляй ссылку непосредственно на эту страницу. Спасибо за понимание
Паника, что-то случилось!!! Ничего не найдено в комментариях. Срочно нужно что-то добавить, чтобы это место не оставалось пустым.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
На сайте используются Cookie. Если вы из ЕС или Калифорнии США, то вы должны согласиться с их использованием - Согласен. Если вы из нормальной страны, то вам пох.
Добавить Комментарий