Являются ли плохие методы программирования типичными для индустрии программного обеспечения? [закрыто]

140

Я только начал свою первую работу в качестве разработчика программного обеспечения более месяца назад. Все, что я узнал об ООП, ТВЕРДОМ , СУХОМ , ЯГНИ, шаблонах проектирования, SRP и т. Д., Можно выбросить из окна.

Они используют C # .NET Webforms и делают почти все внутри Code Behind с очень небольшим количеством внешних классов, определенно не вызываемых объектов. Они используют пользовательские элементы управления и используют их повторно. Об используемых объектах только Entity Framework . Они повторно используют код для каждого клиента. У них есть методы длиной в 400 строк, делающие все виды вещей. Для новых клиентов они берут aspx и aspx.cs, удаляют код клиента и начинают добавлять новый специфичный для клиента код.

Их первым оправданием будет добавление дополнительного обслуживания, и больше кода - больше обслуживания. Это небольшой магазин из трех разработчиков, включая меня. Один разработчик имеет опыт работы более 30 лет, а другой - более 20 лет. Один раньше был разработчиком игр, а другой всегда работал на C и C ++.

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

зловещий
источник
Я открыл обсуждение заголовка в чате: chat.stackexchange.com/transcript/message/40126879#40126879 Пожалуйста, присоединяйтесь ко мне.
17
1
Комментарии не для расширенного обсуждения; этот разговор был перенесен в чат .
Мировой инженер

Ответы:

263
  1. Принципы, которые вы привели в своем вопросе, - это просто ... принципы. Это не мандаты, законы или приказы.
  2. Хотя люди, которые придумали эти принципы, очень умны, они не являются абсолютными авторитетами. Они просто люди, предлагающие свое понимание и руководство.
  3. Не существует «правильного» способа программирования. Об этом свидетельствует тот факт, что «принятый» нами способ изменился и продолжает меняться радикально с течением времени.
  4. Доставка товара часто может иметь приоритет над «правильным» способом. Это настолько распространенная практика, что она имеет название: технический долг.
  5. Некоторые программные архитектуры общего пользования не идеальны. Лучшие практики развиваются от больших монолитных приложений к слабосвязанным коллекциям модулей.

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

Итак, как вы следуете «правильному», принципиальному пути, чтобы вы могли выйти из пустыни?

  1. Изучайте уместность, а не правильность. «Правильный» способ сделать что-либо в разработке программного обеспечения - это тот, который наиболее эффективно соответствует вашим конкретным требованиям.
  2. Изучите компромиссы. Все в разработке программного обеспечения является компромиссом. Вы хотите больше скорости или меньше использования памяти? Вы хотите очень выразительный язык программирования с небольшим количеством практиков или менее выразительный язык, который знают многие разработчики?
  3. Изучай вне времени. Некоторые принципы выдержали испытание временем и всегда будут актуальны. Системы типов универсальны. Первоклассные функции универсальны. Структуры данных универсальны.

  4. Учитесь прагматизму. Быть практичным важно. Математическая чистота, кристально-соборная архитектура и принципы башни из слоновой кости бесполезны, если вы не можете отправить.

  5. Будь ремесленником, а не фанатиком. Самые лучшие разработчики программного обеспечения - это те, кто знает правила, а затем знает, как их нарушать, когда это имеет смысл. Это те, кто до сих пор знает, как решать проблемы и думать самостоятельно. Они используют принципы, чтобы информировать и направлять свой выбор, а не диктовать их.
  6. Написать код. Многое из этого. Принципы проектирования программного обеспечения являются преждевременными оптимизациями, пока вы не написали много кода и не разработали инстинкт правильного их применения.
Роберт Харви
источник
1
Комментарии не для расширенного обсуждения; этот разговор был перенесен в чат .
Яннис
Где я могу получить эти идеи систематически, если у меня нет никаких указаний?
Ooker
4
Не просто понять, что такое лучшая практика, но каковы ощутимые преимущества лучшей практики. Это позволяет связать лучшую практику с уместностью, а также обеспечивает эффективность применения практики для достижения наилучшего эффекта. Если вы просто повторяете, что лучшая практика выполняет «разделение интересов», то вы, вероятно, не можете быть уверены, что выбираете правильный путь, чтобы воспользоваться преимуществами этой практики.
AaronLS
51

