День 1167. #Карьера
Советы о Продуктивности от Разработчиков для Разработчиков. Начало
Быть разработчиком непросто. Это умственно сложная работа, требующая множества софт и хард скилов и определенного набора личных качеств, чтобы продуктивно работать и не выгорать. Предлагаю вам советы от разработчиков о том, как они могут изменить свои привычки и добиться большего за меньшее время.
1. Знайте свою IDE
IDE предоставляет инструменты, необходимые для написания и тестирования ПО. Лучшие IDE предоставляют интерфейс со всеми необходимыми функциями, включая редактор кода, компилятор, отладчик и средства автоматизации.
«Узнайте, как использовать вашу IDE. Обратите внимание на рефакторинг, который она предоставляет, изучите кнопки, навигацию, горячие клавиши и другие её возможности». — Adam Skinner
2. Изучите командную строку
Интерфейс командной строки (CLI) — это текстовый интерфейс, используемый для запуска программ, управления файлами и взаимодействия с компьютером. CLI позволяет пользователям взаимодействовать с системой или другими приложениями с помощью текстовых команд.
«Изучите команды CLI для поиска, замены и редактирования на лету». – Joseph
3. Никогда не спешите писать код
Разработчики спешат писать код, как только получают спецификации. Но на самом деле наспех написанный код, скорее всего, потребует рефакторинга или очистки.
«Обдумайте всё (и обсудите это с пользователем или клиентом, если возможно), прежде чем писать какой-либо код». – leob
«Мои старшие коллеги научили меня: сначала планируй. Спланируйте реализацию в своей голове. Чтобы записать окончательный вариант, требуется очень мало времени. Разобраться что надо сделать, - вот что требует умения и терпения». – Aman Jaiswal
«Когда я только начинал, мне всегда не терпелось погрузиться в код и потеряться в нем. Десятки ошибок спустя, я могу сказать, что стал немного мудрее». – Raphael Jambalos
4. Избегайте Золотого Молотка
Антипаттерн «золотой молоток» — это когнитивное искажение, которое включает в себя чрезмерную зависимость от знакомых инструментов, языков и платформ. Такой подход ограничивает ваш потенциал в учёбе и приобретении опыта, а также снижает качество вашей работы. Нет универсального размера, который подошёл бы всем.
«Избегай золотого молотка. Нет одного способа сделать что-то. Нужно научиться придумывать варианты, рассматривать их плюсы и минусы и выбирать тот, который сработает в конкретной ситуации». – Melvyn Sopacua
5. Просматривайте свои коммиты
Обзоры кода имеют много преимуществ: она помогает разработчикам получать своевременную обратную связь, выявлять ошибки и неудачные решения, а также учиться у коллег-разработчиков. Проверка своего кода перед коммитом позволит вам найти некоторые очевидные ошибки на самой ранней стадии.
«Всегда просматривайте свои коммиты, прежде чем отправлять их, вы будете поражены тем, сколько ошибок вы поймаете сами, прежде чем код попадёт на глаза другим людям. Лучше потратить 10 минут своего времени, чем час работы коллеги». – Victor A. Barzana
6. Изучайте узкоспециализированные вещи
Существует большой спор о том, должны ли разработчики специализироваться. С одной стороны, чем шире ваши знания, тем больше возможностей вам будет доступно. С другой стороны, вы сильно рискуете стать «мастером на все руки, но не профессионалом ни в чем», страдать от синдрома самозванца и выгорания.
«Не пытайтесь выучить «всё», это пустая трата времени. Изучите основы, затем один или два языка и фреймворка, и всё — не прыгайте на каждую новую игрушку, о которой все говорят». – leob
Продолжение следует…
Источник: https://dev.to/actitime/20-productivity-tips-from-developers-to-developers-3bnc
Советы о Продуктивности от Разработчиков для Разработчиков. Начало
Быть разработчиком непросто. Это умственно сложная работа, требующая множества софт и хард скилов и определенного набора личных качеств, чтобы продуктивно работать и не выгорать. Предлагаю вам советы от разработчиков о том, как они могут изменить свои привычки и добиться большего за меньшее время.
1. Знайте свою IDE
IDE предоставляет инструменты, необходимые для написания и тестирования ПО. Лучшие IDE предоставляют интерфейс со всеми необходимыми функциями, включая редактор кода, компилятор, отладчик и средства автоматизации.
«Узнайте, как использовать вашу IDE. Обратите внимание на рефакторинг, который она предоставляет, изучите кнопки, навигацию, горячие клавиши и другие её возможности». — Adam Skinner
2. Изучите командную строку
Интерфейс командной строки (CLI) — это текстовый интерфейс, используемый для запуска программ, управления файлами и взаимодействия с компьютером. CLI позволяет пользователям взаимодействовать с системой или другими приложениями с помощью текстовых команд.
«Изучите команды CLI для поиска, замены и редактирования на лету». – Joseph
3. Никогда не спешите писать код
Разработчики спешат писать код, как только получают спецификации. Но на самом деле наспех написанный код, скорее всего, потребует рефакторинга или очистки.
«Обдумайте всё (и обсудите это с пользователем или клиентом, если возможно), прежде чем писать какой-либо код». – leob
«Мои старшие коллеги научили меня: сначала планируй. Спланируйте реализацию в своей голове. Чтобы записать окончательный вариант, требуется очень мало времени. Разобраться что надо сделать, - вот что требует умения и терпения». – Aman Jaiswal
«Когда я только начинал, мне всегда не терпелось погрузиться в код и потеряться в нем. Десятки ошибок спустя, я могу сказать, что стал немного мудрее». – Raphael Jambalos
4. Избегайте Золотого Молотка
Антипаттерн «золотой молоток» — это когнитивное искажение, которое включает в себя чрезмерную зависимость от знакомых инструментов, языков и платформ. Такой подход ограничивает ваш потенциал в учёбе и приобретении опыта, а также снижает качество вашей работы. Нет универсального размера, который подошёл бы всем.
«Избегай золотого молотка. Нет одного способа сделать что-то. Нужно научиться придумывать варианты, рассматривать их плюсы и минусы и выбирать тот, который сработает в конкретной ситуации». – Melvyn Sopacua
5. Просматривайте свои коммиты
Обзоры кода имеют много преимуществ: она помогает разработчикам получать своевременную обратную связь, выявлять ошибки и неудачные решения, а также учиться у коллег-разработчиков. Проверка своего кода перед коммитом позволит вам найти некоторые очевидные ошибки на самой ранней стадии.
«Всегда просматривайте свои коммиты, прежде чем отправлять их, вы будете поражены тем, сколько ошибок вы поймаете сами, прежде чем код попадёт на глаза другим людям. Лучше потратить 10 минут своего времени, чем час работы коллеги». – Victor A. Barzana
6. Изучайте узкоспециализированные вещи
Существует большой спор о том, должны ли разработчики специализироваться. С одной стороны, чем шире ваши знания, тем больше возможностей вам будет доступно. С другой стороны, вы сильно рискуете стать «мастером на все руки, но не профессионалом ни в чем», страдать от синдрома самозванца и выгорания.
«Не пытайтесь выучить «всё», это пустая трата времени. Изучите основы, затем один или два языка и фреймворка, и всё — не прыгайте на каждую новую игрушку, о которой все говорят». – leob
Продолжение следует…
Источник: https://dev.to/actitime/20-productivity-tips-from-developers-to-developers-3bnc
👍20
День 1168. #Карьера
Советы о Продуктивности от Разработчиков для Разработчиков. Продолжение
Начало
7. Создавайте сторонние проекты
Сторонние проекты бывают разных форм и преследуют множество различных целей, но у них есть важная общая черта: они дают кучу преимуществ. Сторонние проекты ускоряют ваше обучение, способствуют творчеству, расширяют портфолио, а иногда и служат источником дополнительного дохода.
«Практика в проектах или сторонних проектах — лучший способ изучить технологию» – Adrian Matei
8. Пишите читаемый код
Читаемый код — одно из важнейших качеств хорошего разработчика. Читаемый код экономит время и усилия разработчика, сокращая время отладки и сохраняя его удобным для сопровождения и простым для понимания.
«Пишите читаемый код, не комментируйте его, если код говорит сам за себя. Поэтому используйте чёткие имена переменных/методов». – Victor A. Barzana
«Пишите читаемый, а не сложный/причудливый код. Потом вы скажете себе за это спасибо». – Adrian Matei
9. Следите за временем
Разработчики должны отслеживать своё время по нескольким причинам. Прежде всего, отслеживание времени помогает оптимизировать свою работу, определять время пика продуктивности, планировать и расставлять приоритеты в своей рабочей нагрузке. Разработчики-фрилансеры зарабатывают больше, т.к. они могут использовать тайм-трекеры для оценки прибыльности проекта и выставления счетов своим клиентам.
«Разработчики часто чувствуют, что они недостаточно продуктивны. В большинстве случаев это неправда. Используйте трекер времени, чтобы записывать время, которое вы потратили на свои задачи, и документировать важные действия и вехи». – Jane
10. Используйте буферное время
Agile-команды измеряют несколько показателей продуктивности разработчиков, в том числе скорость команды — объем работы, которую команда может выполнить за один спринт. Чтобы понять свои личные пределы и ограничения рабочей нагрузки, вы можете рассчитать свою индивидуальную скорость, добавить к ней небольшие временные буферы при оценке рабочих действий и наслаждаться работой в более спокойном темпе.
«Постарайтесь оценить и отследить реальное количество времени, которое вы потратили на задачу. После того, как вы найдёте личную скорость, вы сможете контролировать давление, которое компания пытается оказать на вас. Например, если вы знаете, что выполните задачу за 3 часа, вы можете оценить её в 4 часа, и у вас будет время подумать и отдохнуть». – Ihor Klymenok
«Одна действительно важная вещь, в которой я хотел бы быть лучше, когда я получил свою первую работу, — это оценка времени, необходимого для того, чтобы что-то сделать. Не уверен, была ли это моя чрезмерная уверенность в своих способностях, наличие чёткого плана выполнения задачи у меня в голове (обычно мешают неожиданные ошибки) или и то, и другое. Но это заставляло меня обычно называть сроки меньше, чем на самом деле требовалось. Я разочаровывал и себя, и своих товарищей по команде, до тех пор, пока сеньор не помог мне с этим процессом. Если кратко, когда вас спрашивают, сколько времени потребуется для выполнения той или иной задачи, всегда добавляйте буферное время». – Anam.DevDes
11. Развивайте софт скилы
Написать хороший код недостаточно — разработчики также должны обладать хорошими нетехническими навыками, включая общение, работу в команде, управление временем, решение проблем, критическое мышление, терпение и настойчивость.
«В настоящее время рабочие места разработчиков перемещаются на удалённую работу, поэтому становится важно иметь отличные навыки совместной и командной работы. Навык публичных выступлений даст вам преимущество». – Atharva Shirdhankar
Продолжение следует…
Источник: https://dev.to/actitime/20-productivity-tips-from-developers-to-developers-3bnc
Советы о Продуктивности от Разработчиков для Разработчиков. Продолжение
Начало
7. Создавайте сторонние проекты
Сторонние проекты бывают разных форм и преследуют множество различных целей, но у них есть важная общая черта: они дают кучу преимуществ. Сторонние проекты ускоряют ваше обучение, способствуют творчеству, расширяют портфолио, а иногда и служат источником дополнительного дохода.
«Практика в проектах или сторонних проектах — лучший способ изучить технологию» – Adrian Matei
8. Пишите читаемый код
Читаемый код — одно из важнейших качеств хорошего разработчика. Читаемый код экономит время и усилия разработчика, сокращая время отладки и сохраняя его удобным для сопровождения и простым для понимания.
«Пишите читаемый код, не комментируйте его, если код говорит сам за себя. Поэтому используйте чёткие имена переменных/методов». – Victor A. Barzana
«Пишите читаемый, а не сложный/причудливый код. Потом вы скажете себе за это спасибо». – Adrian Matei
9. Следите за временем
Разработчики должны отслеживать своё время по нескольким причинам. Прежде всего, отслеживание времени помогает оптимизировать свою работу, определять время пика продуктивности, планировать и расставлять приоритеты в своей рабочей нагрузке. Разработчики-фрилансеры зарабатывают больше, т.к. они могут использовать тайм-трекеры для оценки прибыльности проекта и выставления счетов своим клиентам.
«Разработчики часто чувствуют, что они недостаточно продуктивны. В большинстве случаев это неправда. Используйте трекер времени, чтобы записывать время, которое вы потратили на свои задачи, и документировать важные действия и вехи». – Jane
10. Используйте буферное время
Agile-команды измеряют несколько показателей продуктивности разработчиков, в том числе скорость команды — объем работы, которую команда может выполнить за один спринт. Чтобы понять свои личные пределы и ограничения рабочей нагрузки, вы можете рассчитать свою индивидуальную скорость, добавить к ней небольшие временные буферы при оценке рабочих действий и наслаждаться работой в более спокойном темпе.
«Постарайтесь оценить и отследить реальное количество времени, которое вы потратили на задачу. После того, как вы найдёте личную скорость, вы сможете контролировать давление, которое компания пытается оказать на вас. Например, если вы знаете, что выполните задачу за 3 часа, вы можете оценить её в 4 часа, и у вас будет время подумать и отдохнуть». – Ihor Klymenok
«Одна действительно важная вещь, в которой я хотел бы быть лучше, когда я получил свою первую работу, — это оценка времени, необходимого для того, чтобы что-то сделать. Не уверен, была ли это моя чрезмерная уверенность в своих способностях, наличие чёткого плана выполнения задачи у меня в голове (обычно мешают неожиданные ошибки) или и то, и другое. Но это заставляло меня обычно называть сроки меньше, чем на самом деле требовалось. Я разочаровывал и себя, и своих товарищей по команде, до тех пор, пока сеньор не помог мне с этим процессом. Если кратко, когда вас спрашивают, сколько времени потребуется для выполнения той или иной задачи, всегда добавляйте буферное время». – Anam.DevDes
11. Развивайте софт скилы
Написать хороший код недостаточно — разработчики также должны обладать хорошими нетехническими навыками, включая общение, работу в команде, управление временем, решение проблем, критическое мышление, терпение и настойчивость.
«В настоящее время рабочие места разработчиков перемещаются на удалённую работу, поэтому становится важно иметь отличные навыки совместной и командной работы. Навык публичных выступлений даст вам преимущество». – Atharva Shirdhankar
Продолжение следует…
Источник: https://dev.to/actitime/20-productivity-tips-from-developers-to-developers-3bnc
👍9
#Оффтоп
В чате спрашивали не думаю ли я к каналу донатилку прикрутить. Так сейчас модно вроде. И вот наконец дошли руки. Не могу сказать, чтоб я прям сильно в донатах нуждался. И конечно, посты будут тут выходить в любом случае, пока мне это интересно. Но если вдруг, кому хочется поддержать канал, то буду премного благодарен: https://pay.cloudtips.ru/p/70df3b3b
В чате спрашивали не думаю ли я к каналу донатилку прикрутить. Так сейчас модно вроде. И вот наконец дошли руки. Не могу сказать, чтоб я прям сильно в донатах нуждался. И конечно, посты будут тут выходить в любом случае, пока мне это интересно. Но если вдруг, кому хочется поддержать канал, то буду премного благодарен: https://pay.cloudtips.ru/p/70df3b3b
👍15👎3
День 1169. #Карьера
Советы о Продуктивности от Разработчиков для Разработчиков. Продолжение
Начало 1-6
Продолжение 7-11
12. Автоматизируйте всё, что можете
В своей книге «The Passionate Programmer» Чад Фаулер рассказывает о построении блестящей карьеры инженера-программиста, и автоматизация — один из советов, которые он даёт. Многие аспекты работы разработчика можно автоматизировать. Вы можете внедрить инструменты автоматизации для тестирования, проверки кода, документации или для начала внимательно изучить свой редактор кода.
«Автоматизируйте повторяющиеся задачи; всё, что вы делаете, может быть автоматизировано». – DarkWiiPlayer
13. Планируйте свою продуктивность стратегически
Опытные разработчики используют инструменты повышения продуктивности и автоматизации, которые кажутся слишком сложными для младших разработчиков. Таким образом, последние часто ищут и применяют альтернативные инструменты, которые в итоге оказываются неэффективными. Слушайте своего наставника и изучайте инструменты, которые он советует. Кривая обучения не будет легкой, но ваши усилия в итоге окупятся.
«Выберите инструмент, который сначала может замедлить вас, но поможет позже. Гиперболизированный пример: сегодня можно добиться большего, если использовать блокнот вместо IDE. Но даже если вам понадобится месяц, чтобы изучить основы IDE, следующий месяц с повышенной продуктивностью компенсирует всё потерянное время». – DarkWiiPlayer
14. Инвестируйте в удобные вещи
Точно так же, как разработчики тратят время на изучение новых языков и инструментов, они также должны серьезно относиться к своим офисным принадлежностям. Если вы работаете в опенспейсе и шум вокруг вас отвлекает, не раздумывая, купите себе хорошие наушники! Если вы работаете из дома, вы также должны убедиться, что инструменты, которые вы используете для работы, удобны и надёжны.
«Инвестируйте в наушники с шумоподавлением. Независимо от того, работаете ли вы в офисе или дома, вам нужно сконцентрироваться, чтобы работать в потоке». – Stasy Barns
«Используйте удобный стол и инвестируйте в эргономичное кресло» – sudarshan
15. Остерегайтесь выгорания
Почти каждый разработчик сталкивался с выгоранием, возможно, не раз, поэтому большинство из вас знает о его катастрофических последствиях, в том числе о том, что люди увольняются с работы и даже бросают карьеру. Очень важно заботиться о себе каждый день, знать о симптомах выгорания и знать, как от него избавиться.
«Научитесь определять, когда вы выгорели. Перестаньте работать в течение дня, или вздремните или что-то в этом роде. Если вы этого не сделаете, вы зря потратите время и, возможно, создадите новые проблемы на завтра». – Adam Skinner
16. Ведите дневник
Ведение дневника — это гибкий и мощный инструмент, который может принимать разные формы и служить разным целям. Вы можете использовать его для излияния мыслей и эмоций, что снижает стресс и помогает справиться с трудностями. Можете создать целую панель инструментов с ежедневными списками, трекерами привычек и многим другим. Какую бы технику вы ни выбрали, она, скорее всего, окажется полезной для вашего психического здоровья и личностного роста.
«Я записываю свои привычки сна, еды, спорта и других активностей, отслеживаю продуктивность и настроение. Это может показаться пустой тратой времени, но после того, как у вас будут данные за несколько месяцев, вы увидите, что даёт вам энергию и удовлетворение жизнью, а что истощает их». – Jane
Окончание следует…
Источник: https://dev.to/actitime/20-productivity-tips-from-developers-to-developers-3bnc
Советы о Продуктивности от Разработчиков для Разработчиков. Продолжение
Начало 1-6
Продолжение 7-11
12. Автоматизируйте всё, что можете
В своей книге «The Passionate Programmer» Чад Фаулер рассказывает о построении блестящей карьеры инженера-программиста, и автоматизация — один из советов, которые он даёт. Многие аспекты работы разработчика можно автоматизировать. Вы можете внедрить инструменты автоматизации для тестирования, проверки кода, документации или для начала внимательно изучить свой редактор кода.
«Автоматизируйте повторяющиеся задачи; всё, что вы делаете, может быть автоматизировано». – DarkWiiPlayer
13. Планируйте свою продуктивность стратегически
Опытные разработчики используют инструменты повышения продуктивности и автоматизации, которые кажутся слишком сложными для младших разработчиков. Таким образом, последние часто ищут и применяют альтернативные инструменты, которые в итоге оказываются неэффективными. Слушайте своего наставника и изучайте инструменты, которые он советует. Кривая обучения не будет легкой, но ваши усилия в итоге окупятся.
«Выберите инструмент, который сначала может замедлить вас, но поможет позже. Гиперболизированный пример: сегодня можно добиться большего, если использовать блокнот вместо IDE. Но даже если вам понадобится месяц, чтобы изучить основы IDE, следующий месяц с повышенной продуктивностью компенсирует всё потерянное время». – DarkWiiPlayer
14. Инвестируйте в удобные вещи
Точно так же, как разработчики тратят время на изучение новых языков и инструментов, они также должны серьезно относиться к своим офисным принадлежностям. Если вы работаете в опенспейсе и шум вокруг вас отвлекает, не раздумывая, купите себе хорошие наушники! Если вы работаете из дома, вы также должны убедиться, что инструменты, которые вы используете для работы, удобны и надёжны.
«Инвестируйте в наушники с шумоподавлением. Независимо от того, работаете ли вы в офисе или дома, вам нужно сконцентрироваться, чтобы работать в потоке». – Stasy Barns
«Используйте удобный стол и инвестируйте в эргономичное кресло» – sudarshan
15. Остерегайтесь выгорания
Почти каждый разработчик сталкивался с выгоранием, возможно, не раз, поэтому большинство из вас знает о его катастрофических последствиях, в том числе о том, что люди увольняются с работы и даже бросают карьеру. Очень важно заботиться о себе каждый день, знать о симптомах выгорания и знать, как от него избавиться.
«Научитесь определять, когда вы выгорели. Перестаньте работать в течение дня, или вздремните или что-то в этом роде. Если вы этого не сделаете, вы зря потратите время и, возможно, создадите новые проблемы на завтра». – Adam Skinner
16. Ведите дневник
Ведение дневника — это гибкий и мощный инструмент, который может принимать разные формы и служить разным целям. Вы можете использовать его для излияния мыслей и эмоций, что снижает стресс и помогает справиться с трудностями. Можете создать целую панель инструментов с ежедневными списками, трекерами привычек и многим другим. Какую бы технику вы ни выбрали, она, скорее всего, окажется полезной для вашего психического здоровья и личностного роста.
«Я записываю свои привычки сна, еды, спорта и других активностей, отслеживаю продуктивность и настроение. Это может показаться пустой тратой времени, но после того, как у вас будут данные за несколько месяцев, вы увидите, что даёт вам энергию и удовлетворение жизнью, а что истощает их». – Jane
Окончание следует…
Источник: https://dev.to/actitime/20-productivity-tips-from-developers-to-developers-3bnc
👍13
День 1170. #Карьера
Советы о Продуктивности от Разработчиков для Разработчиков. Окончание
Начало 1-6
Продолжение 7-11
Продолжение 11-16
17. Делайте перерывы
Наш мозг менее продуктивен без отдыха, и это особенно верно для работников умственного труда. «Наш мозг похож на губку», — говорит доктор Би, психолог. - «Она может впитать конечное количество воды до того, как насытится, а затем должна немного подсохнуть». Поэтому не забывайте планировать время для отдыха и расслабления.
«Даже если вы работаете по 12 часов в день, вы, вероятно, продуктивны всего около трёх часов. Что вам действительно нужно, так это 4 часа упорной работы с регулярными перерывами. Делайте небольшой перерыв после работы в течение 45-60 минут». – Sachin N
См. также «помидорный график»
18. Ведите ежедневный учёт достижений
Дневник разработки - это эффективный инструмент для отслеживания вашего роста, карьерных целей и прогресса. Самым большим его преимуществом является то, что вы можете наметить стратегию развития своей карьеры и записывать достижения. У вас будут не только веские причины праздновать свой успех, но вы также сможете полагаться на эти записи, чтобы добиться продвижения, повышения зарплаты или даже лучшей работы.
«Записывайте то, что вы сделали каждый день перед сном». – Sachin N
19. Не бойтесь ошибаться
Многие разработчики, особенно младшие, считают себя неспособными выполнять свою работу, недооценивают свои возможности и боятся ошибиться. Важно каждый день напоминать себе, что ошибки — важная составляющая процесса обучения и в них нет ничего плохого. Ошибки также означают, что вы делаете всё возможное. Потому что не ошибаются только те, кто ничего не делает.
«Младшие разработчики, не могут писать (тем более понимать) сложные шаблоны кода и синтаксис, и это нормально. Их решение проблемы не будет таким элегантным и эффективным, как у разработчика с 20-летним стажем, и это нормально. Главное – учиться на ошибках и расти». – Dan Walsh
«Ошибки будут случаться. Они не определяют вашу уровень или компетентность, однако заставляют вас чувствовать себя хуже, когда случаются в вашем коде. Не корите себя, признайте ошибки, проанализируйте их (попросите помощи у старших, если вы застряли) и учитесь». – Melvyn Sopacua
Подробнее о том, как относиться к своим ошибкам
20. Не забывайте про документацию
Документация создается для информирования пользователей о продукте или ПО, которое она описывает. Звучит очевидно, но большинство из нас, включая разработчиков, склонны использовать вещь или ПО сразу же: мы думаем, что можем посмотреть на интерфейс и понять, как всё работает. Но разработчикам важно читать документацию и обращаться к официальным источникам.
«Так постоянно делают все программисты, включая меня: мы пропускаем чтение документации и пытаемся работать с новой технологией самостоятельно. Мы просто переходим в пользовательский интерфейс или API и начинаем его использовать.
Однако, как говорится «вы можете сэкономить много часов отладки, если потратите 10 минут на чтение документации». Если вы не читаете документацию, возможно, вы черпаете информацию из ненадёжных или устаревших источников (да, ответы на Stackoverflow тоже устаревают). Если документация доступна, почему бы просто не прочитать её?
Это не значит, что нельзя получать информацию из руководств или видеоуроков. Но следите за тем, что сказано в официальной документации». – Rajkumar Thangavel
Источник: https://dev.to/actitime/20-productivity-tips-from-developers-to-developers-3bnc
Советы о Продуктивности от Разработчиков для Разработчиков. Окончание
Начало 1-6
Продолжение 7-11
Продолжение 11-16
17. Делайте перерывы
Наш мозг менее продуктивен без отдыха, и это особенно верно для работников умственного труда. «Наш мозг похож на губку», — говорит доктор Би, психолог. - «Она может впитать конечное количество воды до того, как насытится, а затем должна немного подсохнуть». Поэтому не забывайте планировать время для отдыха и расслабления.
«Даже если вы работаете по 12 часов в день, вы, вероятно, продуктивны всего около трёх часов. Что вам действительно нужно, так это 4 часа упорной работы с регулярными перерывами. Делайте небольшой перерыв после работы в течение 45-60 минут». – Sachin N
См. также «помидорный график»
18. Ведите ежедневный учёт достижений
Дневник разработки - это эффективный инструмент для отслеживания вашего роста, карьерных целей и прогресса. Самым большим его преимуществом является то, что вы можете наметить стратегию развития своей карьеры и записывать достижения. У вас будут не только веские причины праздновать свой успех, но вы также сможете полагаться на эти записи, чтобы добиться продвижения, повышения зарплаты или даже лучшей работы.
«Записывайте то, что вы сделали каждый день перед сном». – Sachin N
19. Не бойтесь ошибаться
Многие разработчики, особенно младшие, считают себя неспособными выполнять свою работу, недооценивают свои возможности и боятся ошибиться. Важно каждый день напоминать себе, что ошибки — важная составляющая процесса обучения и в них нет ничего плохого. Ошибки также означают, что вы делаете всё возможное. Потому что не ошибаются только те, кто ничего не делает.
«Младшие разработчики, не могут писать (тем более понимать) сложные шаблоны кода и синтаксис, и это нормально. Их решение проблемы не будет таким элегантным и эффективным, как у разработчика с 20-летним стажем, и это нормально. Главное – учиться на ошибках и расти». – Dan Walsh
«Ошибки будут случаться. Они не определяют вашу уровень или компетентность, однако заставляют вас чувствовать себя хуже, когда случаются в вашем коде. Не корите себя, признайте ошибки, проанализируйте их (попросите помощи у старших, если вы застряли) и учитесь». – Melvyn Sopacua
Подробнее о том, как относиться к своим ошибкам
20. Не забывайте про документацию
Документация создается для информирования пользователей о продукте или ПО, которое она описывает. Звучит очевидно, но большинство из нас, включая разработчиков, склонны использовать вещь или ПО сразу же: мы думаем, что можем посмотреть на интерфейс и понять, как всё работает. Но разработчикам важно читать документацию и обращаться к официальным источникам.
«Так постоянно делают все программисты, включая меня: мы пропускаем чтение документации и пытаемся работать с новой технологией самостоятельно. Мы просто переходим в пользовательский интерфейс или API и начинаем его использовать.
Однако, как говорится «вы можете сэкономить много часов отладки, если потратите 10 минут на чтение документации». Если вы не читаете документацию, возможно, вы черпаете информацию из ненадёжных или устаревших источников (да, ответы на Stackoverflow тоже устаревают). Если документация доступна, почему бы просто не прочитать её?
Это не значит, что нельзя получать информацию из руководств или видеоуроков. Но следите за тем, что сказано в официальной документации». – Rajkumar Thangavel
Источник: https://dev.to/actitime/20-productivity-tips-from-developers-to-developers-3bnc
👍8
День 1171. #Карьера
Раз уж вся неделя прошла под тегом #Карьера, давайте и закончим её обсуждением на тему. Ниже привожу подборку видео от известных ИТ блогеров на общую тему «Будущее ИТ в России». Понимаю, что могу тут разжечь, но также считаю рассуждения в духе «мы тут #внеполитики, обсуждение только по теме» несусветной глупостью. Жить в пузыре и игнорировать происходящее вокруг невозможно.
Однако всё-таки важное пояснение:
Здесь все всё понимают, все в интернете и умеют гуглить. Мы тут собрались обсуждать .NET, наши карьеры и будущее. Кроме того, мы все делаем общее дело и стараемся помогать друг другу вне зависимости от политических предпочтений, вероисповедания и географического местоположения. Поэтому прошу вас общаться уважительно и придерживаться (хотя бы косвенно) ИТ темы.
Итак, вот вам 3 ролика о будущем ИТ в России, Украине и Беларуси.
Начну с, на мой взгляд, самого острого и мрачного. Сергей Немчинский «Что будет с IT в Украине, России и Беларуси? Программисты еще нужны?»
Второй ролик от АйТиБороды «Русская айтишка ВСЁ? / ЧТО БУДЕТ ДАЛЬШЕ В IT / НЕ позитивный прогноз.»
Ну и третий, как мне показалось, самый позитивный, от Романа Сакутина «Гибель IT в России. Программисты больше никому не нужны. Что будет дальше?»
Предлагаю обсудить. Что думаете? Про рынок, про отдельные компании, про себя (если не секрет).
Пожалуйста, ещё раз прочитайте пояснение выше.
Раз уж вся неделя прошла под тегом #Карьера, давайте и закончим её обсуждением на тему. Ниже привожу подборку видео от известных ИТ блогеров на общую тему «Будущее ИТ в России». Понимаю, что могу тут разжечь, но также считаю рассуждения в духе «мы тут #внеполитики, обсуждение только по теме» несусветной глупостью. Жить в пузыре и игнорировать происходящее вокруг невозможно.
Однако всё-таки важное пояснение:
Здесь все всё понимают, все в интернете и умеют гуглить. Мы тут собрались обсуждать .NET, наши карьеры и будущее. Кроме того, мы все делаем общее дело и стараемся помогать друг другу вне зависимости от политических предпочтений, вероисповедания и географического местоположения. Поэтому прошу вас общаться уважительно и придерживаться (хотя бы косвенно) ИТ темы.
Итак, вот вам 3 ролика о будущем ИТ в России, Украине и Беларуси.
Начну с, на мой взгляд, самого острого и мрачного. Сергей Немчинский «Что будет с IT в Украине, России и Беларуси? Программисты еще нужны?»
Второй ролик от АйТиБороды «Русская айтишка ВСЁ? / ЧТО БУДЕТ ДАЛЬШЕ В IT / НЕ позитивный прогноз.»
Ну и третий, как мне показалось, самый позитивный, от Романа Сакутина «Гибель IT в России. Программисты больше никому не нужны. Что будет дальше?»
Предлагаю обсудить. Что думаете? Про рынок, про отдельные компании, про себя (если не секрет).
Пожалуйста, ещё раз прочитайте пояснение выше.
👍8
День 1173. #ЧтоНовенького
Релиз-кандидат .NET MAUI
Выпущен релиз-кандидат .NET Multi-platform App UI (.NET MAUI). Теперь Microsoft поддерживает .NET MAUI для ваших производственных приложений.
Чтобы приобрести .NET MAUI RC1, установите или обновите Visual Studio 2022 до версии 17.2 Preview 3. В установщике убедитесь, что .NET MAUI (preview) отмечен в разделе Mobile Development with .NET workload (Разработка мобильных приложений с рабочей нагрузкой .NET).
Попробовать .NET MAUI можно на тестовом приложении .NET Podcasts, которое работает на Android, iOS, macOS и Windows и демонстрирует как нативный пользовательский интерфейс приложения, так и Blazor Hybrid.
Кроме того, доступно руководство по началу работы с .NET MAUI, где вы создадите приложение от начала до конца и интегрируете нативные функции.
Поддержка Xamarin по-прежнему действует в течение 2 лет после первоначального выпуска, т.е. до ноября 2023 года.
Источник: https://devblogs.microsoft.com/dotnet/dotnet-maui-rc-1/
Релиз-кандидат .NET MAUI
Выпущен релиз-кандидат .NET Multi-platform App UI (.NET MAUI). Теперь Microsoft поддерживает .NET MAUI для ваших производственных приложений.
Чтобы приобрести .NET MAUI RC1, установите или обновите Visual Studio 2022 до версии 17.2 Preview 3. В установщике убедитесь, что .NET MAUI (preview) отмечен в разделе Mobile Development with .NET workload (Разработка мобильных приложений с рабочей нагрузкой .NET).
Попробовать .NET MAUI можно на тестовом приложении .NET Podcasts, которое работает на Android, iOS, macOS и Windows и демонстрирует как нативный пользовательский интерфейс приложения, так и Blazor Hybrid.
Кроме того, доступно руководство по началу работы с .NET MAUI, где вы создадите приложение от начала до конца и интегрируете нативные функции.
Поддержка Xamarin по-прежнему действует в течение 2 лет после первоначального выпуска, т.е. до ноября 2023 года.
Источник: https://devblogs.microsoft.com/dotnet/dotnet-maui-rc-1/
👍5
День 1174. #ЗаметкиНаПолях #AsyncTips
Неизменяемые множества
Задача: нужна структура данных, не рассчитанная на хранение дубликатов, которая не слишком часто изменяется и допускает безопасные обращения из нескольких потоков. Например, индекс слов из файла может быть хорошим кандидатом для применения множества.
Решение
Существует два типа неизменяемых множеств:
Рекомендую использовать несортированное множество, если только вы не уверены в том, что оно должно быть отсортированным. Это позволит использовать неизменяемое множество в большем количестве ситуаций.
Неизменяемые множества полезны, но заполнение большого неизменяемого множества может быть медленной операцией. У многих неизменяемых коллекций имеются специальные построители, которые могут использоваться для быстрого их построения в изменяемом виде с последующим преобразованием в неизменяемую коллекцию. Это относится ко многим неизменяемым коллекциям, но, на мой взгляд, они особенно полезны для неизменяемых множеств.
См. также:
- Неизменяемые стеки и очереди
- Неизменяемые списки
Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 9.
Неизменяемые множества
Задача: нужна структура данных, не рассчитанная на хранение дубликатов, которая не слишком часто изменяется и допускает безопасные обращения из нескольких потоков. Например, индекс слов из файла может быть хорошим кандидатом для применения множества.
Решение
Существует два типа неизменяемых множеств:
ImmutableHashSet<T> — коллекция уникальных элементов и ImmutableSortedSet<T> — отсортированная коллекция уникальных элементов. Эти типы из пространства имён System.Collections.Immutable обладают похожим интерфейсом:var hs = ImmutableHashSet<int>.Empty;Отсортированное множество допускает индексирование по аналогии со списком:
hs = hs.Add(13);
hs = hs.Add(7);
// Выводит "7" и "13" в непредсказуемом порядке
foreach (int item in hs)
Console.WriteLine(item);
hs = hs.Remove(7);
var shs = ImmutableSortedSet<int>.Empty;Несортированные и отсортированные множества обладают схожим быстродействием: O(log N) для добавления, удаления. Важное примечание: обращение по индексу в сортированном множестве также выполняется за время O(log N), а не O(1), как и у
shs = shs.Add(13);
shs = shs.Add(7);
// Выводит "7", затем "13"
foreach (int item in shs)
Console.WriteLine(item);
int smallest = shs[0]; // 7
shs = shs.Remove(7);
ImmutableList<T>. Это означает, что в данной ситуации действует та же рекомендация: используйте foreach вместо for там, где это возможно.Рекомендую использовать несортированное множество, если только вы не уверены в том, что оно должно быть отсортированным. Это позволит использовать неизменяемое множество в большем количестве ситуаций.
Неизменяемые множества полезны, но заполнение большого неизменяемого множества может быть медленной операцией. У многих неизменяемых коллекций имеются специальные построители, которые могут использоваться для быстрого их построения в изменяемом виде с последующим преобразованием в неизменяемую коллекцию. Это относится ко многим неизменяемым коллекциям, но, на мой взгляд, они особенно полезны для неизменяемых множеств.
См. также:
- Неизменяемые стеки и очереди
- Неизменяемые списки
Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 9.
👍2
День 1175. #Юмор
Сегодня порекомендую вам юморное видео «HR x IT» от makelove agency. Это пилотное видео из серии «Мы вас перезвоним», в котором ребята сталкивают лбами разных представителей айтишечки. И они сразу решили зайти с козырей. HR против разработчика. Их претензии друг другу и разбор самых распространённых мифов об их профессиях. Некоторые требования айтишников даже меня удивили)))
В комментариях на девушку HRа накинулись за грубость 18+, но лично мне показалось, она вполне соответствовала образу.
В общем, веселый дружеский срачик. Мне понравилось.
https://youtu.be/Yyp4VVPylLg
Сегодня порекомендую вам юморное видео «HR x IT» от makelove agency. Это пилотное видео из серии «Мы вас перезвоним», в котором ребята сталкивают лбами разных представителей айтишечки. И они сразу решили зайти с козырей. HR против разработчика. Их претензии друг другу и разбор самых распространённых мифов об их профессиях. Некоторые требования айтишников даже меня удивили)))
В комментариях на девушку HRа накинулись за грубость 18+, но лично мне показалось, она вполне соответствовала образу.
В общем, веселый дружеский срачик. Мне понравилось.
https://youtu.be/Yyp4VVPylLg
👍6
День 1176. #ЗаметкиНаПолях
GraphQL или REST API. Что Использовать? Начало
REST и GraphQL — это стандартные способы разработки серверных API. В последнее десятилетие REST API доминировали, и многие компании и разработчики активно используют его в своих проектах.
Но у REST есть некоторые ограничения, и есть другая доступная альтернатива — GraphQL.
GraphQL был разработан Facebook в 2012 году для внутреннего использования и обнародован в 2015 году. Это язык запросов для API и среда исполнения для выполнения этих запросов к вашим существующим данным. Цитата с официального сайта:
«GraphQL предоставляет полное и понятное описание данных в вашем API, дает клиентам возможность запрашивать именно то, что им нужно, и ничего больше, упрощает развитие API с течением времени и предоставляет мощные инструменты разработчика.»
Проблемы с REST API
1. Запрос нескольких конечных точек
2. Получение лишних данных
3. Неполная выборка и проблема n+1 запроса
4. Медленный отклик на меняющиеся требованиями клиента
5. Высокая связанность между внутренними контроллерами и внешними представлениями
Предположим, что нам нужно показать краткую информацию о пользователе: имя, должность и текст «о себе». С REST запрос будет GET по адресу /users/1. Проблема в том, что сервер возвращает фиксированную структуру данных с множеством ненужной информации. Например:
GraphQL позволяет отправить запрос только нужных данных, который будет выглядеть примерно так:
Источник: https://www.freecodecamp.org/news/graphql-vs-rest-api/
GraphQL или REST API. Что Использовать? Начало
REST и GraphQL — это стандартные способы разработки серверных API. В последнее десятилетие REST API доминировали, и многие компании и разработчики активно используют его в своих проектах.
Но у REST есть некоторые ограничения, и есть другая доступная альтернатива — GraphQL.
GraphQL был разработан Facebook в 2012 году для внутреннего использования и обнародован в 2015 году. Это язык запросов для API и среда исполнения для выполнения этих запросов к вашим существующим данным. Цитата с официального сайта:
«GraphQL предоставляет полное и понятное описание данных в вашем API, дает клиентам возможность запрашивать именно то, что им нужно, и ничего больше, упрощает развитие API с течением времени и предоставляет мощные инструменты разработчика.»
Проблемы с REST API
1. Запрос нескольких конечных точек
2. Получение лишних данных
3. Неполная выборка и проблема n+1 запроса
4. Медленный отклик на меняющиеся требованиями клиента
5. Высокая связанность между внутренними контроллерами и внешними представлениями
Предположим, что нам нужно показать краткую информацию о пользователе: имя, должность и текст «о себе». С REST запрос будет GET по адресу /users/1. Проблема в том, что сервер возвращает фиксированную структуру данных с множеством ненужной информации. Например:
{
"id": 1,
"name": "John Smith",
"username": "jsmith",
"email": "[email protected]",
"title": "Software Engineer",
"phone": "9876543210",
"about": "As a software engineer my daily routine revolves around writing cleancode, maintaining infrastructure, and building scalable software systems.",
"website": "https://www.jsmith.tech",
"gender": "MALE",
"city": "Denver",
"state": "Colorado",
"country": "US",
…
}
Это добавляет в каждый запрос дополнительные данные, которые не требуются клиенту, что увеличивает размер полезной нагрузки и влияет на общее время ответа на запрос. Ещё хуже, если данные выбираются из нескольких таблиц, даже если клиенту этого не нужно.GraphQL позволяет отправить запрос только нужных данных, который будет выглядеть примерно так:
{
user(id: 1){
name
title
about
}
}
Окончание следует…Источник: https://www.freecodecamp.org/news/graphql-vs-rest-api/
👍11
День 1177. #ЗаметкиНаПолях
GraphQL или REST API. Что Использовать? Окончание
Начало
Теперь предположим, что нам нужно отобразить в списке имена пользователей и их «опыт» на текущем месте работы. В REST, учитывая, что «опыт» - это таблица с внешним ключом
1) Создать структуру со всеми внешними связями таблицы
2) Делать несколько запросов на сервер:
С другой стороны, простой запрос GraphQL будет без проблем работать без каких-либо дополнительных изменений на стороне сервера. Запрос будет выглядеть примерно так:
Например, по прошествии времени в списке потребовалось выводить не опыт, а последнюю транзакцию пользователя. С REST нужно будет внести соответствующие изменения в представление, но также придётся изменить и контроллер (добавить метод), и путь. То есть изменение требований клиента сильно влияет на то, что должно быть возвращено сервером.
С GraphQL нам не нужно будет вносить какие-либо изменения на стороне сервера. Изменение внешнего запроса будет минимальным:
Итого
GraphQL имеет ряд преимуществ перед REST во многих областях. Первоначальная настройка GraphQL может занять больше времени, но существует множество скаффолдеров, которые облегчают эту работу. И даже если поначалу это займет больше времени, это даст вам преимущество в долгосрочной перспективе.
Источник: https://www.freecodecamp.org/news/graphql-vs-rest-api/
GraphQL или REST API. Что Использовать? Окончание
Начало
Теперь предположим, что нам нужно отобразить в списке имена пользователей и их «опыт» на текущем месте работы. В REST, учитывая, что «опыт» - это таблица с внешним ключом
user_id, есть три возможных варианта:1) Создать структуру со всеми внешними связями таблицы
users и получать все данные в неё. Но это приведёт к очень дорогостоящим запросам и возвращает много данных из всех внешних таблиц, которые в большинстве случаев не требуются.2) Делать несколько запросов на сервер:
GET /usersЭто пример неполной выборки, так как у одной конечной точки недостаточно данных. Но множественные сетевые вызовы замедляют процесс и влияют на работу пользователя. Кроме того, в случае списка неполная выборка усугубляется тем, что нам нужно сделать запрос опыта для каждого пользователя в списке, и мы сталкиваемся с проблемой n+1 запроса.
GET users/1/experience
GET /users3) Создать специальный контроллер, который возвращает структуру данных, соответствующую требованиям клиента на данный момент времени.
GET users/1/experience
GET users/2/experience
…
GET users/n/experience
GET /user-experienceЭто и делается в большинстве реальных случаев в REST API.
С другой стороны, простой запрос GraphQL будет без проблем работать без каких-либо дополнительных изменений на стороне сервера. Запрос будет выглядеть примерно так:
{
users{
name
experience{
organization
title
duration
}
}
}
Да, можно использовать REST, создавать контроллеры (методы) под требования клиента. Но есть большой недостаток. Мы сформировали тесную связь клиентского представления с внутренними контроллерами API, поэтому потребуется больше усилий, чтобы обрабатывать запросы клиентов. Пользовательский контроллер возвращает данные в зависимости от того, что хочет отобразить представление, поэтому, когда требования изменятся, придётся менять как представление, так и контроллер.Например, по прошествии времени в списке потребовалось выводить не опыт, а последнюю транзакцию пользователя. С REST нужно будет внести соответствующие изменения в представление, но также придётся изменить и контроллер (добавить метод), и путь. То есть изменение требований клиента сильно влияет на то, что должно быть возвращено сервером.
С GraphQL нам не нужно будет вносить какие-либо изменения на стороне сервера. Изменение внешнего запроса будет минимальным:
{
users{
name
transactions{
amount
type
}
}
}
Никакого рефакторинга серверного API, развертывания и тестирования — это означает экономию времени и усилий!Итого
GraphQL имеет ряд преимуществ перед REST во многих областях. Первоначальная настройка GraphQL может занять больше времени, но существует множество скаффолдеров, которые облегчают эту работу. И даже если поначалу это займет больше времени, это даст вам преимущество в долгосрочной перспективе.
Источник: https://www.freecodecamp.org/news/graphql-vs-rest-api/
👍13
День 1178. #Юмор
Вытащу на пятничную болталку очередной твит. Kim Maida предложила следующее задание:
«Расскажите, сколько вам лет в «годах разработчика» одним предложением, не называя фактической цифры.»
Вот некоторые ответы:
«Разработчики на jQuery не *настоящие* JavaScript разработчики»
«Поддержка IE6»
«Использовал картинки с четвертью круга для скругления углов таблиц»
«Моих нынешней и предыдущей профессий не существовало»
«Начинал в классическом ASP, когда он ещё был просто ASP»
«autoexec.bat»
«Javascript поддерживается только в Netscape Navigator»
«Пожалуйста, не используй телефон, у меня загружается огромный файл в 50Мб»
«Знаешь, через пару лет эти двузначные года станут реальной проблемой для наших систем.»
«Не используй mov, просто сделай XOR регистра с самим собой, это сэкономит память»
«Через несколько лет после того, как я начал программировать, я перешёл с кассет на флоппи-диски. Они намного быстрее!»
«Писал программы с помощью карандаша и бумаги, а затем создавал перфокарты и отправлял их в университет. Если программа компилировалась и запускалась, я получал результат примерно через неделю.»
Добавлю от себя:
«Самые современные компьютеры на корпусе, помимо кнопки включения, имели кнопки Reset и Turbo»
Оставляйте ваши варианты в комментариях.
Источник: https://twitter.com/KimMaida/status/1514652490683367438
Вытащу на пятничную болталку очередной твит. Kim Maida предложила следующее задание:
«Расскажите, сколько вам лет в «годах разработчика» одним предложением, не называя фактической цифры.»
Вот некоторые ответы:
«Разработчики на jQuery не *настоящие* JavaScript разработчики»
«Поддержка IE6»
«Использовал картинки с четвертью круга для скругления углов таблиц»
«Моих нынешней и предыдущей профессий не существовало»
«Начинал в классическом ASP, когда он ещё был просто ASP»
«autoexec.bat»
«Javascript поддерживается только в Netscape Navigator»
«Пожалуйста, не используй телефон, у меня загружается огромный файл в 50Мб»
«Знаешь, через пару лет эти двузначные года станут реальной проблемой для наших систем.»
«Не используй mov, просто сделай XOR регистра с самим собой, это сэкономит память»
«Через несколько лет после того, как я начал программировать, я перешёл с кассет на флоппи-диски. Они намного быстрее!»
«Писал программы с помощью карандаша и бумаги, а затем создавал перфокарты и отправлял их в университет. Если программа компилировалась и запускалась, я получал результат примерно через неделю.»
Добавлю от себя:
«Самые современные компьютеры на корпусе, помимо кнопки включения, имели кнопки Reset и Turbo»
Оставляйте ваши варианты в комментариях.
Источник: https://twitter.com/KimMaida/status/1514652490683367438
👍13
День 1179. #ЗаметкиНаПолях
Выделяем Подмассивы. Начало
Сегодня рассмотрим, различные способы выделения подмассива в C#.
Подмассив обычно определяется начальным индексом и количеством элементов, включаемых в него. В общем случае существует два логических способа это сделать:
- Создать новый массив и добавить к нему необходимые элементы.
- Создать оболочку вокруг массива, которая может содержать указатели на определенные элементы внутри массива без создания нового.
Допустим, у нас есть массив строк:
В LINQ есть методы
2. Использование метода Copy()
Тот же сценарий, но помощью метода массива
3. Оператор диапазона (x..y) в C# 8.0+
Начиная с C#8 появился новый оператор диапазона, который сделал выделение подмассива синтаксически очень простым. Он позволяет выделить элементы между индексом «x» и индексом «y», не включая элемент с индексом «y»:
Окончание следует…
Источник: https://code-maze.com/csharp-array-slicing/
Выделяем Подмассивы. Начало
Сегодня рассмотрим, различные способы выделения подмассива в C#.
Подмассив обычно определяется начальным индексом и количеством элементов, включаемых в него. В общем случае существует два логических способа это сделать:
- Создать новый массив и добавить к нему необходимые элементы.
- Создать оболочку вокруг массива, которая может содержать указатели на определенные элементы внутри массива без создания нового.
Допустим, у нас есть массив строк:
var posts = new string[] { "post1", "post2", "post3", "post4", "post5", "post6", "post7", "post8", "post9", "post10" };
1. Использование LINQВ LINQ есть методы
Skip() и Take():var sliced = posts.Skip(0).Take(5);Мы передаем количество элементов, которые хотим пропустить, методу
// Элементы с post1 до post5
Skip() - начальный индекс, и количество элементов, которые хотим включить, в метод Take(). Операция возвращает новый IEnumerable, который мы можем перечислить.2. Использование метода Copy()
Тот же сценарий, но помощью метода массива
Copy():var sliced = new string[5];Здесь мы инициализируем целевой массив, затем мы вызываем метод
Array.Copy(posts, 0, sliced, 0, 5);
Copy(), который принимает исходный массив, начальный индекс, целевой массив, начальный целевой индекс (ноль, потому что мы копируем в новый массив) и количество элементов, которые мы хотим скопировать. Метод возвращает новый массив, содержащий скопированные элементы.3. Оператор диапазона (x..y) в C# 8.0+
Начиная с C#8 появился новый оператор диапазона, который сделал выделение подмассива синтаксически очень простым. Он позволяет выделить элементы между индексом «x» и индексом «y», не включая элемент с индексом «y»:
var s1 = posts[2..]; // co 2го до концаОператор диапазона также выделяет новый массив.
var s2 = posts[..2]; // с начала до 1го
var s3 = posts[1..3]; // с 1го до 2го
var s4 = posts[..]; // весь массив
var s5 = posts[3..^0]; // с 3го до предпоследнего
Окончание следует…
Источник: https://code-maze.com/csharp-array-slicing/
👍21
День 1180. #ЗаметкиНаПолях
Выделяем Подмассивы. Окончание
Начало
Теперь рассмотрим второй способ.
Для него рассмотрим новый сценарий. Допустим, мы создаем модель машинного обучения для благотворительной организации, которая будет предсказывать, сделает ли человек донат, в зависимости от его возраста. У нас есть куча данных, которые мы хотим разбить на две секции: обучающие данные, на которых будет обучаться модель, и тестовые данные, по которым мы будем тестировать модель.
4. Использование ArraySegment<T>
То же самое можно сделать с помощью метода
Замечание: мы должны быть осторожны, потому что это не новый массив, это на самом деле переменная типа-значения, содержащая указатели на позиции элементов в массиве, поэтому любое изменение значений в сегменте массива будет отражаться в исходном массиве.
5. Использование ReadOnlySpan<T> и Span<T>
Код, использующий
Сравнение быстродействия
На массиве из 10 строк быстродействие выделения подмассива из 5 элементов и их перечисления. Общий вид методов:
Источник: https://code-maze.com/csharp-array-slicing/
Выделяем Подмассивы. Окончание
Начало
Теперь рассмотрим второй способ.
Для него рассмотрим новый сценарий. Допустим, мы создаем модель машинного обучения для благотворительной организации, которая будет предсказывать, сделает ли человек донат, в зависимости от его возраста. У нас есть куча данных, которые мы хотим разбить на две секции: обучающие данные, на которых будет обучаться модель, и тестовые данные, по которым мы будем тестировать модель.
var data = new (int, bool)[] {
(20, true),
(50, true),
(35, false),
(55, true),
(16, false)
};
Заметьте, что в примере у нас всего 5 элементов. В реальной же модели обучения их могут быть миллионы, поэтому выделять новый массив будет очень затратно.4. Использование ArraySegment<T>
var train = new ArraySegment<(int, bool)>(data, 0, 3);Мы инициализируем новый экземпляр
var test = new ArraySegment<(int, bool)>(data, 3, 2);
ArraySegment, передавая массив, который мы хотим разделить, начальный индекс и количество элементов. Это создает оболочку вокруг массива, которая ограничивает элементы между указанными позициями. Теперь мы можем выполнить итерацию по этому сегменту и прочитать его значения.То же самое можно сделать с помощью метода
ArraySegment<T>.Slice():var all = new ArraySegment<(int, bool)>(data);Мы создаем
var train = all.Slice(0, 3);
var test = all.Slice(3, 2);
ArraySegment, который охватывает весь массив, затем вызываем метод Slice(), который создает ещё один ArraySegment с указанными границами.Замечание: мы должны быть осторожны, потому что это не новый массив, это на самом деле переменная типа-значения, содержащая указатели на позиции элементов в массиве, поэтому любое изменение значений в сегменте массива будет отражаться в исходном массиве.
5. Использование ReadOnlySpan<T> и Span<T>
ReadOnlySpan<T> предоставляет оболочку, которая позволяет только чтение из массива:var train = new ReadOnlySpan<(int, bool)>(data, 0, 3);
var test = new ReadOnlySpan<(int, bool)>(data, 3, 2);
ReadOnlySpan очень похож на ArraySegment. Он принимает массив, начальный индекс и количество элементов. Мы можем перечислить его, но, если мы попытаемся изменить какой-либо элемент через экземпляр ReadOnlySpan, мы получим ошибку компиляции.Код, использующий
Span<T> и его поведение аналогичны коду с ArraySegment<T>. Их отличие в том, что Span<T> можно использовать не только для массивов. Кроме того, ArraySegment<T> реализует IEnumerable<T> таким образом позволяет вернуть результат как IEnumerable<T>, тогда как ReadOnlySpan<T> и Span<T> возвращают соответствующие типы, хотя оба имеют метод GetEnumerator(), поэтому их также можно перечислить через foreach.Сравнение быстродействия
На массиве из 10 строк быстродействие выделения подмассива из 5 элементов и их перечисления. Общий вид методов:
public int <Метод>()Результаты на картинке ниже.
{
// получение подмассива указанным методом
var slice = <подмассив>;
var cnt = 0;
foreach (var item in slice)
cnt++;
return cnt;
}
Источник: https://code-maze.com/csharp-array-slicing/
👍10
День 1181. #МоиИнструменты
Visual Studio 2022 Tweaks
Сегодня порекомендую вам расширение для Visual Studio 2022 от Мэдса Кристенсена Tweaks 2022. Оно содержит в себе множество мелких, но полезных улучшений (на основании предложений пользователей). Они упростят для вас те мелкие ненужные действия, которые нам приходится делать постоянно в повседневной работе. Подробное их описание ищите на странице расширения).
Стоит оговориться, что большинство из этого уже существует и это можно найти, покопавшись в настройках. Расширение позволяет сделать это быстро.
1. Общие
- Автоматическое сохранение документа, когда он теряет фокус. Также проект автоматически сохраняется при добавлении, удалении или переименовании файлов.
- Закрытие документа по
- Автоматический фокус на обозревателе решений после загрузки проекта (даже если он был скрыт).
- Пункт меню для очистки недавно открытых документов.
- Пункт всплывающего меню «Открыть сбоку» для файлов в обозревателе решений (открывает файл справа от текущего документа).
- Пункт всплывающего меню «Найти в обозревателе решений» для вкладок.
2. IDE
- Перезапуск VS в меню Файл (также возможно по
- Варианты запуска VS в безопасном режиме и в режиме презентации (доступны в выпадающем меню при правом клике на ярлыке VS).
- Отключение кнопок отладки
3. Сборка
- Выпадающий список уровня подробности сообщений сборки в окне Output.
- Сохранение решения при сборке.
- Удаление папок
- Отображение времени запуска и длительности сборки.
- Отображение актуальности файлов проекта (полезно знать, чтобы выяснить, почему проект пересобирается). Отображается даже на минимальном уровне подробностей в окне Output.
- Отображение порядка сборки проектов
4. Редактор
- Очистка кода при форматировании документа (
- Отмена копирования пустых строк. По умолчанию при нажатии
- Копирование без отступов (удаляет отступы у последующих строк, если первая скопирована без отступа).
- Форматирование при перемещении строк.
- Отмена зума по
- Возврат к стандартному зуму по
- Пункт «Настройки» во всплывающем меню документа, вызывающий настройки для языка документа.
- Пункт «Специальная вставка» во всплывающем меню документа.
- Возможность свернуть и скрыть несколько атрибутов.
- Выделение всей строки по
- Предупреждение при вставке больших объёмов текста.
Изменить все упомянутые настройки после установки расширения можно в меню Tools > Options > Environment > Tweaks 2022.
Visual Studio 2022 Tweaks
Сегодня порекомендую вам расширение для Visual Studio 2022 от Мэдса Кристенсена Tweaks 2022. Оно содержит в себе множество мелких, но полезных улучшений (на основании предложений пользователей). Они упростят для вас те мелкие ненужные действия, которые нам приходится делать постоянно в повседневной работе. Подробное их описание ищите на странице расширения).
Стоит оговориться, что большинство из этого уже существует и это можно найти, покопавшись в настройках. Расширение позволяет сделать это быстро.
1. Общие
- Автоматическое сохранение документа, когда он теряет фокус. Также проект автоматически сохраняется при добавлении, удалении или переименовании файлов.
- Закрытие документа по
Ctrl+W.- Автоматический фокус на обозревателе решений после загрузки проекта (даже если он был скрыт).
- Пункт меню для очистки недавно открытых документов.
- Пункт всплывающего меню «Открыть сбоку» для файлов в обозревателе решений (открывает файл справа от текущего документа).
- Пункт всплывающего меню «Найти в обозревателе решений» для вкладок.
2. IDE
- Перезапуск VS в меню Файл (также возможно по
Shift+Alt+F4).- Варианты запуска VS в безопасном режиме и в режиме презентации (доступны в выпадающем меню при правом клике на ярлыке VS).
- Отключение кнопок отладки
F10/F11 (ох, сколько раз я промахивался мимо F12).3. Сборка
- Выпадающий список уровня подробности сообщений сборки в окне Output.
- Сохранение решения при сборке.
- Удаление папок
bin и obj при очистке решения.- Отображение времени запуска и длительности сборки.
- Отображение актуальности файлов проекта (полезно знать, чтобы выяснить, почему проект пересобирается). Отображается даже на минимальном уровне подробностей в окне Output.
- Отображение порядка сборки проектов
4. Редактор
- Очистка кода при форматировании документа (
Ctrl+K,D).- Отмена копирования пустых строк. По умолчанию при нажатии
Ctrl+C, если ничего не выделено, копируется текущая строка. Теперь, если строка пустая, она не будет скопирована.- Копирование без отступов (удаляет отступы у последующих строк, если первая скопирована без отступа).
- Форматирование при перемещении строк.
Alt+стрелки помогают переместить строку вверх/вниз. Теперь будет добавляться нужный отступ.- Отмена зума по
Ctrl+колёсико мыши (из-за случайных срабатываний). Работает через Ctrl+Shift+колёсико мыши.- Возврат к стандартному зуму по
Ctrl+0 (стандартный зум устанавливается в настройках).- Пункт «Настройки» во всплывающем меню документа, вызывающий настройки для языка документа.
- Пункт «Специальная вставка» во всплывающем меню документа.
- Возможность свернуть и скрыть несколько атрибутов.
- Выделение всей строки по
Shift+Alt+E.- Предупреждение при вставке больших объёмов текста.
Изменить все упомянутые настройки после установки расширения можно в меню Tools > Options > Environment > Tweaks 2022.
👍8
День 1182. #Карьера
Как Разработчики Проваливаются
«Разработчики терпят неудачу по двум причинам: либо делают не так, либо делают не то».
Поразительно, что большинство разработчиков уделяют больше внимания первой части проблемы и забывают про вторую. Младшие программисты больше озабочены тем, как создать продукт. Есть техническая задача, и многим из нас нравится решать её, как головоломку. Но по мере накопления опыта вы обнаружите, что часто то, что вы создали, на самом деле не то, что хотел заказчик. А такой дефект труднее обнаружить, и часто дороже устранить.
Сделать не так
Определение намеренно расплывчато. Под неправильным в данном случае понимается любой технический дефект, в результате которого система не удовлетворяет потребностям пользователей. Критическая ошибка, архитектура не масштабируется, есть серьезные проблемы с производительностью, утечки памяти, может быть даже брешь в системе безопасности. Это все те вещи, о которых мы склонны думать, когда думаем о недостатках, дефектах или ошибках в приложениях.
Зачастую эти ошибки незначительны. Они могут быть обнаружены во время тестирования ещё до того, как их увидят конечные пользователи. В других случаях они могут быть довольно дорогими, и их нелегко исправить. Некоторые ошибки неизбежны, поэтому мы разрабатываем программные процессы таким образом, чтобы их можно было ожидать, обнаруживать и исправлять. Наша практика очень часто направлена на максимально быстрое обнаружение дефектов, поскольку мы знаем, что исправление дефекта сразу после его появления обходится на порядки дешевле, чем после его отправки в производственную среду. Предотвращение попадания дефектов в продукт — очень полезная деятельность для разработчиков ПО.
Ещё один способ создавать что-то неправильно связан с архитектурой или качеством. Некоторые решения, принятые на ранней стадии в отношении системной архитектуры, могут оказаться неправильными позже, когда они не позволят нам реагировать на запросы клиентов. Технический долг в виде костылей может иметь аналогичные последствия в перспективе. Хотя это и более коварно, чем выпуск видимых пользователями дефектов, это тоже примеры неправильного построения.
Сделать не то
Зачем мы делаем не то? Оказывается, общение – это трудно. Клиенты и пользователи не всегда чётко сообщают, чего они хотят. Мы не всегда хорошо слушаем или забываем. Или делаем то, что, как мы думаем, они хотят, или то, что хотели бы мы, вместо того, что требуется. Иногда это даже работает, но в большинстве случаев это пример того, как мы забываем, что мы не пользователи.
Часто пользователь хочет решить проблему, но, когда видит часть решения, это порождает новые идеи о том, как лучше её решить. Дело не в том, что они не знали, чего хотят, а в том, что итеративный процесс разработки решения выявил лучший подход. Худшее, что мы можем сделать как разработчики — это продавить посредственное решение, потому что мы не открыты для отличного, которое мы же нашли в процессе разработки. Поэтому важно часто обмениваться информацией, подтверждать наши предположения и позволять клиентам и заинтересованным сторонам реагировать на нашу работу по мере её продвижения. Будьте готовы изменить направление и быть открытыми для новых идей, чтобы максимизировать ценность предлагаемого вами решения.
Способность построить что-то правильно — это, как правило, вопрос технической компетентности. Как только вы достигнете определенного порога мастерства, вы будете уверены в своей способности сделать это. Создание правильной вещи требует дополнительных навыков и может зависеть от этой технической компетенции. Помимо правильного создания ПО, теперь вы должны иметь возможность быстро и эффективно общаться и изменять направление вашего решения по мере необходимости на основе актуальной информации. Только тогда вы можете быть уверены, что создаёте правильные вещи правильно.
Источник: https://weeklydevtips.com/episodes/how-developers-fail-ipx3u5cw?utm_sq=gg631te050
Автор оригинала: Steve "Ardalis" Smith
Как Разработчики Проваливаются
«Разработчики терпят неудачу по двум причинам: либо делают не так, либо делают не то».
Поразительно, что большинство разработчиков уделяют больше внимания первой части проблемы и забывают про вторую. Младшие программисты больше озабочены тем, как создать продукт. Есть техническая задача, и многим из нас нравится решать её, как головоломку. Но по мере накопления опыта вы обнаружите, что часто то, что вы создали, на самом деле не то, что хотел заказчик. А такой дефект труднее обнаружить, и часто дороже устранить.
Сделать не так
Определение намеренно расплывчато. Под неправильным в данном случае понимается любой технический дефект, в результате которого система не удовлетворяет потребностям пользователей. Критическая ошибка, архитектура не масштабируется, есть серьезные проблемы с производительностью, утечки памяти, может быть даже брешь в системе безопасности. Это все те вещи, о которых мы склонны думать, когда думаем о недостатках, дефектах или ошибках в приложениях.
Зачастую эти ошибки незначительны. Они могут быть обнаружены во время тестирования ещё до того, как их увидят конечные пользователи. В других случаях они могут быть довольно дорогими, и их нелегко исправить. Некоторые ошибки неизбежны, поэтому мы разрабатываем программные процессы таким образом, чтобы их можно было ожидать, обнаруживать и исправлять. Наша практика очень часто направлена на максимально быстрое обнаружение дефектов, поскольку мы знаем, что исправление дефекта сразу после его появления обходится на порядки дешевле, чем после его отправки в производственную среду. Предотвращение попадания дефектов в продукт — очень полезная деятельность для разработчиков ПО.
Ещё один способ создавать что-то неправильно связан с архитектурой или качеством. Некоторые решения, принятые на ранней стадии в отношении системной архитектуры, могут оказаться неправильными позже, когда они не позволят нам реагировать на запросы клиентов. Технический долг в виде костылей может иметь аналогичные последствия в перспективе. Хотя это и более коварно, чем выпуск видимых пользователями дефектов, это тоже примеры неправильного построения.
Сделать не то
Зачем мы делаем не то? Оказывается, общение – это трудно. Клиенты и пользователи не всегда чётко сообщают, чего они хотят. Мы не всегда хорошо слушаем или забываем. Или делаем то, что, как мы думаем, они хотят, или то, что хотели бы мы, вместо того, что требуется. Иногда это даже работает, но в большинстве случаев это пример того, как мы забываем, что мы не пользователи.
Часто пользователь хочет решить проблему, но, когда видит часть решения, это порождает новые идеи о том, как лучше её решить. Дело не в том, что они не знали, чего хотят, а в том, что итеративный процесс разработки решения выявил лучший подход. Худшее, что мы можем сделать как разработчики — это продавить посредственное решение, потому что мы не открыты для отличного, которое мы же нашли в процессе разработки. Поэтому важно часто обмениваться информацией, подтверждать наши предположения и позволять клиентам и заинтересованным сторонам реагировать на нашу работу по мере её продвижения. Будьте готовы изменить направление и быть открытыми для новых идей, чтобы максимизировать ценность предлагаемого вами решения.
Способность построить что-то правильно — это, как правило, вопрос технической компетентности. Как только вы достигнете определенного порога мастерства, вы будете уверены в своей способности сделать это. Создание правильной вещи требует дополнительных навыков и может зависеть от этой технической компетенции. Помимо правильного создания ПО, теперь вы должны иметь возможность быстро и эффективно общаться и изменять направление вашего решения по мере необходимости на основе актуальной информации. Только тогда вы можете быть уверены, что создаёте правильные вещи правильно.
Источник: https://weeklydevtips.com/episodes/how-developers-fail-ipx3u5cw?utm_sq=gg631te050
Автор оригинала: Steve "Ardalis" Smith
👍6
День 1183. #ЗаметкиНаПолях
Преимущества в Производительности Запечатанных Классов в .NET
По умолчанию классы не запечатаны. Это означает, что вы можете наследовать от них. Это неправильное поведение по умолчанию. Если класс не предназначен для наследования, он должен быть запечатан. Вы можете изменить это позже, при необходимости. Кроме того, это влияет на производительность. Когда класс запечатан, JIT может применить оптимизацию и немного повысить производительность приложения.
Вызов виртуальных методов
При вызове виртуальных методов фактический метод находится во время выполнения на основе фактического типа объекта. Каждый тип имеет таблицу виртуальных методов (vtable), которая содержит адреса всех виртуальных методов. Эти указатели используются во время выполнения для вызова соответствующих реализаций (динамическая диспетчеризация). Если JIT знает фактический тип объекта, он может пропустить виртуальную таблицу и напрямую вызвать правильный метод. Использование запечатанных типов помогает JIT в этом.
Приведение типов (is / as)
При приведении типов среда выполнения должна проверять тип объекта во время выполнения. При приведении к незапечатанному типу среда выполнения должна проверять наличие всех типов в иерархии. Однако при приведении к запечатанному типу среда выполнения должна проверять только тип объекта, поэтому оно выполняется быстрее.
Массивы
Массивы в .NET ковариантны. Это означает, что допустимо
Преобразование массивов в Span<T>
Вы можете преобразовать массивы в Span<T> или ReadOnlySpan<T>. По тем же причинам, что и в предыдущем разделе, JIT должен проверить тип объекта перед преобразованием массива в
Результаты теста быстродействия на картинке ниже.
Обнаружение недостижимого кода
При использовании запечатанного типа компилятор знает, что некоторые преобразования недействительны. Таким образом, он может сообщать о предупреждениях и ошибках. Это поможет уменьшить количество ошибок в вашем приложении, а также удалить недостижимый код.
Преимущества в Производительности Запечатанных Классов в .NET
По умолчанию классы не запечатаны. Это означает, что вы можете наследовать от них. Это неправильное поведение по умолчанию. Если класс не предназначен для наследования, он должен быть запечатан. Вы можете изменить это позже, при необходимости. Кроме того, это влияет на производительность. Когда класс запечатан, JIT может применить оптимизацию и немного повысить производительность приложения.
Вызов виртуальных методов
При вызове виртуальных методов фактический метод находится во время выполнения на основе фактического типа объекта. Каждый тип имеет таблицу виртуальных методов (vtable), которая содержит адреса всех виртуальных методов. Эти указатели используются во время выполнения для вызова соответствующих реализаций (динамическая диспетчеризация). Если JIT знает фактический тип объекта, он может пропустить виртуальную таблицу и напрямую вызвать правильный метод. Использование запечатанных типов помогает JIT в этом.
public class SealedBenchmarkЗдесь JIT не может знать тип
{
NonSealedType nonSealedType = new();
SealedType sealedType = new();
public void CallMethod_NonSealed()
=> nonSealedType.Method();
public void CallMethod_Sealed()
=> sealedType.Method();
}
nonSealedType. Он мог быть установлен в производный тип другим методом. Поэтому должен быть виртуальный вызов. В отличие от следующего кода:var instance = new NonSealedType();Здесь JIT точно знает тип, поэтому делает прямой вызов.
instance.Method();
Приведение типов (is / as)
При приведении типов среда выполнения должна проверять тип объекта во время выполнения. При приведении к незапечатанному типу среда выполнения должна проверять наличие всех типов в иерархии. Однако при приведении к запечатанному типу среда выполнения должна проверять только тип объекта, поэтому оно выполняется быстрее.
Массивы
Массивы в .NET ковариантны. Это означает, что допустимо
BaseType[] value = new DerivedType[1];Ковариантность приводит к снижению производительности. JIT должен проверять тип объекта перед назначением элемента в массив. При использовании запечатанных типов JIT может удалить проверку.
Преобразование массивов в Span<T>
Вы можете преобразовать массивы в Span<T> или ReadOnlySpan<T>. По тем же причинам, что и в предыдущем разделе, JIT должен проверить тип объекта перед преобразованием массива в
Span<T>. При использовании запечатанного типа можно избежать проверки.Результаты теста быстродействия на картинке ниже.
Обнаружение недостижимого кода
При использовании запечатанного типа компилятор знает, что некоторые преобразования недействительны. Таким образом, он может сообщать о предупреждениях и ошибках. Это поможет уменьшить количество ошибок в вашем приложении, а также удалить недостижимый код.
class SampleИсточник: https://www.meziantou.net/performance-benefits-of-sealed-class.htm
{
public void Foo(NonSealedType obj)
{
_ = obj as IMyInterface;
// ОК, т.к. производные класса
// могут реализовывать интерфейс
}
public void Foo(SealedType obj)
{
_ = obj is IMyInterface;
// ⚠️ Предупреждение CS0184
_ = obj as IMyInterface;
// ❌ Ошибка CS0039
}
}
👍19