Ожидания выпускников и реальность [закрыто]

https://softwareengineering.stackexchange.com/questions/12589

16-10-2019
|

Вопрос

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

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

Обслуживание:В университете нам всем говорили, что большая часть работы по программному обеспечению — это обслуживание существующих систем.Так что я знал, что можно ожидать этого абстрактно.Но я никогда не представлял, насколько ошеломляющим это окажется.Возможно, это то, что я мысленно затмил и надеялся, что мне удастся создавать новые крутые вещи с нуля.Но на самом деле большинство работ в основном ориентированы на обслуживание, исправление ошибок и поддержку.
Недостаток профессионализма:В университете у меня всегда сложилось впечатление, что работа по коммерческому программному обеспечению очень ориентирована на процесс и тщательно спроектирована.У меня были изображения процессов ISO, стопки технической документации, каждая функция и ошибка строго документировались, и в целом профессиональная среда.Для меня стало огромным шоком осознание того, что большинство компаний-разработчиков программного обеспечения работают так же, как команда студентов, работающих над большим семестровым проектом.И я работал как в небольшой agile-мастерской, так и в корпоративном предприятии среднего размера.Хотя я бы не сказал, что это всегда было откровенно «непрофессионально», определенно создается впечатление, что индустрия программного обеспечения (в целом) далека от той сильной инженерной дисциплины, которой я ожидал.

Был ли у кого-нибудь еще подобный опыт?В чем ваши ожидания относительно того, какой будет наша профессия, отличались от реальности?

Решение

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

Вещи, которые я не ожидал:

Школьный стресс и стресс на работу не такие- Стресс от работы над школьным проектом с друзьями или работой соло, даже с тем, что срок действия тезисов или специальная защита проекта не сравнится со стрессом, казалось бы, необоснованных сроков работы, проблем с общением (небольшая офисная политика) и хруста времена

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

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

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

Другие советы

Большая часть работы, которую вы выполняете, не является новаторской

В Uni я работал над управляющими рутинами ИИ, чтобы управлять футбольными роботами, я построил компиляторы и взломал ядра операционной системы.

Но в реальном мире 99%^* разработка программного обеспечения на самом деле довольно скучно. Я всегда восхищался архитекторами или строителями, кого, когда его спросили: «Чем вы зарабатываете на жизнь?» может указать на здание или что -то еще и сказать: «Я сделал что«Но большинство разработчиков программного обеспечения не могут этого сделать. Когда спросили:« Чем вы зарабатываете на жизнь? »Самое близкое к тому, что я когда -либо смог приехать, - это когда я работал в компании, которая создала программное обеспечение, которое Обработанные SMS -сообщения для радиостанций и тому подобное ... Я мог бы сказать: «Вы знаете, когда вы отправляетесь на радиостанцию, чтобы проголосовать за песню, ну, я написал программное обеспечение, которое обрабатывает эти голоса и прочее». Все же, где рядом с Такой крутой, как способность указывать на здание и сказать: «Я построил это».

Конечно, там находятся Люди, которые могут сказать «Я работал над окнами» или чем -то еще, но я уверен, что они на самом деле никому не говорят, что опасается, что следующий вопрос - «Я не могу заставить свой принтер работать, не могли бы вы это исправить мне?"

^* и 62% всех статистических данных составлены на месте

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

полное интервью: http://queue.acm.org/detail.cfm?id=1039523

Я не ветеринар в отрасли; Наоборот, я недавний выпускник, но из лучшей школы CS в США, но мое инстинктивное чувство состоит в том, что то, как мы строим программное обеспечение, неправильно. Вместо того, чтобы нажимать кнопку паузы и пересматривать основы того, как мы программируем, мы только что бросились вперед, используя устаревшие модели 50 -х годов, 60 -е годы постоянно добавляя немного сахара сверху. Если мы будем продолжать так, мы никогда не пройдем, где мы находимся. Люди просто не могут управлять сложностью вещей, которые имеют размер кодовой базы MS Windows. Нам нужен новый путь. Я не знаю, что это такое.

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

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