Это не редкость. Необходимо понять, что индустрия программного обеспечения невероятно разнообразна. Некоторые компании являются передовыми. Ведущие университеты и инновационные компании по разработке программного обеспечения (даже некоторые лаборатории в крупных!), А также благословенные люди или группы, такие как бригада из четырех человек, анализируют проблемы, возникающие в связи с распространенными способами работы, и изобретают новые языки, машины, инструменты и шаблоны. Новые компании, часто отделенные или отделенные, пытаются использовать их в коммерческих целях, а иногда имеют удивительный успех. Подумайте, Facebook или Google.

Но в наши дни программное обеспечение используется почти везде, возможно, в основном в компаниях, которые на самом деле не являются разработчиками программного обеспечения. Я работал в основном в транспортной отрасли (автомобильной и железнодорожной), и у меня есть разные впечатления. Но ни один из них не был близко к «режущей кромке». Иногда они не могут быть; программное обеспечение, связанное с безопасностью, зависит от хорошо проверенных инструментов (в настоящее время мы используем проверенный компилятор C ++ 1990-х годов). Иногда у них нет нужных людей. Зачастую программное обеспечение разрабатывается инженерами в других областях, которые просто оказались вовлечены в разработку программного обеспечения в своей компании, когда программное обеспечение становилось все более важным. Нельзя ожидать, что они знают или используют принципы разработки программного обеспечения.

Еще одна вещь, которую следует учитывать, это то, что важно для инженера в реальном мире. Часто стоящая перед нами задача, в буквальном смысле, не ракетостроение. Хлебные проблемы в компаниях, не занимающихся программным обеспечением, могут быть решены с помощью скромных программных средств. Что делает полезного, возможно, даже хорошего инженера-программиста, отчасти делает хорошего общего инженера: быть надежным; организовывать и документировать свою работу ответственно; быть кооперативным; сделать хорошие оценки стоимости и времени (достоверность оценки важнее, чем фактические затраты и время!); понять, что вы можете и не можете сделать. Здесь явно не хватает «знать и использовать самые современные инструменты и процедуры». То, что вы описываете, - это компания, которая создала набор инструментов и процесс, который работает для них. Они, вероятно, никогда не произведут ничего сексуального или необычного, но они удовлетворяют потребности клиентов достаточно хорошо, чтобы генерировать стабильный поток достаточных доходов. Это может быть определение техники ;-).

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


Я хочу добавить часть утешения или более оптимистичную записку. То, что вы узнали, не должно быть выброшено из окна. Вы можете применять лучшие принципы в своей повседневной работе, где это не сломает вещи. Возможно, появится окно возможности представить новый инструмент или шаблон проектирования. Шансы являются лучшими, когда старый способ работы неприятен для коллег, или если они сталкиваются с проблемами управления сложностью или обслуживанием (две наиболее опасные проблемы, решаемые с помощью инноваций). Будьте готовы предложить улучшения, когда есть возможность. Оказывать положительное влияние и постепенно улучшать методы и инструменты; распространять знания там, где это ценится.

Питер А. Шнайдер
источник
2
@nocomprende: нет entiendo ... Вы имеете в виду, что общее является более распространенным, а необычное, к сожалению, необычным? Или что общее не очень хорошо? Ну да.
Питер А. Шнайдер
3
«То, что вы изучаете в университете, на самом деле не распространено во многих областях» - это, кажется, ключ ...
Брайан
1
Я просто имел в виду, что в области программного обеспечения есть люди с полным спектром человеческих способностей, с полным спектром знаний, у компаний есть полный спектр подготовленности, полный спектр проблем и т. Д., Как и в остальном мире. Программное обеспечение ничем не отличается в этих отношениях от других областей. Проблема могла быть поставлена ​​на любом сайте SE.
1
«Программное обеспечение, относящееся к безопасности, зависит от хорошо проверенных инструментов (в настоящее время мы используем проверенный компилятор C ++ из 1990-х годов)», звучит для меня довольно актуально!
Hovercouch
1
@ PeterA.Schneider - это была глупая шутка о том, насколько передовыми являются проверки ваших инструментов. ;)
Hovercouch
16

Они используют веб-формы C # .Net и делают практически все в коде с очень небольшим количеством внешних классов.

Там ваше объяснение прямо там. Если вы не знаете, готовый код Web Forms является в значительной степени полярной противоположностью OOP, SOLID, DRY, YAGNI, Design Patterns, SRP и т. Д. Даже официальные примеры от Microsoft за несколько лет назад заставил бы тебя съежиться сегодня.

