Comments 13
Редкостно хорошая статья на фоне шлака, которым заполняется хабр в последнее время. Спасибо.
Название прямо как из моего первого учебника Паскаля 2002-го года издания)
Содержание, впрочем, в целом тоже оттуда. Что говорит нам о вечных ценностях программирования =))
Похоже на краткий пересказ классики OOA&D без использования UML в контексте популяризации TS.
В статье говорится про js, но и python в последнее время движется в сторону статических анализаторов кода большими шагами. И добавление аннотации типов даже сторонних библиотек.
Честно говоря вообще не представляю себе, как что-то серьёзное может быть написано без системы типов. Хотя народ пишет вполне серьезные вещи и на питоне и на джаваскрипте. И наоборот ругается, что система типов сковывает свободу. Наверно просто мозги у всех устроены по-разному.
Путём чудовищного падения производительности, естественно. Если вбросить огромное количество людей, которые будут писать тесты, то можно. Так программисты дёшевы.
Почему сразу "огромное количество людей"? Написать тесты это примерно как руками прогнать все кейсы. Только тесты остаются и гонять их можно сколько угодно в отличие от "запустить и потыкать руками".
Это сильное преуменьшение — https://habr.com/ru/articles/560370/
Такого негатива можно в какой угодно области понадёргать.
Вот из моей свежей практики. Втроём несколько месяцев пилим маленький бэк под конкретный бизнес на Node.js (Typescript). 23k LOC, где-то 1.5k тестов, покрытие ближе к сотке.
Прогоняется целиком за 5 минут на t2.medium. Причём в процессе написания кода гонять это целиком не требуется. Пишешь свежий кейс (или несколько) да запускаешь только его (несколько секунд). Перед коммитом можешь прогнать всё если не уверен или если залез в сильно реюзабельный код. В любом случае на пулл реквесте ещё прогон будет автоматический. А ещё всё это в принципе нельзя запустить локально кроме как через юнит-тесты.
В итоге код не разваливается, регрессий минимум, при написании кода почти всегда есть очень быстрый фидбек через отдельную точку входа - достаточно запустить отдельный кейс. И кстати этот бэк вообще нельзя поднять локально и руками что-то там протыкать, он как целое только в AWS Lambda заводится.
Короче... Что я делаю не так и почему вдруг это должно быть гораздо труднее? Ещё раз: я не теоретизирую, я уже так строю систему. Да, 100% покрытие != 100% соответствие требованиям (или ожиданиям поведения). Но это один фиг гораздо прочнее, чем грубое ручное тестирование, результаты которого не фиксируются вообще никак.
О, неужели кто-то спустя 20тилетие хваления js за не строгую типизацию, решил посмотреть насколько со строгой типизацией проще и понятней. Хотя видя строку city="Moscow", так и хочется исправить на city=Cities.MOSCOW. Но даже то что написано, уже хоть немного приоткрывает глаза js разработчикам, на то, как должно хоть немного правильней выглядит ООП.
Если функция, вызывающая generateInvoice, не знает, какой должна быть taxRate, то я добавляю во входные данные этой функции taxRate и продолжаю выполнение вверх по стеку вызовов. Рано или поздно я достигну функции, способной подтянуть необходимый контекст
Разве это правильный подход протаскивать taxRate через весь стек вызовов? Меня это место в вашей статье смутило.
праздники не прошли бесследно, я прочитал:
"Как типы́ делают сложные задачи простыми", ожидая совсем другого.
p.s. был как-то на проекте, где данные гоняли через void*
Как типы делают сложные задачи простыми