Нам не нужны кодеры, нам нужны инженеры-разработчики

про t shaped шла же речь в посте, т.е. автор, как и я сам признается, что экспертом во всех сферах физически не стать, т.к. эксперты мы именно в разработке, но ввиду междисциплинарности профессии - надо не хуже джуна/мидла сферы, для которой пишешь ПО разбиратсья в предметке, иначе велика вероятность, что продукт будет сделан либо работает, но оч.кривой, либо сразу провальный, ибо делал тот, кто понятия не имеет что значит бизнес клининга

Ну т.е. заказчик, который является экспертом в какой-то области, пишет ТЗ, отдает его в работу Вам. Вы читаете его а потом читаете интернет где написано что что-то работает не так и делаете как Вы считаете нужным потому что ну Вы же стали лучше чем джун разбираться в какой-то области? Если нет то знание предметки за пределами получаемой из ТЗ и общения с заказчиком Вам вряд ли нужно и его наличие вряд ли как-то сильно повлияет на то что проект станет успешным.

Нам не нужны кодеры, нам нужны инженеры-разработчики

В заказной разработке и в финтехе та же проблема, что вы описали, но даже там можно +- применить большую часть идей из статьи

Не конечно делать все разработчику самому можно применить. Я Вам даже больше скажу я застал времена когда такое уже было и считалось нормой. Я например помимо разработки катался (и не на служебном транспорте) к заказчикам и ставил/обновлял им разрабатываемое ПО иногда в редких случаях еще катался и исправлял его работу. Общался на объектах с работниками о том что им неудобно и не нравиться в ПО которое я делал, обновлял документацию на ПО, тестировал тоже сам и да нес полную ответственность за все это. И это работало по одной простой причине, само по себе ПО было не сложным по современным меркам, у меня было достаточно времени чтобы и заниматься разработкой и всем остальным, сейчас например на моей текущей работе с моей текущей нагрузкой я не представляю как можно делать что-то еще за пределами разработки.

А что касается «сегодня мед.апп, чз 4 месяца соц.сеть» - наверно к счастью, но я и есть экземпляр этого человека, и да, я с каждой из областей разбираюсь попутно/заранее и если не к середине, то к концу разработки я уж точно необходимый минимум предметки освою (иначе уверен, что сделаю херню полную, а не проект)

Хорошо, Ваш клиент это китайская компания заказавшая приложение для торговли лапшой в Куньмине. Потом идет социальная сеть для уборщиков в США. Далее криптобиржа для австралийского клиента ну еще один маркетплейс для продажи кошерной пищи. Все проекты идут по 3-4 месяца т.е. условно через полторагода Вы бы разбирались в куньминской лапше, как работает рынок клининга в США, стали криптаном и естественно знатоком кошерной пище? Я думаю нет, Вы максимум что приобрели бы знания принесенные Вам через тз и/или общение с заказчиком и дополненные гуглингом.

Нам не нужны кодеры, нам нужны инженеры-разработчики

собираются на недельку и вместе разбирают работу продукта на реальных задачах

Это похоже на обычное совещание с заказчиком, просто выездное.

Нам не нужны кодеры, нам нужны инженеры-разработчики

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

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

Крупные компании могут позволить создавать команды-конвейеры, в которых у работников узкие роли. Так и появились кодеры, математики-алгоритмисты, тестеры...

Они разделились не поэтому а потому что само по себе ПО стало намного сложнее и больше и один человек уже не может все это выполнять потому что сроки явно будут совсем другими. Когда-то средним проектом считался клиент банка и то из-за реализации модулей безопасности, сейчас клиент банка это мультиплатформенный клиент в котором можно и билеты на театр заказать и на самолет с синхронизацией между разными устройствами, а в последнее время еще и AI ассистентом. Если раньше клиентом банка мог действительно заниматься один программист то теперь как считаете все еще может?

В мелкой компании человек может исполнять все роли. Т.е. составить ТЗ, реализовать, а потом развернуть. И это не значит что у человека будет больше нагрузка. Наоборот может быть из-за небольшой нагрузки он может тянуть все и больше людей брать не нужно.

Нагрузка тут не причем, размер и сложность проекта на это влияют.

Очень плохо если программист не выходит в поле. Хотя бы в начале проект нужно побывать у заказчика и своими глазами увидеть контекст.

