Алексей Уколов

Оно всё колхоз.
Вы еще про пластину в зоне VRM забыли.
Если найдете штатный радиатор, который прижмет все чипы памяти, процессор и отдельный радиатор для зоны VRM, то меняйте, иначе оставьте как есть.

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

Стандартной практикой является коммит в репозиторий файла phpunit.xml.dist в который прописываются все настройки по умолчанию, кроме чувствительных к безопасности (api ключи, пароли и пр). Файл phpunit.xml добавляется в .gitignore. Таким образом, если пользователю нужно кастомизировать какие-то параметры, он просто копирует файл phpunit.xml.dist в phpunit.xml и добавляет свои секреты в последний. Это безопасно, так как phpunit.xml заигнорен.

То что вы описываете - это уже не unit, а интеграционное тестирование. Скрипты для интеграционного тестирования обычно делают в отдельном testsuite и скипаются по умолчанию. Для запуска юнит тестов не должна требоваться какая-либо подготовка - только "склонировал репозиторий, запустил". Для интеграционных подготовка уже нужна. Например, юзер должен будет модифицировать phpunit.xml (не .dist!), вписав туда свой тестовый api ключ.

Соответственно, для юнит тестов достаточно в тестируемый код передать мокнутого http клиента, который будет возвращать ответ, который вернуло бы реальное стороннее api (в guzzle это делается с помощью MockHandler). Поэтому если надо просто запустить юнит тест, то ничего делать не нужно - phpunit автоматически подхватит phpunit.xml.dist, если не найдет phpunit.xml. Если надо запустить интеграционные, то юзер должен будет скопировать phpunit.xml.dist в phpunit.xml и добавить туда api ключ.

dadata.ru

твой уровень программирования "школьник 9го класса, изучающий полгода java"

Чтобы не было, например, "обрезаний" при разных разрешениях экрана или "дополнения" пустых мест его дублированием

Геометрия говорит нам, что если пропорции блока и изображения не совпадают, то возможны три варианта:
- поля
- обрезка лишнего
- искажение пропорций

Поскольку, без искажений пропорций из одного изображения так сделать невозможно, то остается один вариант - подгружать разные файлы.

Но кроме пропорций, есть ещё поддержка форматов и плотность пикселей. Так что, сложность тут не одна.

Какие размеры файла желательны (в байтах)?

Минимальные. При этом нужно сохранять достаточное качество.

Этот вопрос не имеет смысла, даже если вы скажете размер вьюпорта/блока, но не покажете картинку. Потому что одна сожмется прекрасно, а другая заметно потеряет в качестве.

Для ретины и разных форматов файлов используйте image-set
Для разных размеров - @media
Для оптимизации размеров - форматы webp, avif

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

Во-вторых подойдет любая функция сравнения строк, например в пыхе что первое гуглится функция similar_text. Тупо смотришь процент схожести и если он высок - порог определи сам - тупо выдавай предупреждение о возможной опечатке. Можешь наколхозить свой вариант - не возбраняется.

Их две:
РКН
ТСПУ