Каждая CPU программа - это строго линейный список команд, - машина тьюринга.
Так как все алгоритмы пишутся под машину тьюринга и доказываются ими. Так же она нужна для конвеера команд в CPU. Чистый код - это всего лишь стандартный кибернетический подход к управлению сложными системами и так же это чистый системный анализ.
Держать в голове миллиарды строк команд, которые еще постоянно изменяются - невозможно.
С помощью декомпозиции можно легко получить стандартную пирамиду управления(аналогично пирамиде власти в армии). Теперь нужно держать в голове лишь несколько команд и список всех модулей. Способа идеальной декомпозиции пока не нашли.
С помощью инверсии зависимостей можно изменить направление зависимости модулей в нужных местах. Для уменьшения связности и большей модульности.
Функциональные принципы: отделение данный от логике, неизменяемость данных. Позволяет уменьшить энтропию кода.
Принципы ооп - применяют лишь в фасадах и плагинах, для структуры типов. Применяются ооп-функционал в качестве инструмента, сам принцип никто не использует.
Каждый if, каждое ветвление кода - это бифуркация, и является логикой. Каждый if увеличивает количество состояний по степенной функции. Десяток тысяч if увеличит количество состояния больше числа гугл.
if(true){}else{} даже в этом случае веротяность попадание в блок else равна 100% на продакшене. Значит каждого сочетания ветвления нужно продумывать и чтобы она всегда было корректное поведение. Каждый лишний if неминуемо приведет к багу.
По тому же принципу нужно учитывать и каждую связь, которых тоже больше гугла.
Поэтому программа в разработке - это всегда сложная система. Но с помощью кибернетики можно каждый баг превратить в уникальную фичу, и минимизировать негативные баги.
Вывод: чистый код по определению содержит меньшее инструкций, и меньше энтропии.
Работал на крупную американскую компанию – начал работать только через 6 месяцев – все это время ждал доступ и акки. Американцкие компании особо выделяются бюрократией.
Linq и foreach использует кучу и генерят мусор, это тоже нужно учитывать. Это делает их бесполезными и медленными. При этом оригинальный linq из F# сделан адекватно.
Еще есть баланс с точки зрения теории игр, равновесие Нэша.
Геймплей обязан быть синергетичным, чтобы количество вариантов состояний и стратегий было большое количество.
Но при это, имбы не должно появлятся, - примитивной стратегии которая дает большое приемущество. У тех же походовых игр приемущество получает либо первый игрок, либо второй. Именно имба больше всего раздражает, но если будет стратегия которая контрит эту имбу, то она по себе балансируется.
Добиться такого равновесие хз как. Можно лишь количество условий уменьшить, так как каждое условие добавляет количество непредвиденных состояний в степеной зависимости и критических точек, которые и дают имбу.
А в чем могут быть проблемы с преобразованием типов с помощью этого? Это не unsafe, и по другому сделать сложно, чтоб без лишнего выделения памяти, мусора и быстро.
В реальной разработке костыли необходимы. Иногда изменения запрещены, и нужно делать быстрый хотфикс с минимальными изменениями.
Это называется техничечкий долг, и в нормальных условиях на это выделяется время.
В любом случае, рано и поздно, костыль будет переписан. Но если поздно, то придется полностью переписывать большой кусок кода. Иногда это единственный вариант, из-за спаггети-кода в котором невозможно разобраться.
Кода проблем и багов с конкретным кодом накопится достаточно, то их скопом можно решить полной переделкой. Иначе не выделят время. По времени это будет в любом случае быстрее.
Как понял, классическая материалистическая физика вполне может объяснить все парадоксы. Единственное что не может - нарушение локальности при запутанности частиц. Но это лишь показывает что существует такое взаимодействие которое не зависит от пространных координат. Но этому противоречит теория скрытых параметров, эксперименты показали нарушение неравенства Бела. Но это неравенство как и эксперименты пока очень спорные.
А всякие наблюдатели, фэнтези параллельные миры, и прочая идеалистическая чушь - это просто подгонка под мат. модели и к физике не имеет отношения.
А есть что-нибудь про оптимизации и алгоритмы умножений матриц, которые используются в gpu и cpu?
Сталкивался что умножение в шейдере каждый раз дает разные результаты с погрешностью, если включить оптимизацию. Для этого есть специальные директивы precise и invariant.
Не помешало бы дать определение системному мышлению.
Программированием - это декомпозиция, а это основа системного анализа. Но это только начало, без этого никуда.
Для функционального программирование нужно еще одно мышление. В разработке и тестировании нужно уже синергетическое и хаотическое мышление. Для производство - совершенное другое. У инженеров вообще свое мышление.
По примерам все же, выходит что основное, это не мышление, а способность самообучиться и менять свое мышление, так как ит движется быстрее чем человек может адаптироваться.
Нельзя расширять просто так энумы, нужно править каждое использование. Энумы - .
Нельзя использовать строки в коде, это данные.
Не нужно костылить энумы, так это неочевидное усложнение.
Для расширение функционала энумов лучше всего использовать атрибуты. Тогда можно в них хранить дополнительные данные и функции преобразования. И это избавить от лишних условий.
Автор некомпетентен.
Каждая CPU программа - это строго линейный список команд, - машина тьюринга.
Так как все алгоритмы пишутся под машину тьюринга и доказываются ими. Так же она нужна для конвеера команд в CPU. Чистый код - это всего лишь стандартный кибернетический подход к управлению сложными системами и так же это чистый системный анализ.
Держать в голове миллиарды строк команд, которые еще постоянно изменяются - невозможно.
С помощью декомпозиции можно легко получить стандартную пирамиду управления(аналогично пирамиде власти в армии). Теперь нужно держать в голове лишь несколько команд и список всех модулей. Способа идеальной декомпозиции пока не нашли.
С помощью инверсии зависимостей можно изменить направление зависимости модулей в нужных местах. Для уменьшения связности и большей модульности.
Функциональные принципы: отделение данный от логике, неизменяемость данных. Позволяет уменьшить энтропию кода.
Принципы ооп - применяют лишь в фасадах и плагинах, для структуры типов. Применяются ооп-функционал в качестве инструмента, сам принцип никто не использует.
Каждый if, каждое ветвление кода - это бифуркация, и является логикой. Каждый if увеличивает количество состояний по степенной функции. Десяток тысяч if увеличит количество состояния больше числа гугл.
if(true){}else{} даже в этом случае веротяность попадание в блок else равна 100% на продакшене. Значит каждого сочетания ветвления нужно продумывать и чтобы она всегда было корректное поведение. Каждый лишний if неминуемо приведет к багу.
По тому же принципу нужно учитывать и каждую связь, которых тоже больше гугла.
Поэтому программа в разработке - это всегда сложная система. Но с помощью кибернетики можно каждый баг превратить в уникальную фичу, и минимизировать негативные баги.
Вывод: чистый код по определению содержит меньшее инструкций, и меньше энтропии.
Это PERT метод, один из самых эффективных https://ru.wikipedia.org/wiki/PERT
Существуют несколько специальных алгоритмов и техники для расчетов сроков производства, этому обучают в вузе.
Один из них - нужно разбивать все на задачи, каждую задачу декомпозировать на подзадачи, пока оценка станет не очевидной.
На каждую подзадачу дается 3 оценки: оптимистическая, песиместическая и медиана.
Все задачи группируется и распаралеливаются для командной работы. Вычисляется среднее время по самой длинной ветки.
А вот сроки для разработки всегда одни - до дедлайна. Разработка - не производство.
По статистике git удаляю код в 2 раза больше чем добавляю новый, включая новые фичи.
Фиксы багов - это в основном удаление лишнего кода. Каждый лишний код, лишнее условие, лишняя сложность - это код бага.
Работал на крупную американскую компанию – начал работать только через 6 месяцев – все это время ждал доступ и акки. Американцкие компании особо выделяются бюрократией.
Непонятно почему не перенесут нормальный linq из F#. Он мощнее, быстрее и не генерит мусор.
Linq и foreach использует кучу и генерят мусор, это тоже нужно учитывать. Это делает их бесполезными и медленными. При этом оригинальный linq из F# сделан адекватно.
В смысле один день команда собирается и бухает вместо работы? Или где?
Рабочее место в офисе не поучится закрепить для всех ради одного дня. А делить комп не безопасно.
Нет доказательств, все исследования по ссылке показывают обратное - на письмо тратится больше умственных усилий.
И если записать то что нужно запомнить, то оно моментально забывается после записи.
Самая большая глубость - запись под диктовку лекций.
А вот делать майдмапы, рисовать ассотивные рисунки от руки действительно помогают лучше запомнить на всю жизнь, достаточно лишь взглянуть на рисунок.
Еще есть баланс с точки зрения теории игр, равновесие Нэша.
Геймплей обязан быть синергетичным, чтобы количество вариантов состояний и стратегий было большое количество.
Но при это, имбы не должно появлятся, - примитивной стратегии которая дает большое приемущество. У тех же походовых игр приемущество получает либо первый игрок, либо второй. Именно имба больше всего раздражает, но если будет стратегия которая контрит эту имбу, то она по себе балансируется.
Добиться такого равновесие хз как. Можно лишь количество условий уменьшить, так как каждое условие добавляет количество непредвиденных состояний в степеной зависимости и критических точек, которые и дают имбу.
А в чем могут быть проблемы с преобразованием типов с помощью этого? Это не unsafe, и по другому сделать сложно, чтоб без лишнего выделения памяти, мусора и быстро.
Детерменированого мира не существует. А динамический хаос не обратим, вернутся нельзя даже математически.
Так же полная туфта про создание парралейной вселенной. Количество их будет контитуально бесконечным.
Энтропия всегда возрастает только в закрытых системах, которых не существует в природе.
Для направления лучше брать необратимые процессы и рекурсивные процессы.
В реальной разработке костыли необходимы. Иногда изменения запрещены, и нужно делать быстрый хотфикс с минимальными изменениями.
Это называется техничечкий долг, и в нормальных условиях на это выделяется время.
В любом случае, рано и поздно, костыль будет переписан. Но если поздно, то придется полностью переписывать большой кусок кода. Иногда это единственный вариант, из-за спаггети-кода в котором невозможно разобраться.
Кода проблем и багов с конкретным кодом накопится достаточно, то их скопом можно решить полной переделкой. Иначе не выделят время. По времени это будет в любом случае быстрее.
Как понял, классическая материалистическая физика вполне может объяснить все парадоксы. Единственное что не может - нарушение локальности при запутанности частиц. Но это лишь показывает что существует такое взаимодействие которое не зависит от пространных координат. Но этому противоречит теория скрытых параметров, эксперименты показали нарушение неравенства Бела. Но это неравенство как и эксперименты пока очень спорные.
А всякие наблюдатели, фэнтези параллельные миры, и прочая идеалистическая чушь - это просто подгонка под мат. модели и к физике не имеет отношения.
А почему тогда работает экран на лучевой трубке? Там тоже два магнита и элнктроны, но луч не раздваивается.
Интересная концепция. И избавляет от дисбаланса походового варианта.
Можно еще что-нибудь на поле добавить. Препятствия или доп. заряд, для разнообразия.
А есть что-нибудь про оптимизации и алгоритмы умножений матриц, которые используются в gpu и cpu?
Сталкивался что умножение в шейдере каждый раз дает разные результаты с погрешностью, если включить оптимизацию. Для этого есть специальные директивы precise и invariant.
Не помешало бы дать определение системному мышлению.
Программированием - это декомпозиция, а это основа системного анализа. Но это только начало, без этого никуда.
Для функционального программирование нужно еще одно мышление. В разработке и тестировании нужно уже синергетическое и хаотическое мышление. Для производство - совершенное другое. У инженеров вообще свое мышление.
По примерам все же, выходит что основное, это не мышление, а способность самообучиться и менять свое мышление, так как ит движется быстрее чем человек может адаптироваться.
Все это очень плохая практика, так делать нельзя.
Нельзя расширять просто так энумы, нужно править каждое использование. Энумы - .
Нельзя использовать строки в коде, это данные.
Не нужно костылить энумы, так это неочевидное усложнение.
Для расширение функционала энумов лучше всего использовать атрибуты. Тогда можно в них хранить дополнительные данные и функции преобразования. И это избавить от лишних условий.