Веб-формы подталкивают себя к процессуальному потоку, с некоторыми фальшивыми «событиями», запускаемыми управляющими щелчками и тому подобным. Разработчики, которые проводили много времени за веб-формами, также, как правило, неохотно уходят от него, вероятно, потому, что они потратили так много времени на изучение жизненного цикла страницы и на то, как создавать динамически отображаемые элементы управления, которые им не нравятся, чтобы отбросить эти знания сейчас. перед лицом новых / лучших методов. Бессознательная версия заблуждения. Эти разработчики потратили годы на то, чтобы научиться разбираться в веб-формах, и теперь им будет нелегко отказаться от этой экспертизы, отсюда и их разговоры о времени «технического обслуживания».

И это довольно часто встречается в пространстве .NET Web Forms, кстати.

Грэхем
источник
6
Приятно обратиться к техническому стеку упомянутого вопроса
jasonoriordan
5
Кто хочет просмотреть 20 классов, вложенных и вызывающих друг друга, чтобы понять, что происходит, когда вы устанавливаете или снимаете флажок? Только сумасшедшие люди, или люди, которые думают, что профессора колледжа - боги.
developerwjk
1
На самом деле, когда WebForm была создана, отраслевые стандартные практики отличались (или не существовали), и уже существующие приложения никогда не получали рефакторинг, когда «новый крутой способ сделать что-то» начал приниматься. Вот почему вы видите много кода WebForm, загроможденного беспорядком. Принципы программирования абстрагируются от используемого вами стека технологий, поэтому их можно применять даже в WebForms, Cobol, Assembly и так далее.
BgrWorker
1
Да, это правда. Сколько МБ было вашего ViewState? Как ни странно, я думаю, что элементы управления на стороне сервера стимулировали бизнес-логику в пользовательском интерфейсе. Тем не менее, программист был сильно виноват в том, что охотно согласился с дерьмовым программированием asp.net. Таким образом: так много событий, что бизнес-объекты не могут прийти в правильное состояние. Bus. объекты не могут вызывать друг друга из-за связи пользовательского интерфейса. Тогда: о, смотри Мо! Мы можем работать "отключен!" ньюк, ньюк, ньюк. Реальный объем данных привел к полной остановке вашего приложения, поскольку классы asp.net выдавали себя за движок базы данных. Но мы спасали связи от износа!
Радар Боб
1
Вся эта напыщенная речь правдива ... сердечно правдива. Я видел так много из того, что описано в этом посте, касающегося приложений WebForms, и это заставляет меня чувствовать, что эти приложения немного лучше, чем некоторые PHP-скрипты, скомпилированные старшеклассником на энергетических напитках - и это считалось корпоративным программным обеспечением!
Грег Бургхардт
12

Насколько распространено это в индустрии программного обеспечения?

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

Есть веская причина, почему это происходит: люди, которые на самом деле не обучены (или не увлечены), вынуждены что-то реализовывать под давлением.

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

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

Или хорошо сделанное приложение заканчивается на этапе сопровождения, все хорошие разработчики идут дальше, и затем его продолжают разрабатывать немногие люди (наихудший случай: один), которые мало о нем знают, у которых нет документации и т. Д.

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

Есть два возможных ответа:

  • Либо: обсудите это со своим боссом и убедитесь, что вы принимаете участие в чистых проектах. Если это невозможно, найдите нового босса.
  • Или: возьмите на себя ответственность за это самостоятельно. Это означает, что вы делаете это самостоятельно - в свободное время или, если можете, в компании, но руководствуемся самим собой (маловероятно).

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

Например, для некоторых людей абсолютно возможно и очень весело, например, копаться в новом языке, таком как Ruby, изучать не только синтаксис, но и углубляться в специальные ОО-аспекты этого языка и действительно углубляться в него. Все в свободное время, без связи с вашей работой. Это будет просто хобби, но, будучи профессиональным профессионалом, вы можете быть столь же эффективными (или даже более), как сидеть рядом с каким-то ведущим разработчиком и пытаться следить за тем, что они делают. Тогда это будет строго для вашего личного развития и вашего собственного удовольствия. Если вам не нравится это делать, или вы обнаружите, что просто не можете достичь какого-либо понимания, то поцарапайте это и вернитесь к первому ответу.

Тот ведущий разработчик, который обучает вас, вполне вероятно, усвоил эти вещи именно таким образом ...

