Это статья-заметка для личных целей. Публикую в чулан, потому что материал крайне поверхностный
1: Необходимо постоянно учиться и переучиваться.
Допустим, мы создаём программу, которая, которая на основании данных из Excel‑таблицы создает отчет в формате PDF, на языке Python.
Для решения этой задачи обычно используются различные библиотеки: одна для работы с Excel, другая — с PDF. Каждая из них обладает своими уникальными командами и особенностями, и их нужно изучать с нуля.
Кроме того, существует множество библиотек для работы с PDF-документами на Python, и они могут значительно отличаться друг от друга. Если вы переходите с одной библиотеки на другую, вам придётся их заново осваивать.
Если же вы переходите с Python на C#, то вам придётся изучить новые библиотеки под другой язык программирования с нуля. В некоторых случаях даже приходится создавать собственные библиотеки, глубоко погружаясь в специфику формата PDF для решения узкоспециализированных задач. И именно за такие задачи платят большие деньги.
А теперь представьте себе ситуацию: вы устраиваетесь на работу и были готовы создавать сайты на React или Django, но вам дают задание работать со странными и малоизвестными или самописными фреймворками. Да. Вам придется изучать их с нуля...
НО НЕ ВСЕ ТАК ПЛОХО! На самом деле, многие сидят на привычных старых библиотеках и работают с ними годами. Просто зарплата будет ниже. Не 180 тыс, а просто 80 тыс. Другими словами, у вас есть выбор сложности. И чем больше опыта, тем сложнее и дороже вы будете брать задачи.
2. Большое количество свободы
Вот есть у вас задача. Её можно решить большим количеством способов и каждый из них будет работать. И это проблема.
Когда вы пишите код, вы наращиваете логическую систему. Со временем эта система при неправильном подходе становится слишком сложной.
Представим, что логический процесс в вашей программе - это провод. То вот как выглядит хорошая система
А вот как выглядит плохая.
Проблема в том, что без опыта трудно понять как выстраивать "фундамент" программы так, чтобы все было удобным, простым и стройным.
Чтобы избежать усложнения системы, придумали правила SOLID. Рекомендую посмотреть видео или статьи на тематику "SOLID на примере Factorio".
3. Описание мира через объекты
Вот какие тут есть объекты?
— Дома, машины, пешеходы, рекламный щиты, шоссе.
— А вот машины. Какие они?
— Ну... Есть автобусы, грузовики, легковые машины. Есть еще припаркованные автомобили, а есть движущиеся.
— Допустим, возьмем автобус. Это объект, так? Но сам автобус состоит из объектов. Какие это объекты?
— Колеса, кузов, двигатель, стекло, пассажиры, водитель, трансмиссия, электроника и тому подобное
Мир можно описать в виде объектов. Каждый объект содержит в себе какую‑то информацию в виде переменных (имя и возраст пешехода). Каждый объект может включать в себя несколько объектов (объект «Автобус» включает в себя объекты «Пассажир», «Водитель»).
Уровень детализации и состав объектов сильно зависит от контекста работы программы. Например, если нам нужно сделать программу, которая считает количество машин, едущих в центр и из центра, то нам не нужно будет расписывать составные части машины. А если нам нужна программа, которая будет анализировать работу фар машины, ее номера и тонирование стекла — то да, придется.
Сложность в том, чтобы понять как создать код, который можно быстро адаптировать к новой задаче: сначала считал количество автомобилей, едущих в центр, а потом научился дополнительно анализировать их состояние. Плохой код нужно постоянно переделывать.
4. Легаси код
Если программист некомпетентный или ему дали мало времени на решения задачи, может появится код ужасного качества (говнокод).
Он будет очень сложен в понимании, его будет трудно расширять. И со временем он стал неотъемлемой частью программы. Если вы захотите переделать этот код, вы столкнетесь с огромным количеством ошибок и, простите, геморроя.
Именно об этом и говорит популярный анекдот:
Анекдот. Сын спрашивает у отца-программиста:
- "А почему солнце встает на востоке, а заходит на западе"?
- Ты проверял?
- Проверял
- Работает?
- Работает
- Ну и пусть работает! Только умоляю, ничего не трогай!
Другими словами, очень сложно на старте понимать , какие решения будут сильно усложнять проект, а какие нет.