Ебанатика - наука точная

2021-06-23 00:32:45 чтобы хорошо программировать на scala надо убить лет 10 на ассемблере Открыть/Комментировать

2021-06-15 01:58:47 Хз, что вы там настраиваете, обычно процесс ознакомления с софтом == 2 недели + 2 недельки немного поковырять что-то, не больше... Открыть/Комментировать

2021-06-02 02:30:23 На текущий момент, используя тесты около 8 лет, с разной интенсивностью, могу сказать следующее: Имеет смысл покрывать тестами только переиспользуемый код. Какие-то функции ядра вашего приложения. То, что вызывается из множества мест вашего приложения. Или тестом стоит фиксировать сложно уловимый баг.
Конечный код, который формирует http ответ, или рисует гуй или ещё что-то тестировать смысла нет. И вот теперь почему:
1. Тесты это действительно код, и код которые требует затрат на содержание.
2. Количество тестов растёт. И затраты на них тоже. Часто можно обнаружить что тесты растут быстрее самого приложения. Мы очень редко удаляем код, в тесты удаляются ещё реже. Когда есть тысяча работающих тестов, никто не пойдёт удалить 500 из них. Да, начинается деление на сьюты постоянных и страховочных, но затраты на содержание никуда не уходят.

Ну и самый главный вопрос, сколько тестов писать: ровно столько, сколько нужно для вашей персональной уверенности, с небольшой оглядкой на команду. В идеале тестов должно быть столько чтобы каждый член команды был уверен что всё ок. И это не 100% покрытие Это скорее что-то около 10%. Ядра системы как правила меньше чем куча нашлёпок по интеграции внешних апи, гуи и прочего одноразового кода. Чем чаще что-то меняется тем нужнее там тест(и помните что цена растёт с частотой изменений). А чем больше тестов, тем выше цена поддержки. Таким образом стоимость поддержки тестов на часто меняющуюся систему растёт, от времени, сверхлинейно, и никогда не имеет тенденций к снижению. Открыть/Комментировать

2021-05-25 13:41:48 Типа такого нарисуешь, потом понятней, как писать) Открыть/Комментировать

2021-05-25 13:41:48 Открыть/Комментировать

2021-05-25 13:41:48 Кастуешь UML :) Открыть/Комментировать

2021-05-18 19:30:04 имхо статическая типизация была придумана в ЯП как костыль, чтобы правильно выделять и освобождать память. И ведь к этому костылю все настолько привыкли, что считают это необходимостью. Да, она позволяет во время компиляции оптимизировать код и отловить 1% ошибок с неправильной передачей параметров. Но чем более высокоуровневый язык, тем меньше пользы и больше головной боли от статики. Для эрланга это вообще бесполезная если даже не вредная хрень. Хотя диалайзер - отличная штука и часто выручает Открыть/Комментировать

2021-05-18 14:14:07 Проблема не в академиках, а в фундаментальном непонимании, что язык такое. Что сокращение кода — не цель. Единственная цель — читабельность кода, быстрая и однозначная. Сокращение этому не поможет, если оно не даёт компактности записи, а оно не даёт. С точки зрения человека пустое пространство — мусор для зрительной памяти, а вот механизмы очистки от этого мусора, мягко скажем, ДРУГИЕ, чем те что предполагает язык. В результате код воспринимается по внешнему виду, и это восприятие доминирует. Читаются совсем другие связи, чем те что будут прочитаны машиной. В результате ошибки не видны.

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

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

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

По той же причине я против засилия синтаксического сахара и в Java. Да, код выходит короче, но в отличие от компилятора, читатель не может сделать «подковёрную работу» со сколь-либо вменяемой скоростью. А читать-то надо раз в 100 быстрее, чем код пишется. И что ещё важнее, в 100 раз чаще. Сокращение скорости написания ценой снижения читабельности — это тот самый «нинзя-кодинг», то есть саботаж, отравление проекта. И в отличие от прямой обфускации, не даёт права потом принять решение всё переписать как надо, типа там же всё хорошо. Прекрасная маркиза. Открыть/Комментировать

2021-05-13 15:42:27 https://www.hackster.io/news/the-lisperati1000-is-a-cyberdeck-terminal-dedicated-to-lisp-programming-bb564f2ffcff

If you’re new to coding and want something easy to use, Python is great. For performance and capability, it’s hard to beat programming in C. But if you need some complex algorithms — particularly algorithms that do a lot of heavy mathematical lifting — then Lisp is the ideal choice. Открыть/Комментировать

2021-05-10 15:53:44 ФП даёт достаточное количество гарантий, чтобы не писать юнит тесты вообще. Лучше интеграционные, они очень полезны Открыть/Комментировать