Я не умею в Б, и я никогда не видел кого либо кто умеет в Б. Всем известный фейсбук создал это все именно потому что и они также не сумели в Б, как они сказали в презентации.
Ну и хотелось бы писать в мутабельном стиле, поэтому
а мне хочется в иммутабельном писать. Пописав какое то время чистый код, приходишь в проект где «обычный порошок» и рвешь волосы на голове, когда натыкаешься на всякое такое, например почему 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 буквально стало на порядок реже. Без преувеличений.
Про номинальное сравнение типов — я сейчас использую вот такие типы для id:
export interface CompanyId {
companyId: string;
}
соответственно если случайно передать CompanyId в метод принимающий UserId будет ошибка компиляции. И даже если ее как то обойти через any, или еще что то, то рантайм исключение возникнет «ближе» к строке содержащей ошибку.
Интересно, есть ли способ лучше, без выставления флага компиляции.
К хорошему быстро привыкаешь, и именно переход обратно к плохому сильно заметен.
Также решена и проблема 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 пока что должно быть сильно меньше, почему жгут именно их?
соответственно если случайно передать CompanyId в метод принимающий UserId будет ошибка компиляции. И даже если ее как то обойти через any, или еще что то, то рантайм исключение возникнет «ближе» к строке содержащей ошибку.
Интересно, есть ли способ лучше, без выставления флага компиляции.