Anoe
источник
2
Так что, нанимайте только высококвалифицированных, полностью обученных и увлеченных людей, чтобы делать ... ну что угодно. Почему мы этого не делаем? Возникает вопрос: как должны жить не очень квалифицированные, не обученные и не находящиеся в восторге люди? Чарльз Диккенс сообщил ответ на этот вопрос: не очень хорошо, если вообще.
@nocomprende, вы проецируете свое мнение, я не имел в виду то, что вы написали в любом случае. Я объясняю причины того, что ОП заметил.
AnoE
Я просто продолжаю думать о вопросе Курта Воннегута от Бога Благослови вас мистер Розуотер : «То , что в аду люди для
2
@nocomprende, если я говорю о "не обученном человеке", я не говорю, что люди глупы, я говорю, что по любой причине человек сделал работу, которая не была хорошо подготовлена ​​для этой работы. Ошибка могла быть с его менеджером за то, что он дал ему неправильную работу; или с обстоятельствами (например, заболевание сотрудника), или по любым другим причинам, которые вы можете себе представить. Это не имеет ничего общего с предложением, чтобы мы нанимали только великих людей. Если мне придется починить сантехнику в моем доме, вы можете быть совершенно уверены, что я устрою беспорядок, хотя я великолепен во всем, что бы я ни делал.
AnoE
1
В антропологии существует старая идея, что рабовладельческие общества, такие как древние египтяне, получали гораздо меньше людей, чем общества, которые помогают людям «процветать». Вот почему капитализм был лучше, чем средневековая культура. В идеале, каждый мог бы добиться успеха, и тогда мы получили бы полную выгоду от каждого человека, а каждый человек - от общества. Капитализм недостаточно хорош для этого, поэтому нам нужно нечто большее. То, что есть люди, выполняющие работу, не являющуюся оптимальной, является доказательством, потому что если бы капитализм был совершенен, этого бы не произошло
11

Я думаю, что в Испании это константа, потому что, когда разработчик проводит много лет в компании, он (или она) обычно продвигается в области управления, такие как анализ и управление проектами. В результате рецензирование не проводится, и код обычно пишется менее опытными людьми.

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

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

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

Рауль Луна
источник
16
Ничего общего с Испанией. Это принцип Питера - люди продвигаются с должностей, где преуспевают, пока не достигают того, чего не достигают, и застревают там, потому что им нечего продвигать.
Ян Худек
3
Существует также тот факт, что индустрия программного обеспечения все еще растет, поэтому людей с относительно небольшим опытом стало больше. И что во многих компаниях вообще нет опытных людей, потому что они новички и слишком дешевы, чтобы нанять ветерана, думая, что подойдет кучка новичков из колледжа - они не будут.
Ян Худек
1
@JanHudec Я не знаю, чувак, мне кажется, что я бы предпочел, чтобы я был молодым студентом из колледжа, чем один из тех людей с 20-летним опытом, о которых рассказывает оригинальный плакат
Мики Маус
9
@ MikeyMouse, правда, есть много людей, у которых нет 20-летнего опыта, а скорее 20-летний опыт работы. И они приносят действительно большие неприятности.
Ян Худек
".. принцип Питера .."; особенно в правительственном учреждении, где это более сознательное явление. Я называю это их программой управления инбридингом. Хотя часто существует хорошее и плохое кодирование, ужас заключается в том, что MIP усиливает некомпетентность. Годы спустя, когда те определенные младший. программисты теперь являются руководителями отделов, которые, в свою очередь, не будут продвигать никого лучше, чем они, хорошие люди и идеи уходят или вытесняются. Магазин стал корзинкой дел некомпетентности; застрял в "остаточном настроении радиационного фона" программирования на мэйнфреймах в культуре идти вместе, чтобы ладить.
радаробоб
7

Некоторые из «лучших практик», которые вы изучаете в школе, не являются практичными или экономически эффективными в реальных проектах. Одно из самых больших изменений, которое я заметил, было в форматировании и комментариях. Большинство моих профессоров подчеркивали важность подробного документирования вашего кода, но в реальном мире хороший код часто (не всегда!) Говорит сам за себя, и что более важно, многие руководители не хотят платить за то, что вы тратите дополнительное время на написание. Комментарии.

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

Тем не менее, одна из самых больших проблем, которые я заметил во многих командах и проектах, - это это нежелание узнавать что-то новое., Многие из старых программистов, с которыми я общался, начинали свою карьеру в период «Дикого Запада» разработки программного обеспечения, когда квалификации начинались и заканчивались готовностью писать код. Они часто специализировались в совершенно разных областях и прыгали в программирование практически без какого-либо формального образования, когда появилась возможность (например, у их работодателя не было программиста, и ему нужно было кого-то учить, чтобы создавать собственное программное обеспечение). Некоторые из этих программистов-самоучек старой школы никогда не прилагают усилий для изучения современных методов кодирования и продолжают писать код примерно в том же стиле, в каком они учились десятилетия назад. Когда они в конечном итоге отвечают за новые проекты из-за старшинства, они, как правило, сдерживают проекты и наносят ущерб общему качеству кода.

