Поскольку я профессиональный студент…
Советы молодого выпускника CS, которые я хотел бы получить во время учебы
Я создал блог!
Новые истории будут публиковаться в моем блоге: https://www.flavienbonvin.com/
Я быстро рассказал о степени бакалавра, которую закончил прошлым летом в предыдущем посте. Поскольку я профессиональный студент (по крайней мере, в течение следующего года, в течение которого я буду получать степень магистра), я хотел поделиться с вами некоторыми советами, которые я хотел бы услышать, когда работал над своими школьными проектами. Некоторые моменты, которые я собираюсь затронуть, явно смущают меня (поскольку для некоторых они очевидны), но я хочу быть честным и поделиться тем, что я не знал или не считал важными.
Однако перед этим я хочу рассказать немного о себе, чтобы помочь вам понять, какие исследования я проводил, поскольку они могут отличаться от других в мире. На самом деле у меня есть степень бакалавра в области информационных технологий для бизнеса, это означает, что наша учебная программа сосредоточена на двух областях: бизнес и ИТ. Бизнес-уроки, которые я взял, были посвящены таким областям, как управление проектами, анализ конкурентов, бухгалтерский учет или маркетинг. Цель заключалась не в том, чтобы сделать нас лучшим бизнес-аналитиком или позволить нам создать нашу собственную компанию и управлять всеми ее аспектами, а скорее в том, чтобы дать нам более широкий взгляд на то, что может сделать разработчик (в зависимости от компании, в которой вы работаете). Это сделало нас чувствительными к вещам, отличным от простого программирования. Такие задачи, как обсуждение с клиентом, преобразование его или ее потребностей в спецификации, отслеживание потраченного времени… На мой взгляд, так же важны, как и разработка самого продукта.
Чтобы помочь нам отработать эти навыки, у нас было много проектов (иногда слишком много одновременно). Вначале они были довольно простыми, просто возвращали программу, но по мере того, как исследования шли, они становились все более и более требовательными. Нам приходилось работать в команде, использовать методологию Agile, организовывать встречи с клиентами,… Мне искренне было слишком приятно работать с друзьями над этими проектами, это было для меня ярким и новым опытом.
10/10 сделает это снова.
Мы использовали несколько технологий для разработки этих проектов, большинство из них были веб-сайтами / службами, написанными на NodeJS, ASP.NET или Java EE. Мы разработали несколько приложений для Android на Java, включая мою дипломную работу бакалавра, но у нас не хватило смелости сделать их на Kotlin (но об этом позже). Наконец, нам пришлось разработать некоторые настольные программы на Java. Это были те языки программирования или фреймворки, которые я использовал на протяжении всей учебы. В некоторых проектах была навязана технология (иначе мы бы не использовали Java EE!), А в отношении других мы могли выбирать. Помимо этого, мы, очевидно, работали с базами данных, мы использовали SQL, MongoDB и Firebase.
Теперь, когда это не так, давайте перейдем к тому, чем я хочу поделиться. Не стесняйтесь поделиться любым моментом, который я мог пропустить, это тот, который я имел в виду или который предложил мой сосед по комнате.
Попробуйте новые технологии
Я усвоил эту ошибку на собственном горьком опыте, когда искал работу. Школы предназначены для того, чтобы научить нас новому, и я не применял этот принцип во время учебы в бакалавриате. Я слишком часто обращался к надежным и хорошо известным технологиям для наших проектов, будь то NodeJS для нашего веб-проекта или Java для приложений Android, я не был очень предприимчивым (за исключением проекта, в котором мне было поручено использовать что-то особенное). Для меня это означает отсутствие PHP, React, Angular, Vue или Kotlin. Это привело к неуверенности в моих навыках при приеме на работу, которая требовала знания этих фреймворков или языка программирования.
Надеюсь, в какой-то проект были навязаны технологии, без этих учителей я бы выбрал то, что я уже знал. Однако я не уверен, что у студентов достаточно зрелости и профессионального опыта, чтобы понять, насколько важно экспериментировать, когда у них есть такая возможность. На мой взгляд, это то, что профессора должны были сказать нам в начале проекта. К сожалению, я не помню, чтобы учителя обращали нас к этому вопросу, но я мог пропустить этот момент из-за следующего :).
В конце концов, наберитесь смелости, чтобы пробовать новые вещи и изучать новые навыки, это цель школы, в которой вы находитесь. Не выбирайте удобный и путь, попробуйте поехать по бездорожью смешнее.
Не торопитесь, прежде чем начинать
Я не могу вспомнить, сколько схем базы данных я прошел во время нашего проекта. Я думаю, что каждая пользовательская история приводила к новой схеме базы данных (возможно, нет, но вы поняли). Я просто не тратил достаточно времени на размышления о проблеме, которую должен был решить, и сразу занялся кодированием. Это известная проблема среди разработчиков.
Мы любим кодировать, а не документировать.
Даже если это обычное заболевание, мне хотелось бы узнать об этом раньше. Не то чтобы это повредило мне в моей работе, но это сделало бы проекты более расслабленными и менее напряженными.
Однако отсутствие времени может быть вредным в ситуациях, когда вам приходится иметь дело с клиентом, если вы его не делаете. Не тратьте необходимое время на понимание и воплощение своих потребностей, вы можете пойти в противоположном направлении, чем того хотел клиент.
В конце концов, это просто: не торопитесь и потратьте один или два часа на обсуждение проблемы, которую вы пытаетесь решить, и на лучший способ достижения своей цели.
Измените свою роль в проекте
Я занимаюсь бэкендом, я не могу с этим бороться, но в каждом проекте мне приходится касаться некоторых (надоедливых 😀) HTML или CSS, и я совершенно не понимаю, как это работает. В какой-то области (той, которой я больше всего увлекаюсь), например в мобильной разработке, я могу разработать красивые экраны и удобство для пользователей. Но что касается Интернета, я так же невежественен, как начинающий пользователь Linux перед vim. А если серьезно, мы всегда организовывали наш проект в команде frontend / backend, а я всегда выбирал backend. Этот момент связан с первым, что я сделал, но, помимо того, что я пробовал новые технологии, мне хотелось бы знать, что выход из зоны комфорта и принятие новой роли было таким важным.
Это нормально. что вы знаете / любите, но переход от внешнего интерфейса к бэкенду (и наоборот) даже для одного проекта может иметь огромное значение. Если бы я применил это, я бы знал, как создать веб-страницу и стиль события для объекта в последнем. Этому никогда не поздно научиться, но я думаю, что это легче сделать в школе, чем в сложном корпоративном проекте.
Если честно, мне кажется, я знал об этом. В глубине души я знал, что совершаю ошибку. Но я проигнорировал это и продолжил использовать серверную часть.
Выйти из зоны комфорта и попытаться взять на себя ответственность, на которую вы никогда не брали, может сильно помочь в будущем.
Потому что, в конце концов, фронтенд и бэкэнд должны работать вместе. Хороший проект похож на хорошие отношения: не может быть чего-то святого, если вы не можете поставить себя на место другого и понять его проблемы.
Сохраняйте свою роль, но касайтесь других частей кода
Я знаю, я только что сказал, что смена ролей необходима, а теперь говорю обратное! Но для меня это тоже важно. Позвольте мне проиллюстрировать это на примере: я не знаю, как маршрутизировать трафик в приложении NodeJS, по крайней мере, сделать это правильно (перенаправление «верхнего уровня» / admin / login,…). Это пример того, чего я никогда не касался, даже если всегда был в бэкэнде. Мой друг был отличным разработчиком и всегда брал на себя эту ответственность. Я не могу винить его, но могу винить себя. Я должен был прокладывать маршруты самостоятельно, и выбор легкого пути, опять же, был не лучшим выбором.
Так что не ограничивайтесь знакомыми частями, а экспериментируйте с неизвестными вещами.
Не переусердствуйте и не недооценивайте свои проекты
При разработке проектов я сосредоточился на предоставлении лучшего программного обеспечения в своем классе, вместо того, чтобы пытаться накопить как можно больше знаний. Я участвовал в своего рода соревновании, которое я создал без всякой видимой причины (это было что-то особенное в нашем классе, я был не единственным в этой ситуации). Это означало, что я сосредоточился на реализации как можно большего количества вещей, а не на обучении. Кроме того, оценка была такой же или ненамного лучше, чем в других группах. Я не имею в виду, что оценки важны, а скорее для того, чтобы подчеркнуть, что школы предназначены для обучения, а не для конкуренции друг с другом (по крайней мере, в моем оптимистическом воображении).
Так что придерживайтесь того, о чем просили, но находите время, чтобы сделать их правильно и учиться чему-то, делая это очень важно и то, что я полностью игнорировал.
Делайте то, что ожидают учителя, и никого не удивляйте, внедряя бесполезную чушь, это не всегда принесет вам пользу, и вы упустите другие базовые навыки.
Сделать ридми
Лучшее я оставила на конец! Это нелепо и очень субъективно, но, на мой взгляд, создание ридми при разработке проекта критично. Это делает весь ваш профиль на Github более привлекательным и захватывающим (более захватывающим, чем мой). Когда я искал работу, мне было немного стыдно за свой профиль git из-за этого, но я не стал создавать ридми,…
Таким образом, чем быстрее будет выполнен ридми, тем легче их будет сделать и тем больше будет результат.
Вот как выглядит Git без readme - пустота и пустота!
Вау, это должен был быть быстрый список пунктов, преобразованный во что-то большее, чем ожидалось! Я искренне надеюсь, что то, что вы читаете, ценно и поможет вам в учебе. Я также молюсь, чтобы вы не воспроизводили некоторые из моих ошибок! Не стесняйтесь поделиться любыми другими интересами, я буду более чем счастлив прочитать и обсудить их!
Я быстро рассказал о своем посте с презентацией, если вы его не читали и вам интересно, вот оно!
