Являются ли мои негативные стажировки репрезентативными для реального мира? [закрыто]

Мне любопытно, если мой нынешний опыт в качестве стажера является представителем реальной отрасли.

В качестве фона, я прохожу большую часть двух компьютерных специальностей и математики в крупном университете; Я оценил каждый класс и обожал их всех, поэтому я хотел бы думать, что я не ужасен в программировании. Я прошел стажировку в одной из крупнейших компаний-разработчиков программного обеспечения, и на полпути я был шокирован необычайно низким качеством кода. Комментарии не существуют, это весь код спагетти, и все, что может быть не так, еще хуже. Я сделал кучу репетиторств / TAing, так что я очень привык читать плохой код, но основные отраслевые продукты, которые я видел, превосходят все это. Я работаю по 10-12 часов в день и никогда не чувствую, что я куда-то добираюсь, потому что это бесконечные часы попыток выяснить недокументированный API или определить поведение какой-либо другой части (полностью недокументированного) продукта. До сих пор я ушел с работы, ненавидя эту работу каждый день, и я отчаянно хочу знать, готовится ли это до конца моей жизни.

Я нарисовал короткую соломинку на стажировках (нелепо большие зарплаты означают, что это не низкокачественная позиция), или это то, на что похож реальный мир?

Они называют это Real World ™ по причине.

99% того, с чем вы столкнетесь в реальном корпоративном мире, будут считаться дерьмом, и на то есть веские причины, которые я объясню. 1%, который не считается дерьмом, со временем станет дерьмом.

# 1 Напиши код, # 2 ????, # 3 Прибыль!

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

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

Теория 0 - Практика ∞

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

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

В теории нет разницы между теорией и практикой. На практике есть. - Йоги Берра

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

Физика жизненного цикла программного обеспечения

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

Чем дальше вы начнете с BBM, тем лучше, но каждая программная система в конечном итоге получит достаточно времени. То, как быстро вы подходите к 100% энтропии, определяется тем, с чего вы начинаете, и насколько быстро вы накапливаете технический долг и насколько высоки проценты по нему.

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

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

Хорошо, достаточно Хорошо, достаточно

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

Системы с длительным жизненным циклом, такие как упомянутая выше внутренняя линейка бизнес-приложений, также не получают больших инвестиций в модульные тесты с 100% -ным охватом кода, потому что скорость изменения в течение срока службы проекта приближается к константе, близкой к нулю в нелинейная мода.

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

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

Вот почему Good Enough - это Good Enough , все, что более или менее - нет.

Программное обеспечение трущоб

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

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

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

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

Прогноз

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

Я потратил 15 лет на консультации и очень быстро понял, что достаточно хорошо , все остальное стоило мне денег. Да, я хотел, чтобы все было идеально, но если вы не продаете кодовую базу, что в 99,9999% времени вы продаете решение , весь этот идеально чистый, организованный элегантный код теряется, и вы просто напрасно тратите свое время, вы никогда не получите компенсацию за ,

Прогресс и Надежда

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

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

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

Agile, когда все сделано правильно, помогает управлять энтропией, замедлять ее, отслеживать, измерять и решать с ней в плановом порядке. Это не остановит!

Карьера Решение

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

Мне любопытно, если мой нынешний опыт в качестве стажера является представителем реальной отрасли.

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

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

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

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

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

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

Бизнес либо не заботится об этом дополнительном времени, либо считает его приемлемым.

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

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

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

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

Я нарисовал короткую соломинку на стажировках (нелепо большие зарплаты означают, что это не низкокачественная позиция), или это то, на что похож реальный мир?

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

Я могу сказать вам, что, похоже, ваш опыт в вашем возрасте был намного лучше, чем любые возможности, которые у меня были. Жизнь для меня в 90-х годах была борьба за оплату аренды и найти мой следующий контракт. Считай, что тебе повезло.

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

Код, который вы видите, часто проходит бесконечные итерации разными программистами с разными подходами и стандартами, разными соглашениями об именах и т. Д. И т. Д.

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

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

Как и в случае с Дреккой, это начинает звучать удручающе, поэтому позвольте мне попытаться стать немного более позитивным, потому что, безусловно, верно то, что: -

