Это разница между чистой функцией и чистоплюйской функцией.
Формально таки лог, не только консольный, нарушает чистоту функции, практически же этим можно пренебречь.
Если, конечно, stdout не является результатом работы программы, тогда нельзя пренебрегать.
Я не умею в Б, и я никогда не видел кого либо кто умеет в Б. Всем известный фейсбук создал это все именно потому что и они также не сумели в Б, как они сказали в презентации.
Ну и хотелось бы писать в мутабельном стиле, поэтому
а мне хочется в иммутабельном писать. Пописав какое то время чистый код, приходишь в проект где «обычный порошок» и рвешь волосы на голове, когда натыкаешься на всякое такое, например почему if не сработал, хотя объекте нужное поле есть, очевидно поля не было в момент прохождения кода, кто то его мутировал позже, а консоль делает evaluation, когда мышкой тыкаешь, а не когда log вызвался.
К хорошему быстро привыкаешь, и именно переход обратно к плохому сильно заметен.
Я думаю, что каждый уважающий себя фронтендер должен написать обертку над Redux для борьбы с бойлерплейтом.
И я тоже написал решение для борьбы с бойлерплейтом. С помощью кодогенерации с функции вида smth(prev: MyChildState, { params }): MyChildState {} генерируется класс smthAction, у которого поля совпадают с params, редюсер (добавляется case в switch), и диспетчер, чтобы не создавать action, а вызвать метод с теми же параметрами.
Также решена и проблема O(n), теперь это O(1).
имена функций, как правило держатся более актуальными чем комменты, но бывает и такое вот.
А еще я встречал метод Read который внутри вызывал метод Write на себе с константами вместо недостающих параметров. По сигнатурам понятно что оно делает и почему так написано, но именование неадекватное, так что волосы дыбом.
Иногда для производительности приходится схлопывать код в одну функцию, чтобы избежать создания лишних объектов, или еще каких то «жирных» операций. Других причин писать большие функции нет.
Я могу сказать про себя, что начинал с больших функций, как и все. Но чем больше практикуешься в декомпозиции, тем лучше она получается. И код сейчас делится на мелкие функции легко и естественно. Это не бинарный показатель, код не делится на плохой и хороший, это длинная шкала, на которой укладывается многолетний опыт. Хотя иногда конечно получается, что какое то конкретное место пишется хуже, чем в среднем и этот код сам для себя считаешь плохим и думаешь «потом перепишу».
Так же и принцип единственной ответственности, он звучит как бинарное правило, либо ответственность одна, либо две и больше. Но это тоже так не работает, и в этом ошибка первоисточников. А вот если взглянуть на это как на непрерывную шкалу, то оно превращается в «слишком много отвественности» и «достаточно мало». И опять, опыт и практика позволяют со временем смещаться по этой шкале в нужную сторону.
Если же воспринимать эти книги вот так вот, отрицая их, потому что с первого раза не получилось, то с мертвой точки оно не сдвинется естественно.
Функции должны иметь как можно меньше аргументов, желательно ни одного.
Clean code, очевидно не подразумевает написание pure code.
В чистом коде функция не может не иметь ни одного аргумента, ведь ее можно(и нужно) заменить константой.
В остальном — я давно уже пришел к маленьким функциям и маленьким файлам еще.
Ах да, попытка «в лоб» уменьшить количество аргументов обычно приводит к тому, что аргументы схлопывают либо в кортежи либо в plain объекты, что меняет функцию только визуально, проблема не решается. Размер функции и количество аргументов это симптомы болезни, root cause же этой болезни — избыточное количество отвественности в функции. Надо уменьшать ответственность, растаскивая ее на части, декомпозируя то бишь. Количество аргументов и размер функции подтянутся сами.
Ну то что оверхед есть это понятно, мне интересно часто ли случается такое, что при какой то относительно простой операции результатом будет число с огромными нумератором и деноминатором, что одно число сожрет пару гигов памяти и соответствующую же производительность.
Да, в шарпе нашел в том числе реализацию с BigInteger, бесконечным целым. (первое что нашел было с uint). Стало интересно, не случается ли риск при каких нибудь безобидных действиях получить удар по производительности/памяти?
Так и я решах существующую задачу, а не сферическую задачу в вакууме, и эта задача прекрасно решается через Decimal.
И Rational тоже допускает потери, по определению, т.к. не имеет бесконечной точности, и к нему также применимо выражение «гарантирует отсустствие потерь, пока не превысится точность», как и к Decimal. В отличие от Double, который дает погрешность уже на примере операции 0.1 + 0.2
Кругом столько минусов, что хочется, чтобы кто то написал статью(или дал ссылку) как правильно работать с деньгами.
Как сохранять в БД бесконечные дроби, да хоть бы и конечные, но с большей точностью, чем стандартные типы. Даже не арифметические операции с такими числами, а просто сохранить в базе и считать без потери.
ЗЫ У нас не было операций деления. Сложение, вычитание и умножение на целое количество процентов(не дает бесконечных дробей, очевидно). А порой просто ввод, хранение и вывод. Double валится уже тут. Decimal на этом всём работает. Это кстати были не банковские деньги, а рассчеты, что то типа выставления сметы.
Гарантирует, пока не превысится точность. Точность не бесконечна естественно, хоть и больше, чем у double.
В JS (как и в шарповом double я думаю) даже без каких либо алгебраических действий можно получить такую кривизну. Просто читаешь ораклом из базы дробное число, получаешь не то что в базе записано. Решали тем, что в селекте значение кастили к строке, а в коде делали new Decimal(val). Библиотечку Decimal использовали, ибо работали с «деньгами» и такие double-фокусы были недопустимы.
E2e-тесты плохие, потому что петля обратной связи очень длинная (долгая).
Unit-тесты околобесполезны, потому что не гарантируют работоспособности продукта.
Решение — Behavior-тесты. Медленно работающие «концы», те самые «end» из Е2Е можно (и нужно) отрезать, и тесты начинают работать также быстро детерминировано как unit-тесты и продолжают гарантировать корректность логики приложения.
Загвоздка здесь в том, чтобы начать писать код так, чтобы концы можно было отрезАть. Например, при разработке на ангуляре, логику зачастую пишут пишут прямо в разметку. Естественно эту логику не протестировать кроме как посредством Е2Е.
И еще непонятен один вопрос, если проблема в шуме, то почему жгут именно 5G?
Я так понимаю шумом они не должны отличаться от оборудования прошлых поколений, да и вышек 5G пока что должно быть сильно меньше, почему жгут именно их?
Да, мне тоже интересно, а как поджигали то. Вышки, которые я видел, это бетонный столб и на высоте ~15 метров оборудование. Звука никакого не слышал, первый раз вот узнал, что они звук могут издавать.
если вы в экипировке на мотоцикле, то не бессмертны
нравится эта аналогия. Я, когда приходится рефакторить ts код, хоть бы и не нахожусь в абсолютной безопасности, все же имею подсказки где что может сломаться. моя оценка — система типизации отлавливает 90% моих ошибок. не бессмертие, но спасает от подавляющего большинства «тупизны». Бывает такое, что ошибка такая тупая, что когда найдешь — обтекаешь, сил нет, как такое могло произойти. С чистым js регулярно случалось, с ts буквально стало на порядок реже. Без преувеличений.
Формально таки лог, не только консольный, нарушает чистоту функции, практически же этим можно пренебречь.
Если, конечно, stdout не является результатом работы программы, тогда нельзя пренебрегать.
К хорошему быстро привыкаешь, и именно переход обратно к плохому сильно заметен.
Также решена и проблема O(n), теперь это O(1).
Но работает только с typescript.
А еще я встречал метод Read который внутри вызывал метод Write на себе с константами вместо недостающих параметров. По сигнатурам понятно что оно делает и почему так написано, но именование неадекватное, так что волосы дыбом.
Я могу сказать про себя, что начинал с больших функций, как и все. Но чем больше практикуешься в декомпозиции, тем лучше она получается. И код сейчас делится на мелкие функции легко и естественно. Это не бинарный показатель, код не делится на плохой и хороший, это длинная шкала, на которой укладывается многолетний опыт. Хотя иногда конечно получается, что какое то конкретное место пишется хуже, чем в среднем и этот код сам для себя считаешь плохим и думаешь «потом перепишу».
Так же и принцип единственной ответственности, он звучит как бинарное правило, либо ответственность одна, либо две и больше. Но это тоже так не работает, и в этом ошибка первоисточников. А вот если взглянуть на это как на непрерывную шкалу, то оно превращается в «слишком много отвественности» и «достаточно мало». И опять, опыт и практика позволяют со временем смещаться по этой шкале в нужную сторону.
Если же воспринимать эти книги вот так вот, отрицая их, потому что с первого раза не получилось, то с мертвой точки оно не сдвинется естественно.
Clean code, очевидно не подразумевает написание pure code.
В чистом коде функция не может не иметь ни одного аргумента, ведь ее можно(и нужно) заменить константой.
В остальном — я давно уже пришел к маленьким функциям и маленьким файлам еще.
Ах да, попытка «в лоб» уменьшить количество аргументов обычно приводит к тому, что аргументы схлопывают либо в кортежи либо в plain объекты, что меняет функцию только визуально, проблема не решается. Размер функции и количество аргументов это симптомы болезни, root cause же этой болезни — избыточное количество отвественности в функции. Надо уменьшать ответственность, растаскивая ее на части, декомпозируя то бишь. Количество аргументов и размер функции подтянутся сами.
И Rational тоже допускает потери, по определению, т.к. не имеет бесконечной точности, и к нему также применимо выражение «гарантирует отсустствие потерь, пока не превысится точность», как и к Decimal. В отличие от Double, который дает погрешность уже на примере операции 0.1 + 0.2
Как сохранять в БД бесконечные дроби, да хоть бы и конечные, но с большей точностью, чем стандартные типы. Даже не арифметические операции с такими числами, а просто сохранить в базе и считать без потери.
ЗЫ У нас не было операций деления. Сложение, вычитание и умножение на целое количество процентов(не дает бесконечных дробей, очевидно). А порой просто ввод, хранение и вывод. Double валится уже тут. Decimal на этом всём работает. Это кстати были не банковские деньги, а рассчеты, что то типа выставления сметы.
Гарантирует, пока не превысится точность. Точность не бесконечна естественно, хоть и больше, чем у double.
В JS (как и в шарповом double я думаю) даже без каких либо алгебраических действий можно получить такую кривизну. Просто читаешь ораклом из базы дробное число, получаешь не то что в базе записано. Решали тем, что в селекте значение кастили к строке, а в коде делали new Decimal(val). Библиотечку Decimal использовали, ибо работали с «деньгами» и такие double-фокусы были недопустимы.
Unit-тесты околобесполезны, потому что не гарантируют работоспособности продукта.
Решение — Behavior-тесты. Медленно работающие «концы», те самые «end» из Е2Е можно (и нужно) отрезать, и тесты начинают работать также быстро детерминировано как unit-тесты и продолжают гарантировать корректность логики приложения.
Загвоздка здесь в том, чтобы начать писать код так, чтобы концы можно было отрезАть. Например, при разработке на ангуляре, логику зачастую пишут пишут прямо в разметку. Естественно эту логику не протестировать кроме как посредством Е2Е.
Я так понимаю шумом они не должны отличаться от оборудования прошлых поколений, да и вышек 5G пока что должно быть сильно меньше, почему жгут именно их?