1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/wizardforcel-lmpythw-zh

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
ex27.md 8.9 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
Отправлено 06.03.2025 03:52 f9ec0dd

Упражнение 27: tr

Оригинал: Упражнение 27: tr

Переводчик: Феликс Ли

Лицензия: CC BY-NC-SA 4.0

Гордо использует Google Translate

Это упражнение продолжает обучение методике TDD (тест-драйв развития) или "разработка с тестами". Важно знать, как так программируется, поскольку этот подход используется во многих местах, но, как было отмечено ранее, он имеет свои ограничения. При реализации команды tr вы снова будете использовать TDD для практики. Убедитесь, что вы строго пишете тесты перед тем, как писать код, а затем проверяете оба этих компонента.

В прошлом упражнении я попросил вас постепенно создавать тестовые случаи и код. Это обычно самый надёжный способ разработки, но он не помогает вам лучше анализировать свой код. В этом упражнении вы сделаете немного другое: я напишу полный тестовый случай, проведу его аудит, а затем напишу весь код, проведу его аудит и подтвердите аудит выполнением тестов.

Это значит, что ваш процесс в этом упражнении будет таким:+ Попробуйте написать большую часть тестовых случаев TDD.

  • Аудируйте тестовые случаи и подтвердите, что они правильно написаны.
  • Выполните тесты, чтобы убедиться, что они проваливаются, но найдите любые синтаксические ошибки. На данном этапе вы должны быть свободны от синтаксических ошибок.
  • Напишите код для тестового случая, но не выполняйте тесты.
  • Аудируйте свой код и попытайтесь найти количество недочетов до выполнения тестов.Вы будете использовать этот процесс в следующем упражнении для отслеживания ваших навыков аудита, метрик тестирования и лучшего контроля над тем, как вы пишете код.

Часто задаваемые вопросы

Инструмент tr является эффективным способом перевода потока символов. Хотя он очень простой, он может выполнять сложные операции со символами. Например, можно использовать tr, чтобы получить частоту использования слов в истории команд одной строкой кода:

history | tr -cs A-Za-z '\n' | tr A-Z a-z | sort | uniq -c | sort -rn

Это кажется крутым, но Дуг МакИлроу использовал эту строку для того, чтобы утверждать, что программа Дональда Кнута слишком длинна. Реализация Кнута составляет "десять страниц", начиная всё с нуля. Одна строка Дуга просто использует стандартные Unix-инструменты для выполнения такой же работы. Это демонстрирует мощь трубопроводов Unix и способность tr перевести текст. Используйте страницы руководства и любую другую информацию, чтобы выяснить назначение команды tr. Также существует проект с таким же названием на Python, но я рекомендую вам пока его избегать до завершения реализации, так как потом можно будет сравнить этот проект. При этом не забывайте, что вам потребуется создать полный проект в тесто-драйв стиле (TDD), то есть сначала пишите тесты, а затем код, который проходит эти тесты, как это указано в моём первоначальном описании.

Критика 45-минутной методикиЯ хочу, чтобы вы продолжали использовать 45-минутные временные отрезки, но есть существенная критика относительно этого подхода: вы не можете войти в расширенный режим концентрации. Временной рабочий день может помочь при необходимости выполнения большого объема работы и ускорения темпа, особенно когда работа становится скучной и однообразной. Я заставляю вас использовать 45-минутные временные отрезки для ускорения своей работы, однако мы также будем использовать их позднее для сбора данных и анализа того, как вы работаете во времени.

Однако стоит отметить, что лучшая программная деятельность происходит в состоянии полной концентрации. Это состояние, когда ваше внимание сосредоточено на работе несколько часов, вы теряете чувство времени до самого утра, осознавая, что провели целую ночь за работой. Такое глубокое погружение делает программирование для меня невероятно приятным, но это действительно устойчиво, если вам интересна работа, которую вы выполняете. Когда же вам приходится иметь дело с плохими кодами других людей, такое состояние обычно не возникает. В таких случаях требуется другой подход, который бы помог ускорить работу и избавиться от проблемы, не снижая вашего энтузиазма. Именно такова роль 45-минутных временных отрезков.Наконец, способность входить в рабочее состояние и концентрироваться несколько часов можно развивать, начиная с короткого времени и постепенно увеличивая его, пока вы не сможете выдерживать более длительные периоды. Продолжайте использовать 45-минутные временные отрезки, но если вы просто полностью погрузитесь в работу и завершите чертовски сложные задачи в последние часы, то пусть будет весело. Никто не станет говорить вам, что вы сделали что-то неправильное, это вполне нормально.

Исследовательское обучение

  • Как тебе этот подход? Нравится ли он тебе? Объясни почему, затем прочитай некоторые современные статьи о тест-диривед жест (TDD) или его близкий родственник поведенчески ориентированное развитие (BDD).

  • Считаешь ли ты, что аудит своего кода перед поэтапным его созданием позволяет находить больше или меньше ошибок? Предположи ответ, а затем запиши его.

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/wizardforcel-lmpythw-zh.git
git@api.gitlife.ru:oschina-mirror/wizardforcel-lmpythw-zh.git
oschina-mirror
wizardforcel-lmpythw-zh
wizardforcel-lmpythw-zh
master