В большом количестве случаев это невозможно или даже бесполезно. Например Вы делаете систему для автоматизации больницы, Вы приехали в больницу и что Вы там узнали? Чтобы получить полный контекст чего-то Вам надо задержаться там надолго и "поработать" вместе с заказчиками. Но опять же даже если Вы побываете там в начале проекта это не гарантирует того что на объекте что-то поменяется через полгода или год когда проект уже будет на финальных стадия разработки. Именно поэтому есть аналитик который должен "кататься" часто к клиенту чтобы следить что там у него происходит.

Нам не нужны кодеры, нам нужны инженеры-разработчики

Я думаю проблема людей в финтехе в том что у них заказчик это они сами, заказчик банка это сам банк. Да у банка есть клиенты, но они жалуются работникам банка которые в свою очередь и являются заказчиками каких-то фич. Т.е. здесь заказчик и исполнитель это по сути коллеги работающие в одной организации. И да тут можно коммуницировать, обсуждать, "быть в теме всего" и т.п. Большинство работников "сидят" на работе по 5-10 лет и уже "свои в доску". В такой атмосфере Ваш стандарт может работать. А теперь посмотрим на другие области где заказчик это обычно внешнее лицо с непонятными целями, непонятной мотивацией и лицо это может быть как физическое одно лицо, так и юридическое лицо или группа лиц с которым если и есть связь но для принятия решений требует согласований неизвестной группой лиц на их стороне с которой у Вас нет четкой и всеобъемлющей связи и всеобъемлющего понимания того что они делают и зачем. К тому же сегодня команда делает мобильное приложение в медицинской сфере а через 4 месяца социальную сеть для уборщиков, знать глубоко каждую предметную область в таком темпе даже не сложно а невозможно. Поэтому и сложилось разделение которое Вы критикуете и предлагаете упразднить вот только такое если и возможно то только в Вашей отрасли и то не факт что везде.

QML: отличие оператора ":" Qt.binding от Binding

Сравнивается Binding и JS

В моих тестах есть и такое сравнение и разница в скорости смешная.

а в ссылке про это всё есть

По ссылке рассматривается узкий пример инициализации значения и 'за' и 'против' применения onCompleted вместо определения поля с дефолтным значением. Про биндинги там вообще ни слова нет, и кто из нас съезжает с темы?

Например выравнивание ширины ListView по макс элементу.

А как стали делать `без JS`?

У нас был деятель, который делал это через JS - уволили.

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

NDA

Мы находимся на техническом ресурсе, и если Вы хотите кому-то что-то доказать то доказывать надо, не поверите, пруфами, т.е. кодом, тестами и бенчмарками. До тех пор пока Вы их не предоставили все Ваши слова не более чем трёп.

QML: отличие оператора ":" Qt.binding от Binding

Нет, мы этого делать не будем, а просто прочитаем документацию

В моем бенчмарке исследуется вопрос производительности биндинга против присвоения через JS и C++, и Ваша ссылка вообще не имеет никакого отношения к нему ровно как и остальные две написанные в сообщении ниже.

 А по опыту выкидывание JS сокращало код в 2-3 раза минимум.

А функционал тоже выкидывался вместе с кодом?

Если логику держать в JS сразу возникают сложности с наследованием, декомпозицией, оптимизацией кода

агрегацией, конкатенацией, маршрутизацией... добавьте еще любые другие слова. Без примера кода это просто набор слов.

Т.к. сразу в новые или декомпозированные элементы нужно сразу тащить весь JS код.

Тоже неясно без кода ничего.

HTML совершенно отличный от QML - там нет биндингов и машины конечных состояний.

Биндинг это просто функция вместо значения которая вызывается когда надо получить значение, машины конечных состояний это функция-генератор которая нативно уже давно в любом JS рантайме поддерживается да и без нее это можно "за вечерок" реализовать если надо. QML использует JS движок из Chrome и заимствует огромное количество концепций из HTML, даже подмножество тегов HTML поддерживается в некоторых QML элементах. Поэтому "совершенно отличный" это преувеличение.

QML: отличие оператора ":" Qt.binding от Binding

JS будет ещё хуже работать вне биндингов, будет гораздо менее производительным и значительно ухудшит архитектуру и расширяемость