Конечно, вышесказанное не относится ко всем более старым программистам, и кодеры нового поколения могут быть такими же виновными. Я работал со многими младшими программистами, которые подобрали несколько инструментов и библиотек только что из колледжа, а затем полностью прекратили обучение. Они будут загружать IDE или библиотеку один раз и никогда не обновлять ее, если это не требуется их компании (иногда вы можете догадаться, какой год выпускал программист, исходя из того, насколько устаревшими являются его библиотеки). Они не поспевают за новыми возможностями на выбранном ими языке и никогда не изучают новые языки. Они не изучают новые стратегии программирования и могут неправильно использовать шаблоны или парадигмы, потому что они не знают более подходящих альтернатив (о, MVC, как сильно вы подвергаетесь насилию). Со временем их рабочий процесс становится все более и более устаревшим, и они становятся скорее пассивом, чем активом.

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

user45623
источник
19
Мне очень не нравится этот миф, что хороший код говорит само за себя, а комментарии устарели. В лучшем случае хороший код точно скажет вам, что происходит. Тем не менее, он не дает никаких указаний относительно того, почему он что-то делает или даже если это правильно. Прокомментируйте свой код, чтобы его будущий сопровождающий не догадывался, почему вы обманываете foo, а не bar .
user369450
13
Я не согласен с вашим первым абзацем. Документирование вашего кода (например, с комментариями), по крайней мере, так же важно, как когда вы учились в колледже. Разница в том, что ни один профессионал не прокомментирует, что делает линия - они документируют ПОЧЕМУ. То, что происходит, можно прочитать из исходного кода. Почему часто результат от нескольких минут до нескольких часов мышления.
Арахо
1
Существует очень мало причин, чтобы написать, почему код что-то делает, и в большинстве случаев это можно объяснить с помощью лучшего имени метода. Посмотрим правде в глаза, большая часть кода, который мы все обычно пишем, достаточно проста, чтобы не заслуживать комментариев.
BgrWorker
1
Как это снова? Код пишется один раз и читается много-много раз. Пишите комментарии, и в конечном итоге вы сэкономите время. @BgrWorker Зависит от человека, я думаю. Я регулярно пишу алгоритмы и думаю, что они заслуживают комментариев (последнее - символический анализатор математики ... определенно нужны комментарии)
person27
1
Я думаю, что юнит-тесты гораздо ценнее комментариев. Слишком часто я встречал ситуации, когда код обновлялся, а комментарии больше не применялись. В этом случае устаревшие комментарии затрудняют понимание того, что происходит. Модульные тесты документируют намерения первоначального программиста, и если ваша система CI выполняет модульные тесты при регистрации, вы обязаны их поддерживать.
bikeman868,
2

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

Джон Смит
источник
Отказ, как правило, тоже не вариант.
1

Я думаю, что важно не просто отличать правильное от неправильного, но знать причины, лежащие в основе каждого правильного и неправильного. Когда вы знаете причины, вы можете предсказать последствия. Зачем использовать тот или иной принцип не потому, что он был описан в книге, а потому, что мы знаем, как он помогает и что именно происходит, если мы его нарушим. Если вы знаете, что происходит, тогда вы можете взвесить все за и против и принять решение. Это также поможет вам аргументировать свою позицию каждый раз. SOLID и OOP также могут снизить затраты на техобслуживание при правильном использовании.

SOLID, если он используется слишком догматично, приводит к слишком большому количеству классов и методов, что тоже не так уж хорошо. Не переусердствуйте. Это отчасти большая проблема с нашими учебниками и учебными пособиями, поскольку они часто пытаются продвигать идеи без должного обоснования. У ООП тоже есть свои минусы. Многие принципы и парадигмы противоречат друг другу. Вам не нужно быть на вершине, вам нужно сделать все разумно, оправданно, элегантно и просто.

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

Я понимаю что ты чувствуешь. Не паникуйте . Вам понадобится то, что вы знаете, может быть, не сразу, но это поможет вам. Может быть, на другом рабочем месте, может быть, в некоторых случаях. У вас впереди время, чтобы идти дальше.

Gherman
источник