Олег Гамега

Все сугубое imho:

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

Смена команды разработки - всегда боль.
Если это резкая смена команды - то либо это заканчивается переписыванием 70-80% кода, либо закладывайте ~30% потраченных на разработку ресурсов на вхождение новой команды в курс дела.

На мой взгляд есть 2 способа этого избежать:
a) покупка изначальной команды в штат
b) участие ваших штатных разработчиков в проекте изначально (но мало кто из аутсорсеров на это пойдет)

ну а предоставить собственно должны исходники без обфускации, с читаемыми названиями переменных, форматированием согласно принятым стандартам языка (для php например это PSR), документацию.

2. Какое качество кода должно быть, есть ли какие-то стандарты качества, которые нужно отразить в договоре?

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

3. Как относятся компании к договору NDA?

Относится отлично, но NDA в РФ не работает по факту. Хотя все их очень любят подписывать по поводу и без.

4. Какую документацию по проекту мы должны получить от разработчика?

Ту которую хотят ваши разработчики. Для веб-приложения на мой взгляд программа минимум это
а) ТЗ по которому все пишется
b) описание внешних и внутренних компонент приложения, что они делают и как взаимодействуют
c) описание структуры БД, как объектов со связями, так и полей. Если где-то денормализация - обоснование её наличия и описание логики.
d) описание endpoint проекта если есть (апи, итд)

5. Нужно ли прописать в договоре пункт про бэкдоры, работает ли это на судебном уровне

В РФ imho нет.

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

вот оптовая торговля по интернету через веб-сайт - это зло. забывать стал как люди выглядят.

Я с Python (все еще использую для своих проектов), перешел на Java

- Открыл список вакансий города, глянул вакансии по .net / java - Java оказалось почти в 3 раза больше, да и зп на 20-30% повыше. Плюс я люблю продуктовые компании, а их под .net очень мало, там чаще всего разработка под заказ
- Посмотрел, какой стек используется в вакансиях
- Прошустрил стек, что мне нужен по книгам, потыкался с пет-проектом
- Пошел работать, без особых проблем

P.s. Только учитывай, что при работе с Java ты учишь не сколько язык, сколько его экосистемы и паттерны - а это лет на 10

i+=10

Electron

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

Ответ концептуальный. Ромбическое наследование. От А наследуются B и C, от них обоих наследуется D.
1) Если в A есть поле, в D что, это поле будет в двух экземплярах? А если оно protected и в B мы добавили метод, который его меняет?
2) Если B и C переопределяют какой-то метод foo(), как быть D? А если нужна и версия B.foo(), и C.foo(), и они обе вызывают A.foo — получатеся D.foo вызовет A.foo дважды? А если в C есть второй метод bar(), который вызывает foo() и начинает вести себя не так, как надо, если мы берём реализацию B.foo()?
В общем, множественное наследование — хорошая штука, но ромбическое — штука опасная. В языке, где любое множественное наследование неизменно ромбическое, всё, что остаётся — делать такие условия, при которых ни 1, ни 2 не сработает.
Одно из таких условий — унаследоваться от одного класса и нескольких интерфейсов. 1) У интерфейса нет полей, и 2) эталонная реализация, существующая в некоторых языках программирования, в любом случае менее приоритетна, чем конкретная реализация из класса. Вызывать ту и другую нет смысла: если программист написал свою сверх эталонной — значит, он хочет сделать то же другим путём.

Вам нужно использовать redux

По-хорошему redux.
Но вы так же можете передавать список из App в Items с колбек функцией, которая запишет в state компонента App id выбранного продукта, ее надо прокинуть через Items в каждый Item и там по клику вызывать:

class App extends Component {
  state = {
    activeItemId: -1,
  };
  
  selectItem = id => {
    this.setState({
       activeItemId: id,
    });
  };

  render() {
    const { items } = this.props;
    const { activeItemId } = this.state;
   
    const activeItem = items.find(item => item.id === selectedItemId);

    return (
      <Wrapper>
        <More item={activeItem} />
        <Items 
          items={items}
          onSelectItemCalback={this.selectItem}
        />
      </Wrapper>
    );
  }
}

Ютуб платит около 0,8$ за 1000 показов. Там есть уникумы с 50+ миллионов подписчиков с доходом в 150k$ в месяц. Это Вас не смущает?
Вот пример:
https://www.youtube.com/user/PewDiePie/about?disab...
за время жизни канала (с 2010 года) было 16 665 142 435 просмотров умножаем на 0,8 делим на 1000 и получаем 13M$ c хвостиком, минус шведские (могу ошибаться) налоги 40% итого чел в плюсе на 8 миллионов долларов за 7 лет.
И проблема совсем не в выплатах, проблема в 16 миллиардах просмотров. Сделайте мне такие просмотры и я сам Вам с радостью отдам 0,34 за каждую тысячу. Потому что заработаю в разы больше.