У меня есть вопрос, который был поднят моей последней работой (скорее, стажер).
Просто чтобы разобраться с ситуацией - мне 21 год, и я закончил 2-й курс университета до этого, у меня было около 2-х лет опыта работы в sys admin / QA, и в целом я могу сказать, что я видел, насколько разные IT секторы работали. Перенесемся в настоящее время и вот я устроился на стажировку в одном из ведущих исследовательских институтов в Великобритании.
Что мне нужно сделать, так это создать несколько внутренних инструментов, используя сочетание технологий - в основном AWS / Java / Bash - и вы получите представление. Все в порядке, я делаю свою работу, но я не счастлив. Почему это так, потому что я должен работать в специальном деле. То есть создавать вещи быстро, не тратя время на проектирование. Мой менеджер прямо сказал, что от проблем, как они возникнут, мы должны были "спешить", а мы - по сути. Как следствие, оказалось, что вещи должны быть переделаны и переработаны, и они все еще не совершенны. Что касается тестирования, сведите его к минимуму, если оно работает, то все в порядке.
Я виноват, что не согласен с таким способом ведения работы? Неправильно ли хотеть продумать систему в целом, затем сосредоточиться на разных компонентах и посмотреть, как они могут взаимодействовать, сосредоточиться на разных «ключевых моментах», которые могут оказаться проблематичными в будущем? Является ли преступлением желание делать хорошую работу, а не «быструю»? Является ли ошибкой или неправильным отношением желание исследовать структуры данных, применимые к проблеме, чтобы вы могли выбрать лучший в зависимости от конкретного набора проблем? Насколько я понимаю, бит «Инжиниринг» в «Инженерии программного обеспечения» имеет отношение именно к этому: исследуйте свою проблемную область и примите обоснованное решение, а затем уточните, если необходимо?
Я был на собеседовании в офисе Arm в Великобритании, и они показали мне свою комнату SCRUM, и, похоже, у них было довольно хорошее представление о том, как управлять своим проектом - у них было отставание, у них были показатели относительно продолжительности каждого из них. проблема может потребоваться, чтобы решить - обычные вещи для SCRUM - полностью отличается от того, как все работает "здесь"
Разве я построил неправильное представление о индустрии программного обеспечения в целом? Я хотел бы услышать ваш вклад по этому вопросу. Я имею в виду, что «вошел» в разработку программного обеспечения исключительно потому, что хочу создавать вещи - простые и понятные, но я хочу создавать качественные вещи. Я хочу, чтобы мое программное обеспечение использовалось в различных сценариях, я хочу видеть его пуленепробиваемым - разве это не движущая сила для всех разработчиков программного обеспечения? Я думаю, что каждый может быть программистом / программистом, просто изучая синтаксис, но для меня, где настоящее веселье начинается, когда вам действительно нужно придумать дизайн, который выполним в реальном мире.
Раньше я выполнял свои университетские задания, просто просматривая их и непосредственно начав кодировать, и мог легко получить оценки выше 75% и никогда по-настоящему не ценил модуль «жизненный цикл разработки программного обеспечения». Но теперь, когда я увидел в реальном мире, как плохо работать без какого-либо формального процесса и разочарования, которое присуще ситуации, когда вы не знаете, изменится ли требования завтра (о, я говорил, что мы не не имеет четко определенный анализ требований?)
Мне действительно нравится верить, что я только что получил положение, когда некоторым людям просто нужна была обезьяна кода, чтобы выполнить свою грязную работу, и это не тот случай, когда мир программного обеспечения работает в целом.
because I'm expected to work in an ad-hoc matter. That is create things quickly, without spending time on designing
- Добро пожаловать в The Real World ™, где есть крайние сроки, и компании должны давать результаты.