Выводы на будущее после написания тысяч строк Python кода на днях

Что: 29b8be0b348b6e1580fc5fdfa86cd8efaa8cbd1a

Когда: 2017-09-25 23:50:13+03:00

Темы: python

Выводы на будущее после написания тысяч строк Python кода на днях

Не выходил я толком из дома уже неделю и писал писал кучу Python кода.
На работе мы конечно давно исповедуем некоторые мантры, но в очередной
раз убедился в их пользе и для меня уже просто неоспоримом преимуществе:


	
рефакторить только после покрытия тестами. После хорошего покрытия,

  типа 100%. Лучше сначала дописать как есть, покрыв тестами, а потом
  рефакторить

	
использовать coverage. Если pylint/flake8/mypy/whatever просто

  помогают чуть сократить время нахождения недочётов, если тесты покажут
  только те проблемы, что были оформлены явно человеком в этих тестах,
  как он их видит и представляет, то coverage это über вещь,
  показывающая то, что человек которому этот coverage пальцем тычет в
  строчки кода, он всё-равно не поверит что они не покрыты, ведь вот же
  прям отдельно для этих случаев специально написан же тест. Что на
  работе, что вот в личных проектах -- coverage показывает то, чего
  люди, команда людей, в упор не видит. Потрясающая по своей простоте и
  эффективности повышения качества кода штука

Отдельно для себя ещё намотал на ус что всякие составные if-ы (if condA
or condB) имеет смысл писать отдельными if-ами, чтобы сделать из этого
два ветвления, два statement. Coverage не раз мне показал что одна из
час��ей этого условия никогда не покрывается, а я ведь был уверен, так
уверен.

Ну и quickfix-подход, а именно Hypothesis библиотека
(http://hypothesis.readthedocs.io/), очень и очень здорово помогает.
Требуется конечно порог вхождения чтобы научиться писать тесты под неё.
Часто приходится возиться с оптимизацией стратегий, так как могут быть
очень медленными, но оно всё стоит того. Мало того что оно просто
помогает писать меньше тестов, так ещё и как небольшой fuzzer работает.

оставить комментарий

Сгенерирован: SGBlog 0.34.0