Библиотека knigago >> Компьютеры и Интернет >> Базы данных >> От джуна до сеньора: Как стать востребованным разработчиком


СЛУЧАЙНЫЙ КОММЕНТАРИЙ

# 1616, книга: Путь к себе. Отчим.
автор: Борис Васильевич Изюмский

Роман Бориса Изюмского "Путь к себе. Отчим" — это глубоко трогательное и эмоционально резонансное произведение, которое исследует сложные отношения семьи и путь к исцелению после утраты. Главный герой, молодой человек по имени Андрей, вынужден столкнуться с трагической потерей своего отчима, человека, который воспитывал его с детства. Смерть отчима пробуждает в Андрее болезненные воспоминания и ставит под сомнение его собственное понимание идентичности и принадлежности. В своем...

СЛУЧАЙНАЯ КНИГА

Перерождение. Галина Валентиновна Чередий
- Перерождение

Жанр: Эротика

Год издания: 2018

Серия: Мои оборотни

Владимир Швец - От джуна до сеньора: Как стать востребованным разработчиком

От джуна до сеньора: Как стать востребованным разработчиком
Книга - От джуна до сеньора: Как стать востребованным разработчиком.  Владимир Швец  - прочитать полностью в библиотеке КнигаГо
Название:
От джуна до сеньора: Как стать востребованным разработчиком
Владимир Швец

Жанр:

Базы данных, Корпоративная культура

Изадано в серии:

неизвестно

Издательство:

Альпина Паблишер

Год издания:

ISBN:

9785961484250

Отзывы:

Комментировать

Рейтинг:

Поделись книгой с друзьями!

Помощь сайту: донат на оплату сервера

Краткое содержание книги "От джуна до сеньора: Как стать востребованным разработчиком"

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

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

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

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


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



Для кого

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

Читаем онлайн "От джуна до сеньора: Как стать востребованным разработчиком" (ознакомительный отрывок). [Страница - 3]

стр.
простоту его восприятия. Для авторов некоторых языков программирования удобство написания текста программы было большим приоритетом (да, Python, мы говорим про тебя). Авторы других языков, видимо, считали, что вы будете в восторге от обилия скобочек и палочек (да, Objective-C, мы в курсе, что ты в комнате).

Опираясь на guideline языка, вы должны следить, чтобы то, что вы пишете, соответствовало тому, что вы хотите сказать. Если вы заводите переменную sum, в которой храните текущую температуру в фаренгейтах, – поверьте, для вас уже разогревают котел в аду. Старайтесь соблюдать баланс в выразительности: переменная activeSessionsUsersWithGuestRole тоже вряд ли кого-то обрадует. Продуманные названия переменных, классов и функций облегчат жизнь не только вам, но и вашим коллегам.

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

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

Тезисы

■ Названия элементов программы должны быть продуманны и логичны.

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


Задание

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


История из жизни

К сожалению, тот пример, который я привел в тексте, – не вымысел. Я действительно находил переменную sum, которая хранила температуру в фаренгейтах. Учитывая тот факт, что код находился в цикле агрегации данных, я потратил немало времени, прежде чем понял, что sum не является суммой всех записей о температурных изменениях. «Спасибо» тебе, неизвестный разработчик. Это не самый страшный пример дурацкого названия переменной, и я готов дать руку на отсечение, что и сам именовал свои переменные довольно идиотским образом.

Повторное использование кода

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

Самое простое, что вы можете сделать, – скопировать код и перенести его в новое место (сделать Copy – Paste, как это называют в индустрии), заменив те части, которые того требуют. В этот момент вам следует остановиться, проверить КАЖДУЮ перенесенную строку и задать себе вопросы: будет ли эта строка работать в этой части проекта? Не нарушена ли логика кода? Все ли части скопированного кода имеют смысл в этом месте проекта? Исправили ли вы все комментарии, названия и связи в скопированном коде?

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

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

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

Оставить комментарий:


Ваш e-mail является приватным и не будет опубликован в комментарии.