• Есть организации, часто с крупнейшими техническими компонентами, которые делают правильные вещи.
• Новая компания ... и код ... уборщик он имеет тенденцию быть. Спагетти растет за счет времени и людей.
• Некоторые люди делают TDD и BDD, другие нет. Ассортимент огромен.
• Спустя примерно 10 лет в настоящее время вся технологическая база меняется, поэтому тем, кто остается в отрасли, может быть так же трудно справляться, как и новичкам.

Наконец, как отмечает Энтони Блейк, всегда есть 3 фактора - время, стоимость и качество.
Мне нравится связанное выражение: «выбрать 2» !

Есть много мнений по этому поводу, потому что у всех разные впечатления.

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

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

Вы должны принять во внимание тот факт, что большинство компаний собираются дать стажерам дрянную работу. Самое интересное приходит после того, как вы сделали две вещи: 1 - зарекомендовали себя и 2 - потратили некоторое время на то, чтобы поработать не только над ошибками других людей. Другими словами, вы должны проявить способность и инициативу.

Реальный трюк с обработкой плохого кода - выяснить, что можно использовать, а что нет. Это происходит из опыта и исследований.

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

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

Извините, если это звучит удручающе. Я уверен, что кто-то другой может сделать более позитивную вещь. :-)

Здесь есть несколько отличных ответов, но позвольте мне добавить немного;

Добро пожаловать в реальный мир - к сожалению, это очень распространено.

Обратитесь к диаграмме ниже;

С корпоративным программным обеспечением вы можете выбрать только 2 или выше, и вы должны пожертвовать одним.

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

Не совсем показательно для отрасли, но из моего ограниченного опыта 5+ лет. Я проработаю вашу стажировку и получу как можно больше уроков из этого опыта. Ищите признаки и индикаторы. Например, для вашей следующей должности вам, без сомнения, придется пройти серию интервью. Этот процесс является двусторонним путем и дает вам возможность почувствовать компанию. Это жизненно важно и, вероятно, приведет к вашему собственному счастью и благополучию.

Подводя итоги, определите признаки сказки;

• Кто управляет компанией? Является ли это одним менеджером, группой маркетинга (если да, держаться подальше), командой разработчиков и т. Д. Этот угол означает, что вы можете получить больше или меньше рычагов для проектов, время, потраченное на проекты и т. Д.
• Есть ли техническая оценка? Посмотрите, как менеджмент, руководитель и члены команды относятся друг к другу. Я был на собеседовании, где менеджеры делали все виды движений бровей, как только технический руководитель начал говорить. После этого и узнав, что они не использовали контроль источников - вы не могли достаточно быстро показать мне дверь.
• Бизнес цель? Живет ли компания изо дня в день, как в ежедневных финансовых целях, или у нее есть долгосрочный план, частью которого вы являетесь. Разработка программного обеспечения обычно выполняется в течение нескольких месяцев, поэтому наличие компании с шизофреническим характером обычно приводит к грязному программному обеспечению.
• Копайтесь по кругу - задавая технические вопросы, и смотрите, не перемешаются ли люди. Контроль исходного кода, контроль документов, процесс выпуска, отчеты об ошибках, стиль управления, T & C и т. Д.

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

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

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

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

Я думал об этом одном проекте вчера. Это был такой очевидный несбыточный сон для меня, что я отскочил от двери по-настоящему минимально функциональной штуки. Я считал это пустой тратой времени и ресурсов.

Ну, удивление, удивление, всем понравилось, и это сработало хорошо. Поэтому я отскочил назад к чертежной доске и сделал все правильно. И новая версия была потрясающей! Но затем произошел оборот в управлении, и все это было пересмотрено в пользу «нового направления бизнеса».

Во второй итерации было развернуто наполовину развертывание внутри компании, и я никогда не слышал об этом ничего другого, что забавно, потому что я знаю, что по крайней мере ~ 10 бизнес-единиц все еще используют его (программное обеспечение, которое мы вводим в эксплуатацию, чтобы выполнить эту работу почти на 2 года отстает от графика) и, видимо, он никогда не ломается.

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

Трудно сказать, что вы считаете ужасно низким качеством кода, но да, немногие программисты очень хороши (по определению). По мере развития программного обеспечения люди совершают ошибки. Со временем они накапливаются, а давление бизнеса (и лень / невежество программиста) делает рефакторинг ... необычным.

Не могу говорить за всех, но вот что я могу сказать.