Хорошо сделаем синтетический тест на сравнение чтобы убедиться что JS "будет гораздо менее производительным". Использую Qt 6.6 на Intel Core i9x2 2.80г, память 16Гб. Сделал вот такой вот простенький пример для биндинга :

import QtQuick

Window {
    width: 640
    height: bindingItem.bindingValue
    visible: true
    title: qsTr("Hello World")

    QtObject {
        id: bindingItem
        property int bindingValue: 200
    }

    MouseArea {
        anchors.fill: parent
        onPressed: {
            for (let i = 0; i < 1000; i++) {
                bindingItem.bindingValue = bindingItem.bindingValue + 1;
            }
        }
    }
}

Запустил профайлинг 5 раз, средний результат на скриншоте (разница между тестами в несколько миллисекунд).

Идем далее и проверим кейс с присвоением этого же поля из скрипта переписав код так:

import QtQuick

Window {
    id: root
    width: 640
    height: 200
    visible: true
    title: qsTr("Hello World")

    MouseArea {
        anchors.fill: parent
        onPressed: {
            for (let i = 0; i < 1000; i++) {
                root.height = root.height + 1;
            }
        }
    }
}

Запустил профайлинг 5 раз, средний результат на скриншоте (разница между тестами в 10 миллисекунд).

Ну и последним проверим кейс с биндингом из С++:

import QtQuick
import TestBinding

Window {
    width: 640
    height: testCppBinding.bindingValue
    visible: true
    title: qsTr("Hello World")

    TestCppBinding {
        id: testCppBinding
    }

    MouseArea {
        anchors.fill: parent
        onPressed: {
            testCppBinding.changeBinding();
        }
    }
}

#ifndef TESTCPPBINDING_H
#define TESTCPPBINDING_H

#include <QObject>
#include <QQmlEngine>

class TestCppBinding : public QObject
{
    Q_OBJECT
    Q_PROPERTY(int bindingValue READ bindingValue WRITE setBindingValue NOTIFY bindingValueChanged FINAL)
    QML_ELEMENT
private:
    int m_bindingValue { 200 };

public:
    explicit TestCppBinding(QObject *parent = nullptr);

    int bindingValue() const noexcept { return m_bindingValue; }
    void setBindingValue(int bindingValue) {
        if (m_bindingValue == bindingValue) return;

        m_bindingValue = bindingValue;
        emit bindingValueChanged();
    }

    Q_INVOKABLE void changeBinding() {
        for (int i = 0; i < 1000; i++) {
            setBindingValue(m_bindingValue + 1);
        }
    }

signals:
    void bindingValueChanged();
};

#endif // TESTCPPBINDING_H

Запустил профайлинг 10 раз потому что был больший разброс, средний результат на скриншоте (разница между тестами в 100 миллисекунд).

Лишние 100 миллисекунд полагаю тратятся на клей между C++ и QML.

Результаты разные конечно но "гораздо менее производительным" какой-то из этих вариантов не стал точно.

Еще бы хотелось узнать от Вас примеры "ухудшит архитектуру и расширяемость".

QML декларативный, JS - процедурный

В соседнем лагере где HTML декларативный, JS - процедурный никого особо не смущает ничего :)

 По моему опыту злоупотребление JS происходит от непонимания QML.

Стоит уточнить только злоупотребление или просто употребление?

QML: отличие оператора ":" Qt.binding от Binding

Это неправильно! Происходит от незнания и непонимания QML. Это очень сильно ухудшает производительность, увеличивает тех долг, сильно усложняет сопровождение и поддержку, ухудшает расширяемость кода и т.п. Плавали - знаем! Поэтому подобную практику пресекли на корню.

Это зависит от того для чего Вы делаете и что Вы делаете. Большое количество биндингов и глубина цепочки этих самых биндингов также легко может стать причиной плохой производительности особенно на слабом железе поэтому не все так однозначно.

QML: отличие оператора ":" Qt.binding от Binding

Мы писали CodingStyle.md где явно не рекомендовали использовать JavaScript код вместо биндингов в т.ч.и потому

На самом деле это зависит от того как именно пишется приложение, если вся логика находиться в C++ то можно впринципе не использовать JavaScript а QML использовать как макет интерфейса. Но вот если приложение QML only или если у Вас дизайнеры/верстальщики участвуют в верстке QML такое вряд ли возможно, присвоение свойств через оператор = в JS функциях обычная практика для сложного дизайна.

