Немного предыстории:
Я один из двух разработчиков программного обеспечения в моей компании, и в настоящее время мы работаем с C++ на встроенных машинах. Мой коллега давно работает с C, и теперь мой начальник хочет улучшить разработку с помощью C++. После стажировки, посвященной созданию веб-приложений, мой начальник попросил меня поработать с этими машинами, ничего не зная о самой машине.
Когда меня предположили, мой босс знал, что я делал что-то на C++ только в школе и что я не делал ничего более личного, но что я хотел узнать больше о том, как разрабатывать программное обеспечение для встроенных машин.
Источник моих проблем:
Итак, как я уже сказал, я начал с чистого листа, разрабатывая программное обеспечение для машин, которые я никогда раньше не видел. У них очень сложная программа, построенная очень сложным образом, в которой иногда отсутствуют возможности ООП и C ++ (поскольку раньше все было построено на C (чего я не знаю, и мой босс знал это)) и у меня много трудностей понять, как это работает, почему что-то было построено определенным образом, какая идея стоит за чем-то и т.д. и т.п.
Я не могу спросить Старшего, так как он делал что-то на C и не программирует эту новую машину (или, во всяком случае, он делает это на C и не хочет изучать C++), и в любом случае он слишком занят.
Однако, несмотря на все эти проблемы, я взял ситуацию под контроль и, по крайней мере, начал знать, как делать некоторые мелочи, и для моего босса это шло нормально ... до сих пор.
Собственно проблема :
Сейчас, по прошествии месяца, из-за трудностей компании меня просят использовать функции Архитектора, а не те, которые я делал самостоятельно. Он человек за кулисами, который написал всю ОС машины, и я не могу связаться с ним, так как он покинул компанию, и может помочь мне, когда его вызывают на «консультацию».
Проблема в том, что я не могу знать, что делает и ведет себя функция, потому что поведение функции закрыто в *.a файлах. Когда я спросил через одно из редких писем, которые я мог отправить, ответ был «название функции и параметры должны прояснить ситуацию, в любом случае у вас есть много документации».
На самом деле ... в этой документации не хватает информации (она заполнена примерно на 30%, чтобы понять идею). И в любом случае это объясняет в целом, что делает функция, предполагая, что я знаю, как работает ОС, какова цель определенной идеи или других случайных вещей, которые я не мог себе представить.
У меня на уме много вопросов, один из которых - уйти из этой компании и заняться веб-разработкой (что меня действительно заинтересовало), но прежде чем приступить к странным идеям, я просто хочу спросить:
Привычно ли работать разработчиком, не имея возможности знать важные вещи в проекте?
На самом деле я понимаю немного здесь и там. Но меня действительно просят решить гигантскую головоломку, не зная, как будет выглядеть окончательная фигура. Поскольку это моя первая работа, я действительно не знаю, что делать, может быть, это распространено в компаниях, и я только разочаровываюсь.
Совершенно нормально, когда разработчика просят творить чудеса в такой ситуации — в плохой компании .
Я работал в кооперативах, где владелец компании ожидал, что я превзойду Билла Гейтса и произведу революцию в его бизнесе. Я сделал все, что мог, но, будем честными, все вышло не совсем так, как они надеялись.
Проблема в том, что многие менеджеры не разбираются в разработке программного обеспечения .
Они не понимают, насколько один язык может отличаться от другого. Они не понимают, что одни области разработки не очень тесно связаны с другими (например, веб-разработка против машинного программирования). Они не понимают сроков разработки сложного программного пакета, последствий изменения масштаба проекта — даже незначительного — и т. д.
Это проблемы, с которыми вы будете постоянно сталкиваться в ходе своей карьеры. Вам нужно будет научиться сообщать о своих опасениях, оценивать сроки доставки (хорошее правило: взять время, которое, по вашему мнению, потребуется, и умножить на 3), а также узнать, когда наступает время GTFO.
Эта компания кажется хаотичной и плохо организованной. Кроме того, ответственное лицо явно понятия не имеет, какого черта они от вас требуют, и оказывает вам небольшую поддержку или вообще не оказывает ее.
На этом этапе вы можете стать более громким, высказать свои опасения и объяснить, каковы ваши собственные планы и сроки выполнения их требований.
Например, вы можете запросить несколько дней, чтобы просто поэкспериментировать с библиотекой и углубить свои знания. Им это может не понравиться, но вы должны объяснить, что без дальнейшего понимания вы вряд ли добьетесь успеха в своих задачах.
Я также хотел бы обратиться к вашему комментарию в адрес Килиси:
я не собираюсь изучать С++ дома или что-то в этом роде
Как разработчик, вы должны будете постоянно повышать свои знания в течение своей карьеры. Только очень плохой разработчик застаивается.
Я не говорю, что вы должны пожертвовать своей личной жизнью, однако, если для достижения успеха в долгосрочной перспективе требуются дополнительные усилия, не стоит так негативно относиться к тому, чтобы потратить несколько часов своего времени на обучение. новая технология.
В конечном счете, если вы хотите заниматься веб-разработкой, вам следует искать новую работу.
Не принято давать новичкам в отрасли такие задачи, если только они не считаются способными. Кажется, что вас забросили на самое дно (что довольно часто).
Вам нужно поговорить об этом со своим менеджером. В частности, вам нужно создать базу знаний с продуктом только для начала. Вы можете двигаться вперед после этого разговора.
Помимо других ответов. Ожидается, что разработчики будут использовать репозитории для хранения своего кода. Даже если они покидают компанию, они должны оставить источник компании, которая заплатила за их работу. Я считаю, что восстановление исходного кода будет полезно не только для вас, но и для компании, которая может потерять это ноу-хау, если о нем забудут. Однажды им может понадобиться изменить одну функцию в файле .a, и никто не сможет ее изменить.
Я предполагаю, что этот код был от вашей собственной компании. Бывают случаи, когда исходный код недоступен. Это может включать:
При кодировании по сравнению с кодом других компаний эта ситуация довольно распространена и неизбежно усложняет ситуацию. Хороший код обычно не требует слишком много объяснений, но хороший код не является нормой, а исходный код полезен для отладки, когда вы не знаете, что происходит. Удачи.
Лилиенталь
МаркВуджи
Брандин
МаркВуджи
Лилиенталь
МаркВуджи
джеймскф