The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Во-первых, независимо от методологии, мы все пишем программное обеспечение для наших пользователей (также известных как клиенты, спонсоры проекта, конечные пользователи или клиенты). Во-вторых, независимо от методологии, мы пишем постепенно, выпуская функции и исправления ошибок по одной. Возможно, я говорю что-то абсолютно очевидное, но важно помнить, что каждая новая версия должна прежде всего удовлетворять потребностям пользователя, а не нам, программистам. Другими словами, способ, которым мы разбиваем большую задачу на меньшие части, должен быть направлен на пользователя, и поэтому вы всегда работаете сверху вниз. Давайте посмотрим, что я имею в виду на практическом примере.
Предположим, что мой друг заключил со мной контракт на создание инструмента командной строки для подсчета слов, очень похожего на wc. Он обещал заплатить мне $200 за эту работу, и я пообещал ему, что предоставлю продукт в двух итерациях: альфа-версии и бета-версии. Я пообещал ему, что выпущу альфа-версию в субботу, а бета-версию в воскресенье. Он собирается заплатить мне $100 после первого выпуска и остаток после второго выпуска.
Я напишу на C, а он заплатит наличными.
Инструмент очень примитивный, и мне понадобилось всего несколько минут, чтобы его написать. Взгляните на него:
Но будем профессионалами и не забывайте о автоматизации сборки и модульном тестировании. Вот простой Makefile, который выполняет оба этих действия:
Теперь я выполняю команду make из командной строки и получаю следующий результат:
All clean!
Я готов получить свои 200 долларов. Подождите, сделка заключалась в том, чтобы предоставить две версии и получить деньги в два этапа. Давайте немного отклонимся и подумаем - как мы можем разделить этот небольшой инструмент на две части?
С первого взгляда, давайте сначала выпустим сам инструмент, а затем создадим автоматизацию и тестирование. Это хорошая идея? Мы можем предоставить какое-либо программное обеспечение без запуска его сначала с тестом? Как я могу быть уверенным, что оно работает, если я не отправлю тесты вместе с ним? Что подумает мой друг о том, что я выпускаю что-то без тестов? Это будет полное осрамление.
Хорошо, давайте сначала выпустим Makefile, а затем wc.c. Но что мой друг будет делать с несколькими тестами и без готового продукта в руках? Этот первый выпуск будет абсолютно бессмысленным, и я не получу свои 100 долларов.
Теперь мы подходим к сути этой статьи. Что я пытаюсь сказать - каждое новое приращение должно добавлять какую-то ценность продукту, как это воспринимается клиентом, а не нами, программистами. Makefile определенно является ценным артефактом, но он не предоставляет никакой ценности для моего друга. Он не нужен, но мне нужен.
Вот что я собираюсь сделать. Я выпущу каркас инструмента, поддерживаемый тестами, но с абсолютно бесполезной реализацией. Посмотрите на это:
И я внесу соответствующие изменения в Makefile. Я отключу первый тест, чтобы убедиться, что сборка проходит успешно.
Работает ли моя программа? Да, она работает. Подсчитывает ли она слова? Да, для некоторых входных данных. Имеет ли она ценность для моего друга? Конечно! Он может запустить ее из командной строки и передать файл в качестве входного параметра. В результате подсчета он всегда получит число “5”, хотя это и не очень хорошо, но это альфа-версия. Он не ожидает, что она будет работать идеально.
Тем не менее, она работает, она поддерживается тестами и правильно упакована.
То, что я только что сделал, является топ-даун подходом к проектированию. Прежде всего, я создал что-то, что приносит пользу моему клиенту. Я также удостоверился, что она соответствует моим техническим задачам, таким как правильное покрытие модульными тестами и автоматизация сборки. Но самой важной целью для меня было убедиться, что мой друг получил что-то… и заплатил мне.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-16 at 15:45