readonly свойство с binding (присваиванием) решает эту проблему и запрещает менять биндинг.

Добавление readonly возможно только в своих компонентах, поэтому фундаментально это проблему не решит. К тому же никто не мешает через js менять не значение а сам binding который по сути является функцией Qt.binding .

В России к 2030 году планируют запустить защищённую промышленную сеть передачи данных

К 2030 году в России должна начать работать доверенная промышленная сеть (ДПС)

Аббревиатура явно не случайна...

Microsoft анонсировала новый инструмент для обнаружения и исправления галлюциногенного контента в результатах ИИ

Т.е. вместо траты усилий на то чтобы галлюцинирующего контента в ответах не было лучше сделаем средство которое будет проверять и исправлять постфактум.

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

также меняются правила оплаты услуг мобильной связи за наличные деньги — такой расчёт может стать возможен только в уполномоченных правительством организациях, и исключительно при подтверждении личности плательщика.

И организаций таких конечно же будет одна на всю страну.

Делаем простой рисовальщик в PySide6

А почему для описания не использовать .ui файлы? или вообще QML? Портянки кода для создания виджетов выглядят жирными и не читаемыми.

Следователи поместили Дурова под стражу во Франции, суд через несколько часов — как гражданина этой страны

Основная претензия властей ЕС к Telegram - зашифрованные сообщения

Среди возможных обвинений: терроризм, наркотики, соучастие, мошенничество, отмывание денег, сокрытие данных, контент с педофилие

Как общение третьих лиц (зашифрованное или нет не суть) на платформе может превратиться в данные список обвинений? Типа я открыл клуб и если в нем торгуют наркотиками третьи лица то меня обвинят в торговле наркотиками?

Разработчик трилогии Grand Theft Auto объяснил, почему из San Andreas исчез мусор

В Готике тоже была настоящая ночь и без факела или заклинания свет не видно было буквально ничего.

QML: отличие оператора ":" Qt.binding от Binding

property var varOfRectangle: item.varOfItem

Тем не менее, логика статьи мне кажется всё равно актуальной. Зачем писать:

Итак давайте все же начнем сначала, когда мы пишем код выше то значит что мы априори подразумеваем что нам не надо управлять varOfRectangle самостоятельно а чтобы он присвоился автоматически из item.varOfItem. Т.е. биндинг по природе своей подразумевает что мы отдаем присвоение какой-то переменной некому автоматическому механизму. Если Вы сделали так то зачем начали присваивать его вручную? Если Вам необходимо делать вручную или Вас не устраивает как работает биндинг то никто не мешает написать например так:

Item {
  id: item
  property var varOfItem

  onVarOfItem: {
    rectangle.varOfRectangle = item.varOfItem
  }
}

Rectangle {
  id: rectangle
  property var varOfRectangle
  onVarOfRectangle: {
    item.varOfItem = rectangle.varOfRectangle
  }
}

Таким образом можно сделать биндинг просто кодом.

У меня есть ListView внутри Loader-а, который грузится какое то время, и есть currentIndex из файла конфигурации, который тоже грузится не сразу. И мне как то надо их свести вместе :)

Если интересно вот тут можете посмотреть как реализовано https://github.com/anilibria/anilibria-winmaclinux/blob/master/src/Views/OnlinePlayer.qml#L164 нечто похоже по описанию как Вам требуется.

QML: отличие оператора ":" Qt.binding от Binding

readonly используется для кейсов где свойство инициализируется каким-то значением и в дальнейшем не может быть изменено. Удобно им пользоваться для случаев когда создается свой компонент и надо вытащить наружу какие-то свойства но извне их менять запрещено. Например я частенько вытаскиваю размер шрифта который используется внутри моего компонента наружу но менять его извне бессмысленно.

QML: отличие оператора ":" Qt.binding от Binding

Item {
  id: item
  property var varOfItem
}

Rectangle {
  id: rectangle
  property alias varOfRectangle: item.varOfItem
}

QML: отличие оператора ":" Qt.binding от Binding

Если хочется забиндить свойства внутреннего компонента в другой компонент то проще всего сделать это через alias который создает bi-directional binding c и в целом решает полностью описанную Вами проблему.