Comments 27
FizzBuzz на разных языках на сайте Rosettacode
P.S. В том числе и на Forth.
На Питон, тоже несколько вариантов.
Форт решение выигрывает по количеству «буковок» затраченных для описания решения. :)
По-моему, для сравнения будет правильнее привести вот эту нестареющую классику
Остановились на середине. setup.py, requirements.txt, entry points.
ci/cd — это уже delivery pipeline, а setup.py — то, как его ставить. Даже если ci/cd нет, процедура установки всё равно какая-то должна быть. И scp ~developer/git/mywork/foobar.py root@production:/var/www/production/, это явно не то, что хочется видеть в продакшене. Даже если это пятистрочный питон.
Иными словами несмотря на довольно занимательную идею пример прям активно демонстрирует позицию тех кто сравнил этот метод с «пальбой из пушки по воробьям»
Вот исходный код Python-скрипта, который позволяет решить задачуИ по идее, после кода должен быть конец.
Конечно, в данном контексте эту задачу взяли для наглядности из-за ее компактности и минимального содержания, которое бы хоть как-то оправдывало ее обвязку и расширение.
Переводчику я должен заметить, что у источника в заголовке слово «sustainable», которое я бы в данном контексте перевёл не как «надежный», или «прочный», а скорее — «долговечный». Тогда все вроде становится на свои места. Ведь, если мы увеличили сложность всего решения, а она очевидно возрасла в разы, то надежность будет неминуемо падать. Простое перемножение вероятностей. Так что, нельзя с уверенностью утверждать, что мы увеличили надежность скрипта, несмотря на то, что все описаное и является «хорошим тоном» в программировании. А вот «долговечность» такого кода увеличивается.
если мы увеличили сложность всего решения, а она очевидно возрасла в разы, то надежность будет неминуемо падать. Простое перемножение вероятностей. Так что, нельзя с уверенностью утверждать, что мы увеличили надежность скрипта
Если добавили своего кода, то да, если использовали готовые надежные модули, то сложность растет уже не так катастрофически.
Добавить проверку аргументов командной строки: fizz != buzz, оба не равны 0, start <= end + 1
Многие свойства click — не самая лучшая идея для приложения, которое нужно хорошо протестировать, хоть и хороша для очень маленьких демо-проектов, помещающихся в одном файле.
То, с чем столкнулся я и почему перестал использовать:
- "положим всё в декораторы!" — хорошо, но очень много магии и труднее протестировать. Разделяй реализацию метода и вызов.
- порядок аргументов очень важен, click позволяет только сортированный
* antipattern "магическое состояние, которое хранится в каком-нибудь одном модуле". Его нет в aiohttp и других asyncio фреймворках (из request можно достать app, в котором можно что-то сохранить, если нужно). "explicit is better than implicit"
- argparse можно найти обычно в одном из модулей, если необходимо, некоторые проекты документируют
- читать docstring, на который нет стандарта в поисках документации… часть он угадает, часть — нет (
explicit is better than implicit) - Monkey-patching для вывода ошибок? нет, спасибо. Это последнее, что нужно в Python. Если вы пришли из Ruby, пожалуйста, научитесь писать нормально.
Например
Python 3.7.2 (default, Feb 19 2019, 13:23:50)
Type "help", "copyright", "credits" or "license" for more information.
>>> import click
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'click'
>>>
Вы написали логгер и аргпарс руками хотя могли бы использовать docopt и loguru и код увеличился бы едва ли на десять строк.
Поговорим о том, как его улучшить.может просто применить решето Эратосфена заместо трёх проверок числа на каждое значение
А зачем вам простые числа?
Вычислять до какого предела? А если чиселка с внешнего пайплайна пришла? Какой-нибудь деревянный вариант балансира, который по облачному id определяет на какой из трех серваков подать нагрузку. Решета нужны когда есть шанс переиспользоваться в одном запуске, и в случае fizzbuzz оно точно не эратосфеново
Разработка надёжных Python-скриптов