Виберіть структуру, яку зможете пояснити
Створіть теку з назвою проєкту, а потім кілька місць із чіткими ролями. Ім'я людини чи сьогоднішня дата не завжди дають зрозуміти вміст через шість тижнів. Нотатка в корені має пояснювати, де знаходяться вхідні файли, поточні спроби та затверджена поставка.
Кембриджський університет рекомендує заздалегідь узгодити класифікацію та послідовні правила найменування. Наведена нижче модель — пропозиція BriefGPU для невеликого сеансу. Адаптуйте її, якщо ваше програмне забезпечення вже задає структуру проєкту; не переміщуйте пов'язані з ним ресурси, не переконавшись, що проєкт їх знаходить.
| Emplacement proposé | Ce qu’il contient | Règle de travail |
|---|---|---|
| 00_lire-moi.txt | Мета, план тек та затверджена спроба. | Оновлюйте важливі рішення. |
| 01_entrees | Отримані джерела та ідентифіковані версії. | Не зберігайте тут результати обробки. |
| 02_reglages | Параметри та версії інструментів для кожної спроби. | Зберігайте налаштування, які справді використовувалися. |
| 03_sorties/essai-01 | Результати ідентифікованого запуску. | Створіть іншу теку для наступної спроби. |
| 04_suivi | Інвентар, журнал і відгуки перевірки. | Пов'яжіть кожен результат із його джерелом. |
| 05_livraison/v01 | Добірка, готова до передачі. | Позначайте будь-яку нову версію поставки. |
Зберігайте отриманий вхідний файл упізнаваним
Перед першою обробкою складіть список джерел із їхніми початковими назвами та місцезнаходженням. Збережіть незмінну версію цих вхідних файлів, як рекомендує Cornell для необроблених даних. Сама лише назва «оригінали» не захищає вміст: вкажіть програмі іншу теку для виводу та перевірте її поведінку на тестовому файлі.
Якщо вам потрібно конвертувати чи обрізати вхідний файл перед обчисленням, розглядайте цю підготовку як окремий ідентифікований етап. Зберігайте зв'язок з отриманим джерелом. Тоді ви зможете відрізнити дефект, який уже був, проблему підготовки та вплив обробки GPU.
Коли нове джерело замінює старе, занотуйте версію та результати, які потрібно переглянути. Не перезаписуйте мовчки файл, використаний у спробі, яку хочете зрозуміти. Правило — зберігати корисне походження, а не тримати всі робочі копії безстроково.
Дайте стабільний ідентифікатор кожній одиниці роботи
Короткий ідентифікатор, як-от image-001, слугує для відстеження того самого вхідного файлу в кількох спробах. Його роль не змінюється, коли результат прийнято. Зберігайте стан перевірки в інвентарі, а не перейменовуйте файли без кінця на «добрий», «поганий» чи «майже-фінал».
Для ста вхідних файлів номери від 001 до 100 дають рівномірний орієнтир. Додайте змістове позначення, коли воно потрібне для поставки. Не припускайте, що два файли під назвою photo.png, отримані в різних підтеках, означають одне й те саме. Повний шлях вхідного файлу має залишатися пов'язаним з ідентифікатором.
Вибирайте назви, сумісні з інструментами призначення. Windows, зокрема, зарезервовує символи двокрапки, знака питання та зірочки; його звичайні правила також не дають змоги надійно розрізняти дві назви лише за великою літерою. Назва, як-от image-007_essai-02.png, уникає цих неоднозначностей. Перевіряйте обмеження, властиві вашим іншим інструментам, а не обіцяйте універсальну сумісність.
Приклад: дві спроби, одна колекція джерел
Припустимо, отримано вісім зображень у двох теках. Інвентар присвоює їм ідентифікатори image-001 — image-008 і зберігає їхні початкові шляхи. Перший прохід використовує налаштування essai-01; усі його результати потрапляють у відповідну теку. Дефект на image-003 і image-006 призводить до другого проходу, обмеженого лише цими двома елементами.
Шість задовільних результатів першого проходу не перераховуються, щоб зробити теку одноріднішою. Інвентар показує, який результат було обрано для кожного елемента. Поставка v01 містить вісім файлів із очікуваними назвами, навіть якщо їхнє походження розподілене між двома проходами. Цей приклад описує організацію, не припускаючи, що налаштування обов'язково покращують результати.
| Entrée | Sortie retenue dans l’exemple | Réglages à retrouver | État |
|---|---|---|---|
| image-001 | 03_sorties/essai-01/image-001.png | 02_reglages/essai-01.txt | Прийнято |
| image-003 | 03_sorties/essai-02/image-003.png | 02_reglages/essai-02.txt | Прийнято після повторної обробки |
| image-006 | 03_sorties/essai-02/image-006.png | 02_reglages/essai-02.txt | Прийнято після повторної обробки |
Зберігайте налаштування під час проходу
Файл з назвою essai-02.txt може бути простою нотаткою, якщо програма не вміє експортувати свої параметри. Запишіть версію інструмента, можливу модель, відповідні вхідні дані та обрані вами значення. Додайте причину зміни порівняно з попереднім проходом. Скриншот може доповнити нотатку, коли параметри видно лише у вікні.
Уникайте єдиної нотатки «поточні налаштування», яку замінюють після кожного проходу. Вона пояснювала б останню спробу, але вже не старі результати. Якщо кілька проходів використовують ті самі параметри, посилайтеся на ту саму позначену конфігурацію, а не копіюйте її без потреби.
Версія програми та параметри допомагають пояснити результат; самі по собі вони не гарантують ідентичного відтворення. Деякі застосунки вимагають іншої інформації чи ресурсів. Дотримуйтеся їхньої документації для точного відтворення, зокрема коли йдеться про стан навчання.
Ведіть журнал, який пояснює рішення
Журнал доповнює інвентар. Інвентар відповідає на запитання «на якому етапі цей елемент?»; журнал відповідає на запитання «чому ми щось змінили?». Достатньо кількох рядків із датами: відповідний прохід, спостереження, рішення та наступна перевірка. Уникайте копіювання кожного повідомлення програми, якщо ним ніхто не зможе скористатися.
Для прикладу корисний рядок був би таким: «essai-01: неповні контури на image-003 і image-006; повторити ці два елементи з налаштуванням B; залишити інші результати в очікуванні фінального підтвердження.» Після перегляду додайте фактичне рішення. Не переписуйте початкове спостереження так, ніби дефекту ніколи не було.
Перегляньте технічні журнали перед передаванням: вони можуть містити приватні шляхи або засоби доступу. Тримайте секрети окремо від документальної теки. Нотатка, призначена колезі, має пояснювати роботу з інформацією, яка йому потрібна.
Розрізняйте впорядкування, поставку та резервне копіювання
Робоча тека зберігає проходи, корисні для ваших міркувань. Тека поставки збирає те, що має отримати адресат. Резервна копія зберігає потрібні елементи в іншому місці, з перевіркою копіювання. Три теки, розміщені поряд в одному просторі, самі по собі не виконують ці три функції.
Не копіюйте всі джерела в кожну теку проходу. Пов'язуйте результати з вхідними даними через інвентар. Для поставки може бути корисною дібрана копія, щоб передати автономний набір; тоді зазначте її походження та версію. Для резервного копіювання дотримуйтеся окремого посібника, який детально описує інвентар і перевірку після перенесення.
Перш ніж прибирати відкинуті варіанти, перевірте ті, що залишаються потрібними для пояснення рішення чи повторного виконання роботи. Ця організація не встановлює жодного строку зберігання. Вона дозволяє вирішити, що варто зберегти, а потім знайти копію, яка є взірцевою.
Зробіть перевірку на випадково обраному результаті
Оберіть файл поставки, не відкриваючи спершу вашу програму. За його назвою та інвентарем знайдіть його вхідний елемент, прохід, який його створив, його налаштування та рішення про прийняття. Повторіть із результатом, який потребував повторної обробки. Якщо цей шлях залежить від вашої пам'яті, у супроводі бракує ланки.
Потім перевірте кількість: запланована кількість входів, відібрані результати, заблоковані елементи та виключені варіанти. Навіть добре впорядкована тека може бути неповною. Ця невелика перевірка завершена, коли розбіжності мають пояснення і хтось інший може зрозуміти, які файли використовувати.