Большое железо - Технологии, которые они преподавали, были в первую очередь мэйнфреймы и мини -компьютеры. Декан одного колледжа сказал мне, что я не смогу устроиться на работу, потому что я даже не знал, что такое Masterfile. Я не собирался работать над мэйнфреймами, так как я не мог себе этого позволить, но я не собирался быть настолько глупым, чтобы не быть слегка подготовленным. Ваксен был крутым, и я с нетерпением ждал, чтобы получить оплату за код на моем собственном Micro Vax в моей кабине. Какой позор, что рынок полностью взорвался. (Как оказалось, у меня было две должности, работающие с мэйнфреймом ... как подрядчик для IBM.)
Разработка программного обеспечения - На пятках структурированного программирования, SASD и других методологий проектирования вы, возможно, подумали, что мы будем настоящими инженерами. Я сделал. Но учителя давали очень мало рекомендаций по методам дизайна, которые я читал в библиотеке. Студентам оставалось постоять за себя, и микросхарки позволили слишком легко пролететь в коде, пока они не получили ответ, которым они были довольны. Я не понимал, насколько хуже было на рынке труда. Каким -то образом я должен был сделать немного нового кода, так что это было не так скучно. Но я также много взял на себя, и они были достаточно плохими, это было похоже на новый проект, потому что мне пришлось исправить много кода. Это была комбинация исследования существующей функции и создания нового кода (его замена); Написание инструментов для упрощения процесса и создания лучшего управления проектами.
Высокотехнологичная карьера - Это одна вещь, когда в школах есть старые здания и оборудование (оборудование для перфокартов было заменено в семестр до того, как я начал ... в 1984 году), но когда вы работаете на плохо освещенном складе или для начальника, который висел на клиентах, звонящих Строка поддержки, вы начинаете реализовать свое описание работы, вряд ли будет включать приготовление попкорна с 5-мегаваттным лазером.

Развитие в основном командная работа. Это означает, что общение (разговорное и чтение), чтение кода другого и повторное использование предыдущих модулей (как внутреннего, так и внешнего)-это то, с чем сталкивается почти каждый день. В моем колледже, по крайней мере, мне приходилось кодироваться с большим количеством людей в очень немногих случаях, поэтому я подумал, что основной частью работы было код в одиночку, в пустыне. Нет, это не так.
Объяснить вещи не разработчикам сложно (Также покрывается первым пунктом), и вы обязаны сделать ваши очки (не остальные 99% мира).
Хороший тест - это тест, который терпит неудачу. (В первый раз, по крайней мере) и, конечно, нет такой вещи, как код без ошибок. Вы не плохой программист, если у вас есть ошибки. Ошибки-это просто (очень важная и трудоемкая) часть вашей работы.
Там нет серебряных пуль. Каждая технология имеет свои преимущества и недостатки.
Колледж не преподает вас современные технологии. Но также 90% работ используют довольно старые технологии. Что, кстати, иногда это необходимо.
Нетехнические люди принимают решения о технических решениях, в основном по эзотерическим причинам, таким как обслуживание, партнерство, доступность работника ...
Ты только начинаешь, молодой Падаван.

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

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

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

Добавлен

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

Добавлен

Мои два цента: просто привыкните к этому.

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

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

def lf(p, q, r):
    x = 4
    xx = 4.5
    t = {1:p, 2:p+2, 3:p*4} #I think there's a bug in here but I don't know
    .
    .
    .

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

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

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

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

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

Ожидания пользователей в отношении функций растут с каждым днем, но во многих областях они ниже в инженерных областях.Предположим, программное обеспечение для банковских транзакций так же надежно и профессионально разработано, как современный автомобиль.Управление объемом — современное чудо, но как насчет надежности каждой транзакции?Не так много.Ваш пост о том, что ваш щенок впервые нагадил на коврик, удалили, и что.Это больше похоже на маленькие пластиковые пакеты в продуктовом магазине.Их делают миллиарды, рвут, рвут и выбрасывают.Большинству людей все равно, чтобы требовать сумку получше.

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с softwareengineering.stackexchange