Я не работал более 30 лет в этой области, но я видел достаточно, чтобы сказать несколько вещей. Проект имеет жизнь, очень похожую на человека. Первоначальный дизайн может не соответствовать текущим потребностям, скажем, одного проекта после 20 лет разработки. Тем не менее, за это время многие люди изменили испорченный им код и добавили вещи, которые поначалу не предполагались.

Нетрудно представить себе некрасивый код в старых или довольно старых проектах. Мы не можем ожидать, что все полностью поймут первоначальные проекты. Печально, но так оно и есть.

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

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

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

Если вы закончите рефакторинг проекта, вы можете оказаться тем человеком, на которого указывают плохие дизайнерские решения! И тогда вы можете понять, почему рефакторинг не происходит так часто. Надеюсь, что если вся команда будет рефакторинг, то никто не будет указывать. Они просто всех уволят =)

Я бы попытался подвести итог ответа на эти вопросы с помощью простой цитаты:

All code turns to crap given enough time and hands.

Остальные просто истории ...

Качество кода зависит в основном от двух факторов.

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

Второе это люди. Прежде всего, те, кто принимает решение о бюджете, должны выбрать расходы на качество кода, затем они должны привлекать людей, которые хотят «жить». Как вы можете себе представить, может оказаться трудным превратить хорошо оплачиваемый пятидесятилетний программист сверху-вниз на Delphi (без стереотипов, извините) в современного разработчика Java, который занимается сборкой и производством CI. слабосвязанный код Многие разработчики испытывают отвращение к урокам (может быть, молодых) товарищей, им не нравится, когда кто-то ловит рыбу в своем пруду или гремит на троне.

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

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

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

Я получил стажировку в одной из крупнейших софтверных компаний

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

Я думаю, что ребята из Solaris сделали очень хорошее и честное описание того, какие кодовые базы вы найдете в крупных компаниях: http://hub.opensolaris.org/bin/view/Community+Group+on/dev_solaris.

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

Нет, я кодирую уже более 15 лет и все еще люблю это.

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

Большая компания сильно отличается от маленькой. Внутри одной и той же компании A иногда очень разные формы команды B. Найдите того, кто имеет правильный баланс для вас (например, сложные проекты, культура, которая вам нравится, хорошая оплата и так далее)

Удачи!

Я видел подобные вещи, как вы. У меня есть два случая, когда это происходит.

1. Когда разработка слишком ориентирована на проект. Единственное, что имеет значение, - это обеспечить функциональность вовремя, а затем завершить работу. Следующее изменение будет сделано кем-то другим, другой командой / менеджером проекта с новым бюджетом.
2. Когда часть программного обеспечения обслуживается всего несколькими людьми в течение длительного времени, разработчики склонны лениться, так как они все равно знают свою часть программного обеспечения. Академические принципы далеко.

Это печально, но в некоторых местах так оно и есть.

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

Это будет короткий ответ.

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

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

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

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

Ваш негативный опыт слишком типичен для крупных известных компаний известных брендов, к которым многие разработчики обращаются с гораздо большей осторожностью и трепетом, чем в первый раз, когда у них была возможность работать в одной из них. По сути, чем больше у вас уровней управления, тем выше посредственность. Менеджеры среднего звена не отчитываются перед менеджерами высшего звена о качестве кода. Они сообщают о функциях, предоставляемых за X раз, и проводят презентации PowerPoint с помощью функции neato UI, которые, как они надеются, работают достаточно долго, чтобы справиться с ними. Если все это рухнет само по себе через месяц, это обычно чья-то проблема, и они это знают.

Так что да, разработчикам, которые живут в таких местах, как правило, наплевать. Они не могли бы выжить там, если бы они сделали. Я слышал, что в Силиконовой долине сказано, что если хочешь быть ленивым, работай на одного из знаменитостей. Если вам нужна захватывающая работа, поищите более поздний стартап, который пока не является именем нарицательным. Я работаю в Чикаго и могу поручиться за подобное явление здесь.

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

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

И, конечно же, работая с более популярными корпоративными инструментами, вы обнаружите, что средний уровень талантов будет довольно вялым. Если ваши основные навыки - это сочетание Java и C #, немного расширяйте свой кругозор. Вы можете найти более счастливую нишу в написании Erlang или Python среднего уровня или: o JavaScript.

И не позволяй никому говорить тебе иначе. У вас может не быть выбора в отношении того, как поступить, но чушь кода стоит! @ # $ Дорого.

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

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

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

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

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

Удачи.