День шестьсот девяносто второй. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
2. Ищите новые способы мышления и ментальные модели
Новые ментальные модели помогают мыслить вообще, но они также помогают лучше решать конкретные инженерные проблемы. Я придерживаюсь подхода just-in-time («всему своё время»). Я ищу новые подходы к проблеме, только когда зацикливаюсь на чём-то или когда обнаруживаю, что мои абстракции и решения не работают.
Например, недавно я боролся с доменом с большим количеством сложной бизнес-логики. Нормой были пограничные случаи, и мы хотели разработать систему, которая успешно с ними справляется. Именно тогда я прочитал о предметно-ориентированном проектировании. Я смог мгновенно применить его на практике. Впоследствии я лучше усвоил эти концепции. Я приобрёл новую ментальную модель создания корпоративного ПО.
Второй способ поиска новых ментальных моделей – читать статьи, появляющиеся на специализированных ресурсах (например, на Хабре). Там вы можете подчерпнуть интересные идеи. Однако они намного менее эффективны, чем описанная выше техника. Единственная причина заниматься этим на постоянной основе – набирать багаж навыков. Это позволяет знать о методах решения проблем, поэтому, когда я сталкиваюсь с проблемой, я могу вспомнить, что где-то читал про метод, который может помочь.
Последний способ - это изучение новых языков. Изучение нового диалекта или новых функций языка принесёт гораздо меньше пользы, чем, скажем, изучение языка, абсолютно непохожего на ваш. Каждый язык имеет свой словарный запас и грамматику, и позволяет по-иному смотреть на вещи.
Когда управление памятью находится под вашим контролем, вы понимаете, как работают указатели и выделение памяти. Когда C# абстрагирует это, вы цените снижение сложности. Когда в функциональном языке используются фильтры и проекции, вы понимаете, как можно заменить циклы for. И тогда вы замечаете, что в ООП некоторые вещи становятся проще. Нет одного волшебного инструмента, который подошёл бы ко всему. Но несмотря на это, вам не нужно менять ваш инструмент. Вы можете адаптировать передовой опыт для решения ваших проблем: например, использовать функциональные парадигмы в ООП. Принципы важнее, чем способы их выражения.
3. Стратегии повышения эффективности повседневной деятельности
Другая сторона медали - привычки, позволяющие хорошо мыслить. Это начинается с того, что вы в течение дня замечаете мелкие нюансы, которые вызывают у вас раздражение: неэффективные собрания, тормозящая программа, какая-нибудь рутинная задача, требующая от вас постоянно выполнять одни и те же действия. Затем вы придумываете стратегию, как этого избежать. Эти мелкие улучшения часто недооцениваются.
Вы решаете, что делать, а затем это входит у вас в привычку, и работает автоматически, освобождая мозг для обдумывания более интересных вещей. Я заметил несколько хороших привычек:
- Никогда не покидайте встречу, не приняв решения о дальнейших действиях. Решите, кто это сделает. Задачи без исполнителя редко выполняются.
- Документируйте решения, принятые в ходе разработки проекта.
- Выделите время (пусть это будет час в неделю) на настройку рабочей среды: обновите тормозящую утилиту или найдите ей замену, напишите макрос для рутинных действий, изучите горячие клавиши вашей IDE.
В будущем всё это позволит вам работать эффективнее и получать больше удовольствия от работы, а значит, затраченное время окупится.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
2. Ищите новые способы мышления и ментальные модели
Новые ментальные модели помогают мыслить вообще, но они также помогают лучше решать конкретные инженерные проблемы. Я придерживаюсь подхода just-in-time («всему своё время»). Я ищу новые подходы к проблеме, только когда зацикливаюсь на чём-то или когда обнаруживаю, что мои абстракции и решения не работают.
Например, недавно я боролся с доменом с большим количеством сложной бизнес-логики. Нормой были пограничные случаи, и мы хотели разработать систему, которая успешно с ними справляется. Именно тогда я прочитал о предметно-ориентированном проектировании. Я смог мгновенно применить его на практике. Впоследствии я лучше усвоил эти концепции. Я приобрёл новую ментальную модель создания корпоративного ПО.
Второй способ поиска новых ментальных моделей – читать статьи, появляющиеся на специализированных ресурсах (например, на Хабре). Там вы можете подчерпнуть интересные идеи. Однако они намного менее эффективны, чем описанная выше техника. Единственная причина заниматься этим на постоянной основе – набирать багаж навыков. Это позволяет знать о методах решения проблем, поэтому, когда я сталкиваюсь с проблемой, я могу вспомнить, что где-то читал про метод, который может помочь.
Последний способ - это изучение новых языков. Изучение нового диалекта или новых функций языка принесёт гораздо меньше пользы, чем, скажем, изучение языка, абсолютно непохожего на ваш. Каждый язык имеет свой словарный запас и грамматику, и позволяет по-иному смотреть на вещи.
Когда управление памятью находится под вашим контролем, вы понимаете, как работают указатели и выделение памяти. Когда C# абстрагирует это, вы цените снижение сложности. Когда в функциональном языке используются фильтры и проекции, вы понимаете, как можно заменить циклы for. И тогда вы замечаете, что в ООП некоторые вещи становятся проще. Нет одного волшебного инструмента, который подошёл бы ко всему. Но несмотря на это, вам не нужно менять ваш инструмент. Вы можете адаптировать передовой опыт для решения ваших проблем: например, использовать функциональные парадигмы в ООП. Принципы важнее, чем способы их выражения.
3. Стратегии повышения эффективности повседневной деятельности
Другая сторона медали - привычки, позволяющие хорошо мыслить. Это начинается с того, что вы в течение дня замечаете мелкие нюансы, которые вызывают у вас раздражение: неэффективные собрания, тормозящая программа, какая-нибудь рутинная задача, требующая от вас постоянно выполнять одни и те же действия. Затем вы придумываете стратегию, как этого избежать. Эти мелкие улучшения часто недооцениваются.
Вы решаете, что делать, а затем это входит у вас в привычку, и работает автоматически, освобождая мозг для обдумывания более интересных вещей. Я заметил несколько хороших привычек:
- Никогда не покидайте встречу, не приняв решения о дальнейших действиях. Решите, кто это сделает. Задачи без исполнителя редко выполняются.
- Документируйте решения, принятые в ходе разработки проекта.
- Выделите время (пусть это будет час в неделю) на настройку рабочей среды: обновите тормозящую утилиту или найдите ей замену, напишите макрос для рутинных действий, изучите горячие клавиши вашей IDE.
В будущем всё это позволит вам работать эффективнее и получать больше удовольствия от работы, а значит, затраченное время окупится.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
День шестьсот девяносто третий.
Nuget Пакеты, с Которыми Должен Быть Знаком Каждый .NET разработчик
1. xUnit и NUnit
Пакеты для юнит-тестов. Ничего необычного.
2. Moq и NSubstitute
Также для написания юнит-тестов – пакеты для создания фиктивных объектов в тестах.
3. Polly
Пакет для осуществления повторных попыток. Если у вас есть API, который может быть недоступен какое-то время, вам необходимо реализовать механизм повторения запросов, и Polly очень облегчит вам жизнь.
4. FluentAssertions
Снова вернёмся к юнит-тестам. Этот пакет позволяет создавать утверждения, вызывая цепочку методов, что делает выражение близким к обычному английскому языку, например:
Один из самых известных пакетов вообще и для теста производительности вашего кода в частности.
6. Serilog
Пакет для ведения журналов. Хотя, здесь можно назвать и ещё несколько похожих. Да и логгер по умолчанию от Майкрософт в последнее время переписан и усовершенствован.
7. Autofixture и Bogus
Эти пакеты позволяют вам сгенерировать тестовые данные для вашей базы данных на стадии разработки, либо для тестов. По умолчанию Autofixture создаст случайные данные, тогда как Bogus больше ориентирован на домен, и создаст данные близкие к реальности.
8. Scrutor
Пакет, расширяющий встроенные в .NET возможности внедрения зависимостей. Работает на соглашениях об именовании. Также позволяет декорировать внедрённую зависимость.
9. Automapper
Очень широко используемый пакет для связи объектов передачи данных (DTO) с объектами бизнес-логики.
10. Dapper и Entity Framework Core
Описание ORM пакетов потянет на целую книгу. Здесь стоит отметить, что эти 2 пакета можно использовать совместно. Например, Dapper для чтения из БД из-за его скорости, а EF Core – для записи, поскольку он хорошо справляется со сложными запросами на модификацию данных.
11. MediatR
Очень широко используемый пакет для реализации паттерна CQRS.
12. FluentValidation
Аналогично FluentAssertions предоставляет интерфейс цепочки методов для валидации объектов.
13. Swagger, Refit и RestSharp
Пакеты, позволяющие вам создавать клиентов для ваших REST API. Первые два больше полагаются на созданные вами объекты модели, последний предоставляет fluent-интерфейс.
14. Json.NET
Пакет от Newtonsoft для сериализации/десериализации в JSON. Майкрософт довольно неплохо усовершенствовали стандартную сериализацию, но Json.NET всё ещё превосходит её во многих аспектах.
Какие полезные NuGet пакеты вы используете? Оставляйте варианты в комментариях.
Источник: https://www.youtube.com/watch?v=qapJwFY9y2Y
Nuget Пакеты, с Которыми Должен Быть Знаком Каждый .NET разработчик
1. xUnit и NUnit
Пакеты для юнит-тестов. Ничего необычного.
2. Moq и NSubstitute
Также для написания юнит-тестов – пакеты для создания фиктивных объектов в тестах.
3. Polly
Пакет для осуществления повторных попыток. Если у вас есть API, который может быть недоступен какое-то время, вам необходимо реализовать механизм повторения запросов, и Polly очень облегчит вам жизнь.
4. FluentAssertions
Снова вернёмся к юнит-тестам. Этот пакет позволяет создавать утверждения, вызывая цепочку методов, что делает выражение близким к обычному английскому языку, например:
actual.Should().Contain("EF").And.HaveLength(6)…
5. BenchmarkDotNetОдин из самых известных пакетов вообще и для теста производительности вашего кода в частности.
6. Serilog
Пакет для ведения журналов. Хотя, здесь можно назвать и ещё несколько похожих. Да и логгер по умолчанию от Майкрософт в последнее время переписан и усовершенствован.
7. Autofixture и Bogus
Эти пакеты позволяют вам сгенерировать тестовые данные для вашей базы данных на стадии разработки, либо для тестов. По умолчанию Autofixture создаст случайные данные, тогда как Bogus больше ориентирован на домен, и создаст данные близкие к реальности.
8. Scrutor
Пакет, расширяющий встроенные в .NET возможности внедрения зависимостей. Работает на соглашениях об именовании. Также позволяет декорировать внедрённую зависимость.
9. Automapper
Очень широко используемый пакет для связи объектов передачи данных (DTO) с объектами бизнес-логики.
10. Dapper и Entity Framework Core
Описание ORM пакетов потянет на целую книгу. Здесь стоит отметить, что эти 2 пакета можно использовать совместно. Например, Dapper для чтения из БД из-за его скорости, а EF Core – для записи, поскольку он хорошо справляется со сложными запросами на модификацию данных.
11. MediatR
Очень широко используемый пакет для реализации паттерна CQRS.
12. FluentValidation
Аналогично FluentAssertions предоставляет интерфейс цепочки методов для валидации объектов.
13. Swagger, Refit и RestSharp
Пакеты, позволяющие вам создавать клиентов для ваших REST API. Первые два больше полагаются на созданные вами объекты модели, последний предоставляет fluent-интерфейс.
14. Json.NET
Пакет от Newtonsoft для сериализации/десериализации в JSON. Майкрософт довольно неплохо усовершенствовали стандартную сериализацию, но Json.NET всё ещё превосходит её во многих аспектах.
Какие полезные NuGet пакеты вы используете? Оставляйте варианты в комментариях.
Источник: https://www.youtube.com/watch?v=qapJwFY9y2Y
День шестьсот девяносто четвёртый.
Microsoft вводит бесплатное продление сертификатов
За последний год в Microsoft Azure добавили более 1000 новых возможностей. Быстрые темпы технологических изменений меняют и картину востребованных навыков в цифровом мире.
В Microsoft Learn создали набор тренингов и сертификатов, призванных помочь техническим специалистам оставаться в курсе событий. В 2021 году вводится несколько обновлений в программы сертификации.
Во-первых, сертифицированным специалистам предоставляется возможность продлить свои сертификаты Microsoft, изначально полученные путём сдачи экзаменов. В начале февраля 2021 года можно будет продлить срок действия сертификатов, пройдя бесплатный аттестационный тест в Microsoft Learn. Вместо того, чтобы пересдавать экзамены, тест можно пройти онлайн в удобное для вас время в течение шести месяцев до истечения срока действия вашего сертификата. После прохождения аттестации сертификация продлевается ещё на один год с текущей даты истечения срока действия. И это можно делать ежегодно. Для помощи в подготовке будет доступна бесплатная коллекция учебных модулей для каждого аттестационного теста.
Во-вторых, срок действия сертификатов теперь ограничен годом, начиная с даты получения. С июня 2021 г. это изменение вступит в силу для новых сертификатов. Переход на одногодичный срок действия сертификации зависит от того, насколько быстро меняются облачные технологии. Ежегодное обновление сертификатов подтверждает, что навыки и способность выполнять свои должностные обязанности актуальны на рынке.
Этот новый подход побуждает специалистов оставаться на волне актуальных технологий, но в то же время позволяет снизить нагрузку и затраты на поддержание активности вашей сертификации.
Источник: https://techcommunity.microsoft.com/t5/microsoft-learn-blog/stay-current-with-in-demand-skills-through-free-certification/ba-p/1489678
Microsoft вводит бесплатное продление сертификатов
За последний год в Microsoft Azure добавили более 1000 новых возможностей. Быстрые темпы технологических изменений меняют и картину востребованных навыков в цифровом мире.
В Microsoft Learn создали набор тренингов и сертификатов, призванных помочь техническим специалистам оставаться в курсе событий. В 2021 году вводится несколько обновлений в программы сертификации.
Во-первых, сертифицированным специалистам предоставляется возможность продлить свои сертификаты Microsoft, изначально полученные путём сдачи экзаменов. В начале февраля 2021 года можно будет продлить срок действия сертификатов, пройдя бесплатный аттестационный тест в Microsoft Learn. Вместо того, чтобы пересдавать экзамены, тест можно пройти онлайн в удобное для вас время в течение шести месяцев до истечения срока действия вашего сертификата. После прохождения аттестации сертификация продлевается ещё на один год с текущей даты истечения срока действия. И это можно делать ежегодно. Для помощи в подготовке будет доступна бесплатная коллекция учебных модулей для каждого аттестационного теста.
Во-вторых, срок действия сертификатов теперь ограничен годом, начиная с даты получения. С июня 2021 г. это изменение вступит в силу для новых сертификатов. Переход на одногодичный срок действия сертификации зависит от того, насколько быстро меняются облачные технологии. Ежегодное обновление сертификатов подтверждает, что навыки и способность выполнять свои должностные обязанности актуальны на рынке.
Этот новый подход побуждает специалистов оставаться на волне актуальных технологий, но в то же время позволяет снизить нагрузку и затраты на поддержание активности вашей сертификации.
Источник: https://techcommunity.microsoft.com/t5/microsoft-learn-blog/stay-current-with-in-demand-skills-through-free-certification/ba-p/1489678
День шестьсот девяносто пятый. #ЧтоНовенького
Критические Изменения в .NET5. WPF/Windows Forms
В заключительной части нашего обзора критических изменений в .NET 5 рассмотрим WPF/Windows Forms.
Предыдущие посты:
- BCL
- Исторические технологии
- ASP.NET Core. Начало
- ASP.NET Core. Продолжение
- ASP.NET Core. Окончание
Windows Forms, наряду с веб-формами, консолью и службами Windows, была одной из исходных сред приложений в первом .NET, вышедшем в 2002 году. Среда действует как тонкая оболочка для нативных элементов управления Windows. Это обеспечивает хорошую производительность, но довольно ограничено в настройках. Первое серьезное изменение в WinForms появилось в .NET 2.0 в 2005 году. Были заменены различные пользовательские элементы управления. С тех пор технология считается «завершённой». Единственные заметные изменения - это периодические обновления для поддержки мониторов с более высоким разрешением. Даже долго не решаемые ошибки обычно игнорировались, к большому раздражению разработчиков на WinForms.
Windows Presentation Foundation (WPF) была первой попыткой Microsoft создать полностью настраиваемую среду графического интерфейса. Несмотря на то, что он был выпущен всего через 4 года после WinForms, потребовалось время, чтобы стать общепринятым, поскольку шаблоны и концепции проектирования были более сложными. Производительность также может быть проблемой. Двумя ключевыми особенностями WPF были использование XAML для макета пользовательского интерфейса и шаблона MVVM для привязки данных. Как и WinForms, WPF долгие годы считался «законченным». Он даже не получил поддержки XAML-2009 после того, как спецификация XAML была выпущена в 2012 году. Такие проекты, как Avalonia, пытались сгладить недостатки WPF, например, позволяя привязку событий непосредственно к методу модели или модели представления.
1. Новый SDK
В .NET Core 3.x для WPF и WinForms требовался специальный SDK
2. Убран вывод в консоль
Хотя подавляющее большинство приложений WPF и WinForms не отображаются в консоли, на самом деле это не запрещено, это просто значение по умолчанию. Если нужно, вы можете установить для
3. Улучшенная обработка ошибок
В Windows Forms для .NET Core 3 большей части кода валидации просто не существовало. То есть переданный недопустимый аргумент мог вызвать исключение
4. Удалены элементы управления строки состояния
Одним из элементов управления, заменённых в .NET Framework 2, стал
Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-windows/
Критические Изменения в .NET5. WPF/Windows Forms
В заключительной части нашего обзора критических изменений в .NET 5 рассмотрим WPF/Windows Forms.
Предыдущие посты:
- BCL
- Исторические технологии
- ASP.NET Core. Начало
- ASP.NET Core. Продолжение
- ASP.NET Core. Окончание
Windows Forms, наряду с веб-формами, консолью и службами Windows, была одной из исходных сред приложений в первом .NET, вышедшем в 2002 году. Среда действует как тонкая оболочка для нативных элементов управления Windows. Это обеспечивает хорошую производительность, но довольно ограничено в настройках. Первое серьезное изменение в WinForms появилось в .NET 2.0 в 2005 году. Были заменены различные пользовательские элементы управления. С тех пор технология считается «завершённой». Единственные заметные изменения - это периодические обновления для поддержки мониторов с более высоким разрешением. Даже долго не решаемые ошибки обычно игнорировались, к большому раздражению разработчиков на WinForms.
Windows Presentation Foundation (WPF) была первой попыткой Microsoft создать полностью настраиваемую среду графического интерфейса. Несмотря на то, что он был выпущен всего через 4 года после WinForms, потребовалось время, чтобы стать общепринятым, поскольку шаблоны и концепции проектирования были более сложными. Производительность также может быть проблемой. Двумя ключевыми особенностями WPF были использование XAML для макета пользовательского интерфейса и шаблона MVVM для привязки данных. Как и WinForms, WPF долгие годы считался «законченным». Он даже не получил поддержки XAML-2009 после того, как спецификация XAML была выпущена в 2012 году. Такие проекты, как Avalonia, пытались сгладить недостатки WPF, например, позволяя привязку событий непосредственно к методу модели или модели представления.
1. Новый SDK
В .NET Core 3.x для WPF и WinForms требовался специальный SDK
Microsoft.NET.Sdk.WindowsDesktop. В .NET5 они используют Microsoft.NET.Sdk, как и любой другой проект. Однако целевой платформой должна быть net5.0-windows, а не просто net5.0.2. Убран вывод в консоль
Хотя подавляющее большинство приложений WPF и WinForms не отображаются в консоли, на самом деле это не запрещено, это просто значение по умолчанию. Если нужно, вы можете установить для
OutputType значение Exe вместо WinExe. В .NET5 параметр OutputType будет игнорироваться, если вы также не установите для DisableWinExeOutputInference значение true.3. Улучшенная обработка ошибок
В Windows Forms для .NET Core 3 большей части кода валидации просто не существовало. То есть переданный недопустимый аргумент мог вызвать исключение
NullReferenceException или просто вести себя неопределённым образом. В .NET5 будет выброшено более соответствующее исключение ArgumentException, ArgumentNullException или ArgumentOutOfRangeException. 4. Удалены элементы управления строки состояния
Одним из элементов управления, заменённых в .NET Framework 2, стал
StatusBar. Эквивалент в .NET 2 - StatusStrip. В Microsoft не объяснили, почему его нужно было удалить, возможно, затраты на обслуживание были слишком высоки для элемента, о существовании которого большинство людей даже не подозревает. StatusBar уже очень давно не отображается в панели инструментов дизайнера и полностью удалён в .NET5.Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-windows/
День шестьсот девяносто шестой. #Оффтоп
Доброй рабоче-нерабочей субботы, дорогие товарищи. На сегодня у меня для вас лёгенькое 3х-часовое интервью с 78-летним программистом от IT Бороды. https://www.youtube.com/watch?v=eqsg3Blzmdg Жёсткие диски бы делать из таких людей!
Доброй рабоче-нерабочей субботы, дорогие товарищи. На сегодня у меня для вас лёгенькое 3х-часовое интервью с 78-летним программистом от IT Бороды. https://www.youtube.com/watch?v=eqsg3Blzmdg Жёсткие диски бы делать из таких людей!
День шестьсот девяносто седьмой. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
71. Изобретайте Велосипеды
Просто используйте то, что уже существует. Глупо изобретать велосипед…
Сколько раз вы слышали эту фразу или её вариации? Каждому разработчику это приходится слышать довольно часто. Но почему? Почему изобретение велосипеда так осуждается? Потому что чаще всего существующий код является рабочим кодом. Он уже прошёл какой-то контроль качества и тщательное тестирование и успешно используется. Кроме того, время и усилия, вложенные в переписывание, вряд ли окупят выгоды перед использованием существующего продукта или кодовой базы. Стоит ли изобретать велосипед? Зачем? Когда?
Возможно, вы слышали о паттернах (#DesignPatterns) разработки или читали книги по разработке ПО. Эти книги могут быть скучными, независимо от того, насколько прекрасна содержащаяся в них информация. Точно так же, как просмотр фильма о парусном спорте сильно отличается от парусного спорта. Так и использование существующего кода намного скучнее разработки собственного ПО с нуля, его тестирования, взлома, починки и улучшения в процессе.
Изобретение велосипеда - это не просто упражнение в том, где разместить конструкции кода: это о том, как получить глубокие знания о внутренней работе различных компонентов, которые уже существуют. Вы знаете, как работают менеджеры памяти? Виртуальный пейджинг? Можете реализовать это самостоятельно? Как насчет двусвязных списков? Классов динамических массивов? ODBC-клиента? Можете написать графический пользовательский интерфейс, который бы работал так же, как один из популярных, известных вам? Можете создать свой собственный виджет для браузера? Знаете, как «на лету» выбрать между записью в постоянную БД или в БД в памяти?
Большинство разработчиков просто никогда сами не создавали такие типы основных программных реализаций и поэтому не имеют глубоких знаний о том, как они функционируют. Как следствие, все эти виды программного обеспечения рассматриваются как загадочные чёрные ящики, которые просто работают. Только поверхностного понимания недостаточно, чтобы выявить скрытые в глубине опасности. Незнание более глубоких вещей в разработке программного обеспечения ограничит вашу способность создавать блестящие продукты.
Изобретать велосипед и ошибаться гораздо важнее, чем делать всё правильно с первого раза. Уроки, извлечённые из проб и ошибок, содержат эмоциональную составляющую, которую невозможно получить при чтении технической книги!
Изученные факты и «книжные навыки» имеют решающее значение. Но для того, чтобы стать отличным программистом, приобретённый опыт не менее важен, чем полученные знания. Изобретать велосипед так же важно для образования и навыков разработчика, как тяжелая атлетика важна для бодибилдера.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Jason P. Sage
97 Вещей, Которые Должен Знать Каждый Программист
71. Изобретайте Велосипеды
Просто используйте то, что уже существует. Глупо изобретать велосипед…
Сколько раз вы слышали эту фразу или её вариации? Каждому разработчику это приходится слышать довольно часто. Но почему? Почему изобретение велосипеда так осуждается? Потому что чаще всего существующий код является рабочим кодом. Он уже прошёл какой-то контроль качества и тщательное тестирование и успешно используется. Кроме того, время и усилия, вложенные в переписывание, вряд ли окупят выгоды перед использованием существующего продукта или кодовой базы. Стоит ли изобретать велосипед? Зачем? Когда?
Возможно, вы слышали о паттернах (#DesignPatterns) разработки или читали книги по разработке ПО. Эти книги могут быть скучными, независимо от того, насколько прекрасна содержащаяся в них информация. Точно так же, как просмотр фильма о парусном спорте сильно отличается от парусного спорта. Так и использование существующего кода намного скучнее разработки собственного ПО с нуля, его тестирования, взлома, починки и улучшения в процессе.
Изобретение велосипеда - это не просто упражнение в том, где разместить конструкции кода: это о том, как получить глубокие знания о внутренней работе различных компонентов, которые уже существуют. Вы знаете, как работают менеджеры памяти? Виртуальный пейджинг? Можете реализовать это самостоятельно? Как насчет двусвязных списков? Классов динамических массивов? ODBC-клиента? Можете написать графический пользовательский интерфейс, который бы работал так же, как один из популярных, известных вам? Можете создать свой собственный виджет для браузера? Знаете, как «на лету» выбрать между записью в постоянную БД или в БД в памяти?
Большинство разработчиков просто никогда сами не создавали такие типы основных программных реализаций и поэтому не имеют глубоких знаний о том, как они функционируют. Как следствие, все эти виды программного обеспечения рассматриваются как загадочные чёрные ящики, которые просто работают. Только поверхностного понимания недостаточно, чтобы выявить скрытые в глубине опасности. Незнание более глубоких вещей в разработке программного обеспечения ограничит вашу способность создавать блестящие продукты.
Изобретать велосипед и ошибаться гораздо важнее, чем делать всё правильно с первого раза. Уроки, извлечённые из проб и ошибок, содержат эмоциональную составляющую, которую невозможно получить при чтении технической книги!
Изученные факты и «книжные навыки» имеют решающее значение. Но для того, чтобы стать отличным программистом, приобретённый опыт не менее важен, чем полученные знания. Изобретать велосипед так же важно для образования и навыков разработчика, как тяжелая атлетика важна для бодибилдера.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Jason P. Sage
День шестьсот девяносто восьмой. #MoreEffectiveCSharp
18. Предпочитайте Переопределения Обработчикам Событий
Многие классы .NET предоставляют два разных способа обработки событий. Вы можете подписать обработчик событий или переопределить виртуальную функцию базового класса. Внутри производных классов вы всегда должны переопределять виртуальную функцию. Ограничьте использование обработчиков событий реагированием на события в несвязанных объектах.
Рассмотрим код приложения WPF, где нужно реагировать на события нажатия мыши. Вы можете переопределить метод
Хорошо, но подписка на события зачем-то добавлена. Зачем?
1. Переопределения предназначены для производных классов. Но сторонние классы должны использовать механизм событий.
2. XAML поддерживает декларативную подписку на события. То есть дизайнер приложения в визуальном редакторе может выбрать действие при нажатии мыши, если оно доступно, и не добавлять работы программисту.
3. Это позволяет подписываться на события во время выполнения. Вы можете подключить разные обработчики событий, в зависимости от обстоятельств выполнения программы.
4. Возможно подключить несколько обработчиков к одному событию.
Итого
Когда у вас есть одна функция, которая обрабатывает одно событие в производном классе, переопределение является лучшим подходом. Это решение легче поддерживать, оно с большей вероятностью сохранит корректность с течением времени и более эффективно. Оставьте обработчики событий для других целей.
Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 18.
18. Предпочитайте Переопределения Обработчикам Событий
Многие классы .NET предоставляют два разных способа обработки событий. Вы можете подписать обработчик событий или переопределить виртуальную функцию базового класса. Внутри производных классов вы всегда должны переопределять виртуальную функцию. Ограничьте использование обработчиков событий реагированием на события в несвязанных объектах.
Рассмотрим код приложения WPF, где нужно реагировать на события нажатия мыши. Вы можете переопределить метод
OnMouseDown():public partial class MainWindow : WindowЛибо вы можете подписать обработчик события, что требует изменений как в файле C#, так и в файле XAML:
{
//…
protected override void OnMouseDown(MouseButtonEventArgs e)
{
DoMouseThings(e);
base.OnMouseDown(e);
}
}
<Window x:Class="WpfApp1.MainWindow"Следует предпочесть первое решение, и вот почему. При переопределении функции сначала вызывается ваш обработчик, а вызов функции базового класса отвечает за вызов любых обработчиков событий в цепочке. В некоторых редких случаях вам может потребоваться заменить поведение по умолчанию, чтобы другие обработчики не вызывались, но зачастую поведение по умолчанию – то, что вам нужно. Кроме того, в первом варианте нужно поддерживать изменение в одном месте, а во втором – в двух.
xmlns:local="clr-namespace:WpfApp1"
mc:Ignorable="d"
Title="MainWindow" Height="350" Width="525"
MouseDown="OnMouseDownHandler">
<Grid></Grid>
</Window>
public partial class MainWindow : Window
{
//…
private void OnMouseDownHandler(
object sender, MouseButtonEventArgs e)
{
DoMouseThings(e);
}
}
Хорошо, но подписка на события зачем-то добавлена. Зачем?
1. Переопределения предназначены для производных классов. Но сторонние классы должны использовать механизм событий.
2. XAML поддерживает декларативную подписку на события. То есть дизайнер приложения в визуальном редакторе может выбрать действие при нажатии мыши, если оно доступно, и не добавлять работы программисту.
3. Это позволяет подписываться на события во время выполнения. Вы можете подключить разные обработчики событий, в зависимости от обстоятельств выполнения программы.
4. Возможно подключить несколько обработчиков к одному событию.
Итого
Когда у вас есть одна функция, которая обрабатывает одно событие в производном классе, переопределение является лучшим подходом. Это решение легче поддерживать, оно с большей вероятностью сохранит корректность с течением времени и более эффективно. Оставьте обработчики событий для других целей.
Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 18.
День шестьсот девяносто девятый. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
4. Следите за скоростью
Я заметил, что более медленный темп даёт прирост моей производительности. Хотите сделать больше? Не торопитесь. Вот что я имею в виду.
Я заметил, что люди спешат решать проблемы. Это может быть что-то, что они делали раньше, или что-то, на что у нас есть шаблон решения. Приятно щёлкать задачи, как орешки. Я тоже так делал раньше. Однако есть очень ограниченное количество случаев, когда это имеет смысл.
Каждый раз, когда я работаю над чем-то новым, я нахожу время, чтобы узнать кое-что о системе, с которой я работаю, и вещах, тесно связанных с ней. Если она слишком большая, я стараюсь учиться как можно больше. Каждый раз, когда я возвращаюсь к системе, я стремлюсь узнать больше.
Когда вы не торопитесь, у вас есть шанс поэкспериментировать, поучиться и обдумать логику. Значит останется достаточно времени, чтобы всё сделать. В условиях постоянной спешки сроки горят, и всё ваше внимание сосредоточено на завершении задачи. Защищать свой темп - значит не позволять дедлайнам овладевать вами. Часто для этого достаточно просто поговорить с вашим начальством.
Неторопливость может со стороны показаться бездельничаньем, но умение отстоять возможность работать в своём темпе - это суперсила. Это долгосрочное вложение в собственное развитие за счет краткосрочной эффективности. Когда я тороплюсь завершить задачу, мне гораздо труднее обнаруживать и исправлять ошибки. Я не трачу время на обдумывание правильных логических конструкций, а это значит, что мои предположения могут не соответствовать существующему коду, и именно в этом несоответствии кроется большинство ошибок. Я отстаиваю возможность работы в своём темпе, поэтому я могу выделить время, чтобы уделить больше внимания обучению, а не исполнению.
Один из моих любимых вариантов использования времени - экспериментирование. Иногда я обнаруживаю ошибку, которая не имеет для меня никакого смысла. Я понимаю, что запутался, но при этом нахожу ответ на Stack Overflow и продолжаю работу. Однако меня беспокоит то, что я не понял причину появления ошибки. Stack Overflow дал ответ, но не объяснение, что было не так в моём понимании логики работы программы. Чтобы укрепить свое понимание, мне нужно поэкспериментировать.
Если у меня нет свободного времени, мне некогда экспериментировать, а значит, я должен забыть об этой ошибке. И напротив, если есть возможность провести пару экспериментов, можно точно выяснить, чего я не понимал. Я люблю такие моменты, когда я узнаю что-то новое о системе. В следующий раз это сделает меня намного эффективнее.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
4. Следите за скоростью
Я заметил, что более медленный темп даёт прирост моей производительности. Хотите сделать больше? Не торопитесь. Вот что я имею в виду.
Я заметил, что люди спешат решать проблемы. Это может быть что-то, что они делали раньше, или что-то, на что у нас есть шаблон решения. Приятно щёлкать задачи, как орешки. Я тоже так делал раньше. Однако есть очень ограниченное количество случаев, когда это имеет смысл.
Каждый раз, когда я работаю над чем-то новым, я нахожу время, чтобы узнать кое-что о системе, с которой я работаю, и вещах, тесно связанных с ней. Если она слишком большая, я стараюсь учиться как можно больше. Каждый раз, когда я возвращаюсь к системе, я стремлюсь узнать больше.
Когда вы не торопитесь, у вас есть шанс поэкспериментировать, поучиться и обдумать логику. Значит останется достаточно времени, чтобы всё сделать. В условиях постоянной спешки сроки горят, и всё ваше внимание сосредоточено на завершении задачи. Защищать свой темп - значит не позволять дедлайнам овладевать вами. Часто для этого достаточно просто поговорить с вашим начальством.
Неторопливость может со стороны показаться бездельничаньем, но умение отстоять возможность работать в своём темпе - это суперсила. Это долгосрочное вложение в собственное развитие за счет краткосрочной эффективности. Когда я тороплюсь завершить задачу, мне гораздо труднее обнаруживать и исправлять ошибки. Я не трачу время на обдумывание правильных логических конструкций, а это значит, что мои предположения могут не соответствовать существующему коду, и именно в этом несоответствии кроется большинство ошибок. Я отстаиваю возможность работы в своём темпе, поэтому я могу выделить время, чтобы уделить больше внимания обучению, а не исполнению.
Один из моих любимых вариантов использования времени - экспериментирование. Иногда я обнаруживаю ошибку, которая не имеет для меня никакого смысла. Я понимаю, что запутался, но при этом нахожу ответ на Stack Overflow и продолжаю работу. Однако меня беспокоит то, что я не понял причину появления ошибки. Stack Overflow дал ответ, но не объяснение, что было не так в моём понимании логики работы программы. Чтобы укрепить свое понимание, мне нужно поэкспериментировать.
Если у меня нет свободного времени, мне некогда экспериментировать, а значит, я должен забыть об этой ошибке. И напротив, если есть возможность провести пару экспериментов, можно точно выяснить, чего я не понимал. Я люблю такие моменты, когда я узнаю что-то новое о системе. В следующий раз это сделает меня намного эффективнее.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
День семисотый. #Оффтоп
5 обязательных навыков для разработчиков 2021. Начало
Дни, когда разработчики просто сидели перед своими компьютерами и печатали код, давно прошли. В современном мире разработка ПО - это гораздо больше: это скорее культура и карьера. Вы когда-нибудь чувствовали себя отвратительно из-за того, что не смогли найти работу или пройти собеседование? Конечно, мы все прошли через эту фазу, у неё даже есть название... синдром самозванца. Но сейчас не об этом. Мы обсудим 5 обязательных навыков для разработчиков в 2021 году, которые помогут вам добиться успеха, стать современным разработчиком и повысить ваши шансы при общении с потенциальными работодателями.
1. Навыки обучения
Способность к обучению - важный навык, которым должен обладать каждый разработчик. Вы будете сталкиваться с многочисленными проблемами и новым набором задач почти каждый день. Вам нужно уметь учиться и быстро усваивать весь гигантский объём информации, с которым вы будете сталкиваться. Общие советы, как научиться чему-либо быстрее:
- Ограничить количество вещей, которые вы изучаете за раз. Будьте конкретны в том, что вы изучаете и усваиваете в каждый конкретный момент, потому что вы не можете изучить, усвоить и понять несколько вещей одновременно.
- Практикуйтесь по-настоящему и пишите код. Если вы изучаете новый язык или библиотеку, обязательно пишите код по мере чтения. Избегайте чтения сегодня и практики завтра, практикуйтесь здесь и сейчас.
2. Навыки прохождения собеседования
Это одни из самых важных навыков, которыми должен обладать разработчик, потому что без него вам будет сложно устроиться на работу. Вот некоторые важные моменты, которые помогли мне в процессе собеседования:
- Изучите компанию
Нельзя входить в комнату для собеседований полным новичком. Нужно провести исследование, узнать кого именно компания ищет, что ценит в работниках, помимо простого описания в вакансии. Нужно научиться позиционировать себя как идеального человека, которого ищет компания, на основе проведенного вами исследования. Просмотрите веб-сайт компании, найдите их страницы в социальных сетях и прочие данные о компании в сети. Наконец, обратите внимание на описание вакансии: из него также можно извлечь много полезной информации. Это поможет вам как правильно отвечать на вопросы интервьюера, так и задавать ему правильные вопросы.
- Задавайте вопросы интервьюеру
Это мой любимый совет на все времена: процесс собеседования должен быть диалогом между вами и интервьюером, а не экзаменом. Вам также необходимо провести собеседование с интервьюером, задав соответствующие вопросы. Этот процесс может помочь вам лучше понять компанию, команду и менеджеров. Вы можете использовать эту информацию, чтобы предложить идею, которая поможет развитию их компании. Вы должны выглядеть заинтересованными в компании, а не только в должности. Интервьюер долен видеть это и по вашему выражению лица, и по манере вашего разговора. Представьте, что кандидат во время интервью даёт компании идею, как кардинально улучшить бизнес-процесс и заработать больше денег. Как вы думаете, откажется ли компания от такого кандидата?
- Расслабьтесь и будьте собой
Наконец, расслабьтесь, это просто интервью, это обычный разговор, который вы вели много раз. Не нервничайте, будь, что будет. Даже если вы не получите работу, это не означает, что вы ни на что не годны. Возможно, компании просто не нужен такой кандидат, как вы, и вам не следует пытаться вписаться в неё, во что бы то ни стало. Не притворяйтесь кем-то, кем вы не являетесь, лишь для того, чтобы получить работу. Это может только навредить вам, потому что вы можете не вписываться в их культуру, вы можете не стать хорошим командным игроком. Будьте лучшей версией себя, и позвольте интервьюеру определить, кто подходит для его компании. А лучший вариант для вас ещё найдётся.
Окончание следует…
Источник: https://medium.com/backenders-club/5-must-have-skills-for-developers-2021-e64d91f273cc
Автор оригинала – Solomon Eseme
5 обязательных навыков для разработчиков 2021. Начало
Дни, когда разработчики просто сидели перед своими компьютерами и печатали код, давно прошли. В современном мире разработка ПО - это гораздо больше: это скорее культура и карьера. Вы когда-нибудь чувствовали себя отвратительно из-за того, что не смогли найти работу или пройти собеседование? Конечно, мы все прошли через эту фазу, у неё даже есть название... синдром самозванца. Но сейчас не об этом. Мы обсудим 5 обязательных навыков для разработчиков в 2021 году, которые помогут вам добиться успеха, стать современным разработчиком и повысить ваши шансы при общении с потенциальными работодателями.
1. Навыки обучения
Способность к обучению - важный навык, которым должен обладать каждый разработчик. Вы будете сталкиваться с многочисленными проблемами и новым набором задач почти каждый день. Вам нужно уметь учиться и быстро усваивать весь гигантский объём информации, с которым вы будете сталкиваться. Общие советы, как научиться чему-либо быстрее:
- Ограничить количество вещей, которые вы изучаете за раз. Будьте конкретны в том, что вы изучаете и усваиваете в каждый конкретный момент, потому что вы не можете изучить, усвоить и понять несколько вещей одновременно.
- Практикуйтесь по-настоящему и пишите код. Если вы изучаете новый язык или библиотеку, обязательно пишите код по мере чтения. Избегайте чтения сегодня и практики завтра, практикуйтесь здесь и сейчас.
2. Навыки прохождения собеседования
Это одни из самых важных навыков, которыми должен обладать разработчик, потому что без него вам будет сложно устроиться на работу. Вот некоторые важные моменты, которые помогли мне в процессе собеседования:
- Изучите компанию
Нельзя входить в комнату для собеседований полным новичком. Нужно провести исследование, узнать кого именно компания ищет, что ценит в работниках, помимо простого описания в вакансии. Нужно научиться позиционировать себя как идеального человека, которого ищет компания, на основе проведенного вами исследования. Просмотрите веб-сайт компании, найдите их страницы в социальных сетях и прочие данные о компании в сети. Наконец, обратите внимание на описание вакансии: из него также можно извлечь много полезной информации. Это поможет вам как правильно отвечать на вопросы интервьюера, так и задавать ему правильные вопросы.
- Задавайте вопросы интервьюеру
Это мой любимый совет на все времена: процесс собеседования должен быть диалогом между вами и интервьюером, а не экзаменом. Вам также необходимо провести собеседование с интервьюером, задав соответствующие вопросы. Этот процесс может помочь вам лучше понять компанию, команду и менеджеров. Вы можете использовать эту информацию, чтобы предложить идею, которая поможет развитию их компании. Вы должны выглядеть заинтересованными в компании, а не только в должности. Интервьюер долен видеть это и по вашему выражению лица, и по манере вашего разговора. Представьте, что кандидат во время интервью даёт компании идею, как кардинально улучшить бизнес-процесс и заработать больше денег. Как вы думаете, откажется ли компания от такого кандидата?
- Расслабьтесь и будьте собой
Наконец, расслабьтесь, это просто интервью, это обычный разговор, который вы вели много раз. Не нервничайте, будь, что будет. Даже если вы не получите работу, это не означает, что вы ни на что не годны. Возможно, компании просто не нужен такой кандидат, как вы, и вам не следует пытаться вписаться в неё, во что бы то ни стало. Не притворяйтесь кем-то, кем вы не являетесь, лишь для того, чтобы получить работу. Это может только навредить вам, потому что вы можете не вписываться в их культуру, вы можете не стать хорошим командным игроком. Будьте лучшей версией себя, и позвольте интервьюеру определить, кто подходит для его компании. А лучший вариант для вас ещё найдётся.
Окончание следует…
Источник: https://medium.com/backenders-club/5-must-have-skills-for-developers-2021-e64d91f273cc
Автор оригинала – Solomon Eseme
День семьсот первый. #Оффтоп
5 обязательных навыков для разработчиков 2021. Окончание
Начало
3. Будьте «нанимаемым»
Компании хотят знать гораздо больше, чем просто о ваших навыках программирования. Они хотят видеть ваши достижения и подтверждения вашей квалификации, а также хотят убедиться, что у вас есть необходимые навыки хорошего работника.
- Задавайте профессиональные вопросы
Вам нужно научиться задавать профессиональные вопросы. Как на собеседовании, так и просто в разговоре с коллегами. Это скажет вашим работодателям о том, что вы обладаете обширными знаниями в своей области.
- Очистите свои социальные сети
Это может показаться паранойей, и вообще, это ваша личная жизнь. Но всё больше кадровиков ищут информацию о кандидатах в Интернете перед принятием решения о приёме на работу (иногда даже перед собеседованием). И довольно часто кандидаты отсеиваются уже на этом этапе. Поищите себя в сети и посмотрите, какие результаты вы получите. Вы бы приняли себя на работу?
- Обновите своё резюме
Убедитесь, что ваше резюме всегда отражает самую последнюю информацию, а также не содержит неактуальной или вводящей в заблуждение информации.
4. Навыки коммуникации
Ещё один отличный навык, который вам стоит освоить, - это создание социальных связей, знакомств, сотрудничество с коллегами в компании или в вашей сфере специализации. Никто не является кладезем знаний. Нужно сотрудничать с людьми, чтобы вы могли получать помощь, вместе работать над проектами и обмениваться навыками. Быть самым умным парнем с лучшими навыками тайм-менеджмента и знанием всех технических деталей - это хорошо, но рано или поздно найдётся проблема, которая даже вам окажется не под силу. Именно тут помогут сотрудничество и связи. Вы легко сможете найти решение при помощи других специалистов в этой области.
5. Навыки программирования
Как бы банально это ни звучало, будьте профессионалом в том, что вы делаете. Чтобы хорошо программировать, нужно много терпения, времени и постоянная практика. Практикуйте задачи на алгоритмы и частые задачи с собеседований (см. #ЗадачиНаСобеседовании), чтобы тренировать навыки решения задач, а также просматривайте частые вопросы на собеседовании (см. #ВопросыНаСобеседовании), чтобы не забывать теорию. Вы должны отлично владеть хотя бы одним языком программирования, что облегчит для вас изучение других языков.
Какими ещё важными навыками должен, по-вашему, обладать современный программист? Пишите в комментариях. И с наступающим всех!
Источник: https://medium.com/backenders-club/5-must-have-skills-for-developers-2021-e64d91f273cc
Автор оригинала – Solomon Eseme
5 обязательных навыков для разработчиков 2021. Окончание
Начало
3. Будьте «нанимаемым»
Компании хотят знать гораздо больше, чем просто о ваших навыках программирования. Они хотят видеть ваши достижения и подтверждения вашей квалификации, а также хотят убедиться, что у вас есть необходимые навыки хорошего работника.
- Задавайте профессиональные вопросы
Вам нужно научиться задавать профессиональные вопросы. Как на собеседовании, так и просто в разговоре с коллегами. Это скажет вашим работодателям о том, что вы обладаете обширными знаниями в своей области.
- Очистите свои социальные сети
Это может показаться паранойей, и вообще, это ваша личная жизнь. Но всё больше кадровиков ищут информацию о кандидатах в Интернете перед принятием решения о приёме на работу (иногда даже перед собеседованием). И довольно часто кандидаты отсеиваются уже на этом этапе. Поищите себя в сети и посмотрите, какие результаты вы получите. Вы бы приняли себя на работу?
- Обновите своё резюме
Убедитесь, что ваше резюме всегда отражает самую последнюю информацию, а также не содержит неактуальной или вводящей в заблуждение информации.
4. Навыки коммуникации
Ещё один отличный навык, который вам стоит освоить, - это создание социальных связей, знакомств, сотрудничество с коллегами в компании или в вашей сфере специализации. Никто не является кладезем знаний. Нужно сотрудничать с людьми, чтобы вы могли получать помощь, вместе работать над проектами и обмениваться навыками. Быть самым умным парнем с лучшими навыками тайм-менеджмента и знанием всех технических деталей - это хорошо, но рано или поздно найдётся проблема, которая даже вам окажется не под силу. Именно тут помогут сотрудничество и связи. Вы легко сможете найти решение при помощи других специалистов в этой области.
5. Навыки программирования
Как бы банально это ни звучало, будьте профессионалом в том, что вы делаете. Чтобы хорошо программировать, нужно много терпения, времени и постоянная практика. Практикуйте задачи на алгоритмы и частые задачи с собеседований (см. #ЗадачиНаСобеседовании), чтобы тренировать навыки решения задач, а также просматривайте частые вопросы на собеседовании (см. #ВопросыНаСобеседовании), чтобы не забывать теорию. Вы должны отлично владеть хотя бы одним языком программирования, что облегчит для вас изучение других языков.
Какими ещё важными навыками должен, по-вашему, обладать современный программист? Пишите в комментариях. И с наступающим всех!
Источник: https://medium.com/backenders-club/5-must-have-skills-for-developers-2021-e64d91f273cc
Автор оригинала – Solomon Eseme
День семьсот второй.
Расслабьтесь и зарядитесь энергией
Для многих из нас большой удачей будет возможность провести новогодние праздники, не отвлекаясь на работу. Если у вас есть такая возможность, используйте её, чтобы отдохнуть и подготовиться к вызовам 2021 года. Проведите время с семьей, даже если вы были с ними весь год из-за карантина. Потратьте несколько минут на приборку рабочего стола (как физического, так и виртуального). Сделайте бекап. Почистите почтовый ящик, откажитесь от ненужных подписок.
Подумайте о том, что вы сделали в прошлом году. Чем вы больше всего гордитесь? В чём вы добились прогресса и что надеетесь улучшить в новом году? Какие у вас долгосрочные карьерные цели и какие шаги вы можете предпринять в новом году для их достижения?
Высыпитесь, наконец! Всё больше исследований показывают, что сон имеет решающее значение для нашего здоровья. Ютуб, сериалы и игры никуда не денутся.
С новым годом!
Автор оригинала: Steve "ardalis" Smith
Расслабьтесь и зарядитесь энергией
Для многих из нас большой удачей будет возможность провести новогодние праздники, не отвлекаясь на работу. Если у вас есть такая возможность, используйте её, чтобы отдохнуть и подготовиться к вызовам 2021 года. Проведите время с семьей, даже если вы были с ними весь год из-за карантина. Потратьте несколько минут на приборку рабочего стола (как физического, так и виртуального). Сделайте бекап. Почистите почтовый ящик, откажитесь от ненужных подписок.
Подумайте о том, что вы сделали в прошлом году. Чем вы больше всего гордитесь? В чём вы добились прогресса и что надеетесь улучшить в новом году? Какие у вас долгосрочные карьерные цели и какие шаги вы можете предпринять в новом году для их достижения?
Высыпитесь, наконец! Всё больше исследований показывают, что сон имеет решающее значение для нашего здоровья. Ютуб, сериалы и игры никуда не денутся.
С новым годом!
Автор оригинала: Steve "ardalis" Smith
День семьсот третий. #Оффтоп
7 Расширений VS Code для Повышения Продуктивности
1. Import Cost
Современные разработчики должны постоянно иметь дело с зависимостями. Поскольку мы используем кучу разного кода для сборки нашего проекта, за этот дополнительный код приходится платить. Import Cost рассчитывает приблизительный размер импорта, позволяя нам увидеть, сколько зависимость добавит к размеру нашего проекта.
2. indent-rainbow
Стиль - важный фактор, делающий наш код читабельным. Частью этого стиля являются отступы. Иногда проблема заключается в нескольких уровнях вложенности, и может быть трудно найти соответствующее начало или конец блока. indent-rainbow добавляет цвета к отступам, позволяя нам легко за ними следить.
3. Rainbow Brackets
Подобно отступам, сложный код, особенно при использовании математических выражений, может легко запутать. Хотя это и простой пример, он может легко выйти из-под контроля, и скобки трудно будет отследить:
v
4. Settings Sync
Если вы часто работаете на нескольких машинах, вам, возможно, приходится вручную поддерживать одинаковые настройки среды. Settings Sync позволяет сохранять настройки VS Code в GitHub Gist и синхронизировать их между разными установками VS Code.
5. Profile Switcher
Если вам нужно демонстрировать свой экран другим, приходится менять цвета и размер шрифта, чтобы люди могли видеть текст. Проблема в том, что эти настройки отличаются от тех, которые вы используете повседневно, когда пишете код. Profile Switcher позволяет вам настроить несколько профилей VS Code, каждый со своей собственной конфигурацией, и легко переключаться между различными настройками.
6. Better Comments
Хотя не все считают их важными, на самом деле комментарии помогают другим понять ваш код. Они также помогут вам понять свой код, когда вы будете читать его через полгода-год. Better Comments добавляют к комментариям своего рода подсветку синтаксиса, добавляя цвет к ключевым словам и операторам.
7. Duplicate Action
Последний вариант кажется мелочью. Duplicate Action добавляет в выпадающее меню пункт «Дублировать файл или папку» (Duplicate File or Folder), при нажатии на файл или папку правой кнопкой мыши.
Источник: https://www.freecodecamp.org/news/vs-code-extensions-to-boost-your-development-productivity/amp/
7 Расширений VS Code для Повышения Продуктивности
1. Import Cost
Современные разработчики должны постоянно иметь дело с зависимостями. Поскольку мы используем кучу разного кода для сборки нашего проекта, за этот дополнительный код приходится платить. Import Cost рассчитывает приблизительный размер импорта, позволяя нам увидеть, сколько зависимость добавит к размеру нашего проекта.
2. indent-rainbow
Стиль - важный фактор, делающий наш код читабельным. Частью этого стиля являются отступы. Иногда проблема заключается в нескольких уровнях вложенности, и может быть трудно найти соответствующее начало или конец блока. indent-rainbow добавляет цвета к отступам, позволяя нам легко за ними следить.
3. Rainbow Brackets
Подобно отступам, сложный код, особенно при использовании математических выражений, может легко запутать. Хотя это и простой пример, он может легко выйти из-под контроля, и скобки трудно будет отследить:
v
ar value = (((1+1)*2)+1)*2;
Rainbow Brackets выделяет круглые скобки разными цветами, что позволяет лучше понять, какая открывающая скобка принадлежит какой закрывающей скобке.4. Settings Sync
Если вы часто работаете на нескольких машинах, вам, возможно, приходится вручную поддерживать одинаковые настройки среды. Settings Sync позволяет сохранять настройки VS Code в GitHub Gist и синхронизировать их между разными установками VS Code.
5. Profile Switcher
Если вам нужно демонстрировать свой экран другим, приходится менять цвета и размер шрифта, чтобы люди могли видеть текст. Проблема в том, что эти настройки отличаются от тех, которые вы используете повседневно, когда пишете код. Profile Switcher позволяет вам настроить несколько профилей VS Code, каждый со своей собственной конфигурацией, и легко переключаться между различными настройками.
6. Better Comments
Хотя не все считают их важными, на самом деле комментарии помогают другим понять ваш код. Они также помогут вам понять свой код, когда вы будете читать его через полгода-год. Better Comments добавляют к комментариям своего рода подсветку синтаксиса, добавляя цвет к ключевым словам и операторам.
7. Duplicate Action
Последний вариант кажется мелочью. Duplicate Action добавляет в выпадающее меню пункт «Дублировать файл или папку» (Duplicate File or Folder), при нажатии на файл или папку правой кнопкой мыши.
Источник: https://www.freecodecamp.org/news/vs-code-extensions-to-boost-your-development-productivity/amp/
День семьсот четвёртый. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
5. Задавайте вопросы
Мы вообще не умеем задавать вопросы. Либо мы боимся, что вопрос выставит нас тупыми, поэтому вообще не задаём их, либо задаём вопрос с длинной преамбулой, которая нужна скорее для того, чтобы доказать, что мы не глупы, а не для того, чтобы уточнить вопрос. Но вы не можете считать вопрос глупым, пока не узнаете ответ.
Для полноценного понимания нужно задавать много вопросов. Начать сначала и постепенно латать дыры в понимании. Здесь помогут позитивные отношения в команде. Например, вот мой диалог с коллегой относительно программного обеспечения для упаковки:
- Что такое пакет?
- Это объединённый код, который можно установить в системе.
- Зачем нужны пакеты?
- Они дают единообразный способ получить все нужные файлы в нужном месте. Без них всё легко испортить. Необходимо убедиться, что каждый файл находится там, где он должен быть, настроены системные пути и доступны зависимые пакеты.
- Чем пакеты отличаются от приложений?
- Концепция очень похожая. Установщик Windows похож на диспетчер пакетов, который помогает устанавливать приложения. Аналогично пакеты dpkg и rpm похожи на .exe файлы, которые можно установить в системах Linux с помощью менеджеров пакетов apt и yum, в чём-то похожие на установщик Windows.
- Понятно. То есть setup.py в python каким-то образом конвертируется в dpkg? Как это работает?
- У нас есть python-debhelper, который запускает setup.py для преобразования.
- Интересно! Откуда ты это узнал?
- Файл debian/rules содержит инструкции по созданию пакетов dpkg.
Теперь я знаю, что пора посмотреть документацию. У меня достаточно деталей, чтобы разобраться в ней. Оказалось, что это было не так просто, как я думал, и задать вопрос не было глупой идеей.
Я выработал эту привычку: всегда полезно задать несколько хороших вопросов. Большинство из них зависят от контекста, но у меня есть один любимый общий вопрос: «Как вы узнали про X?» Когда я спрашиваю кого-то о чем-то, и они отвечают, то следующее, что я спрашиваю, - откуда они это узнали? Это помогает мне в следующий раз разобраться самому. Я сделал это в диалоге, приведённом выше, и узнал, что есть файл с инструкциями, которые я могу прочитать сам, и не отвлекать человека вопросами в следующий раз.
Ещё один хороший вопрос – спросить о что вас смущает или уточнить что-то, что для вас не совсем ясно. Лучше задать короткий вопрос, чем сделать неправильно и переделывать.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
5. Задавайте вопросы
Мы вообще не умеем задавать вопросы. Либо мы боимся, что вопрос выставит нас тупыми, поэтому вообще не задаём их, либо задаём вопрос с длинной преамбулой, которая нужна скорее для того, чтобы доказать, что мы не глупы, а не для того, чтобы уточнить вопрос. Но вы не можете считать вопрос глупым, пока не узнаете ответ.
Для полноценного понимания нужно задавать много вопросов. Начать сначала и постепенно латать дыры в понимании. Здесь помогут позитивные отношения в команде. Например, вот мой диалог с коллегой относительно программного обеспечения для упаковки:
- Что такое пакет?
- Это объединённый код, который можно установить в системе.
- Зачем нужны пакеты?
- Они дают единообразный способ получить все нужные файлы в нужном месте. Без них всё легко испортить. Необходимо убедиться, что каждый файл находится там, где он должен быть, настроены системные пути и доступны зависимые пакеты.
- Чем пакеты отличаются от приложений?
- Концепция очень похожая. Установщик Windows похож на диспетчер пакетов, который помогает устанавливать приложения. Аналогично пакеты dpkg и rpm похожи на .exe файлы, которые можно установить в системах Linux с помощью менеджеров пакетов apt и yum, в чём-то похожие на установщик Windows.
- Понятно. То есть setup.py в python каким-то образом конвертируется в dpkg? Как это работает?
- У нас есть python-debhelper, который запускает setup.py для преобразования.
- Интересно! Откуда ты это узнал?
- Файл debian/rules содержит инструкции по созданию пакетов dpkg.
Теперь я знаю, что пора посмотреть документацию. У меня достаточно деталей, чтобы разобраться в ней. Оказалось, что это было не так просто, как я думал, и задать вопрос не было глупой идеей.
Я выработал эту привычку: всегда полезно задать несколько хороших вопросов. Большинство из них зависят от контекста, но у меня есть один любимый общий вопрос: «Как вы узнали про X?» Когда я спрашиваю кого-то о чем-то, и они отвечают, то следующее, что я спрашиваю, - откуда они это узнали? Это помогает мне в следующий раз разобраться самому. Я сделал это в диалоге, приведённом выше, и узнал, что есть файл с инструкциями, которые я могу прочитать сам, и не отвлекать человека вопросами в следующий раз.
Ещё один хороший вопрос – спросить о что вас смущает или уточнить что-то, что для вас не совсем ясно. Лучше задать короткий вопрос, чем сделать неправильно и переделывать.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
День семьсот пятый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
72. Дорога к Производительности – Минное Поле из Плохого Кода
Чаще всего настройка производительности системы требует от вас изменения кода. Когда нам нужно изменить код, каждый чрезмерно сложный или сильно связанный фрагмент представляет собой мину, угрожающую разрушить всю нашу красивую структуру. Первой жертвой взрыва мины грязного кода станет ваше расписание. Когда разработка идёт плавно, легко предсказать, когда вы закончите. Неожиданные столкновения с грязным кодом очень затрудняют прогнозирование.
Допустим, вы обнаружили проблему в производительности на «горячем пути» выполнения программы. Для оптимизации вы решаете изменить алгоритм на нижележащем уровне. И вы сообщаете менеджеру проекта, что оптимизация займёт 3–4 часа. Применяя исправление, вы быстро понимаете, что сломали зависимую часть системы. Возможно, вы предвидели и это (связанность блоков на один шаг вполне можно предвидеть), но что, если после исправления этой части сломается что-нибудь ещё? Кроме того, чем дальше зависимость от источника, тем меньше вероятность того, что вы распознаете её и учтёте в оценке трудозатрат. Внезапно ваша оценка в 3–4 часа превращается в 3–4 недели, увеличиваясь с каждой новой обнаруженной проблемой сразу на 1-2 дня. Нередко «быстрый» рефакторинг выливается в несколько месяцев работы. Такая ситуация может серьёзно подорвать доверие к команде. Если бы только у нас был инструмент, который помог бы нам выявить и измерить эти риски…
На самом деле, у нас есть много способов измерения и контроля степени и глубины взаимосвязи и сложности нашего кода. Метрики программного обеспечения могут использоваться для подсчёта частоты появления определённых функций в нашем коде. Значения этих подсчетов действительно коррелируют с качеством кода. Для измерения связанности применяются две
метрики: fan-in и fan-out.
- fan-out для классов определяется как количество классов, на которые прямо или косвенно ссылается выбранный класс. Рассматривайте эту метрику как количество классов, которые должны быть скомпилированы перед компиляцией вашего класса.
- fan-in представляет собой количество классов, зависящих от интересующего нас класса.
Зная эти показатели, мы можем вычислить коэффициент нестабильности:
При использовании метрик следует помнить, что это всего лишь теоретические правила. Полагаясь исключительно на математику, можно заметить, что увеличение fi без изменения fo приближает I к нулю. Однако есть обратная сторона очень большого значения fan-in: такие классы будет труднее изменить, не нарушая зависимостей. Кроме того, не решая проблему большого значения fan-out, вы не снижаете риски, поэтому необходимо соблюдать определённый баланс.
Одним из недостатков программных метрик является то, что огромный массив чисел, которые генерируют инструменты метрик, может напугать непосвящённых. Тем не менее, метрики качества ПО могут быть мощным инструментом в нашей борьбе за чистый код. Они могут помочь нам выявить и устранить «мины грязного кода» до того, как они станут серьёзными угрозами рефакторингу.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Kirk Pepperdine
97 Вещей, Которые Должен Знать Каждый Программист
72. Дорога к Производительности – Минное Поле из Плохого Кода
Чаще всего настройка производительности системы требует от вас изменения кода. Когда нам нужно изменить код, каждый чрезмерно сложный или сильно связанный фрагмент представляет собой мину, угрожающую разрушить всю нашу красивую структуру. Первой жертвой взрыва мины грязного кода станет ваше расписание. Когда разработка идёт плавно, легко предсказать, когда вы закончите. Неожиданные столкновения с грязным кодом очень затрудняют прогнозирование.
Допустим, вы обнаружили проблему в производительности на «горячем пути» выполнения программы. Для оптимизации вы решаете изменить алгоритм на нижележащем уровне. И вы сообщаете менеджеру проекта, что оптимизация займёт 3–4 часа. Применяя исправление, вы быстро понимаете, что сломали зависимую часть системы. Возможно, вы предвидели и это (связанность блоков на один шаг вполне можно предвидеть), но что, если после исправления этой части сломается что-нибудь ещё? Кроме того, чем дальше зависимость от источника, тем меньше вероятность того, что вы распознаете её и учтёте в оценке трудозатрат. Внезапно ваша оценка в 3–4 часа превращается в 3–4 недели, увеличиваясь с каждой новой обнаруженной проблемой сразу на 1-2 дня. Нередко «быстрый» рефакторинг выливается в несколько месяцев работы. Такая ситуация может серьёзно подорвать доверие к команде. Если бы только у нас был инструмент, который помог бы нам выявить и измерить эти риски…
На самом деле, у нас есть много способов измерения и контроля степени и глубины взаимосвязи и сложности нашего кода. Метрики программного обеспечения могут использоваться для подсчёта частоты появления определённых функций в нашем коде. Значения этих подсчетов действительно коррелируют с качеством кода. Для измерения связанности применяются две
метрики: fan-in и fan-out.
- fan-out для классов определяется как количество классов, на которые прямо или косвенно ссылается выбранный класс. Рассматривайте эту метрику как количество классов, которые должны быть скомпилированы перед компиляцией вашего класса.
- fan-in представляет собой количество классов, зависящих от интересующего нас класса.
Зная эти показатели, мы можем вычислить коэффициент нестабильности:
I = fo/(fi+fo)Чем ближе к 0, тем стабильнее код, и наоборот, чем ближе к 1, тем стабильность меньше. Чем стабильнее код, тем проще его изменять, тогда как нестабильный код с большей вероятностью будет содержать «мины». Цель рефакторинга - приблизить I к 0.
При использовании метрик следует помнить, что это всего лишь теоретические правила. Полагаясь исключительно на математику, можно заметить, что увеличение fi без изменения fo приближает I к нулю. Однако есть обратная сторона очень большого значения fan-in: такие классы будет труднее изменить, не нарушая зависимостей. Кроме того, не решая проблему большого значения fan-out, вы не снижаете риски, поэтому необходимо соблюдать определённый баланс.
Одним из недостатков программных метрик является то, что огромный массив чисел, которые генерируют инструменты метрик, может напугать непосвящённых. Тем не менее, метрики качества ПО могут быть мощным инструментом в нашей борьбе за чистый код. Они могут помочь нам выявить и устранить «мины грязного кода» до того, как они станут серьёзными угрозами рефакторингу.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Kirk Pepperdine
День семьсот седьмой. #ЧтоНовенького
Mapster
У Nick Chapsas вышло интересное видео про маппер под названием Mapster. "Как AutoMapper, только намного, намного быстрее", - как утверждают создатели. Но для начала приведу парочку тезисов Ника, которые мне показались интересными.
При выборе между ручным и автоматическим маппингом руководствуйтесь двумя правилами:
1. Обязательно добавляйте юнит-тесты для логики маппинга, чтобы удостовериться, что маппинг настроен правильно. Лучше даже добавить их в CI-пайплайн, чтобы без прохождения этих тестов релиз был невозможен.
2. Никогда не смешивайте бизнес логику, какую-либо валидацию с логикой маппинга, и не добавляйте в маппинг внешние зависимости. Всё это относится к логике домена или логике приложения, в маппинге этому не место.
Третьим соображением обычно является производительность. Однако Ник проверил скорость работы ручного маппинга и нескольких автоматических мапперов, и скорость на самом деле не играет особой роли.
Но упомянуть это видео я решил ещё по одной причине. Я как-то уже писал про генераторы кода, новую функцию, появившуюся в среде .NET. Так вот, Mapster позволяет сгенерировать для класса домена код как маппера, так и класса DTO, просто добавив атрибут к классу домена. Довольно круто. При этом бенчмарк сгенерированного маппинга по времени такой же быстрый (а то и превосходит) ручной маппинг, и примерно в 4 раза быстрее, чем AutoMapper. То есть даже о тех микроскопических потерях в скорости при использовании автоматического маппинга относительно ручного, теперь говорить не приходится.
Подробности бенчмарка и описание работы Mapster'а в видео по ссылке ниже.
Источник: https://www.youtube.com/watch?v=UIslFVEHkzA
Mapster
У Nick Chapsas вышло интересное видео про маппер под названием Mapster. "Как AutoMapper, только намного, намного быстрее", - как утверждают создатели. Но для начала приведу парочку тезисов Ника, которые мне показались интересными.
При выборе между ручным и автоматическим маппингом руководствуйтесь двумя правилами:
1. Обязательно добавляйте юнит-тесты для логики маппинга, чтобы удостовериться, что маппинг настроен правильно. Лучше даже добавить их в CI-пайплайн, чтобы без прохождения этих тестов релиз был невозможен.
2. Никогда не смешивайте бизнес логику, какую-либо валидацию с логикой маппинга, и не добавляйте в маппинг внешние зависимости. Всё это относится к логике домена или логике приложения, в маппинге этому не место.
Третьим соображением обычно является производительность. Однако Ник проверил скорость работы ручного маппинга и нескольких автоматических мапперов, и скорость на самом деле не играет особой роли.
Но упомянуть это видео я решил ещё по одной причине. Я как-то уже писал про генераторы кода, новую функцию, появившуюся в среде .NET. Так вот, Mapster позволяет сгенерировать для класса домена код как маппера, так и класса DTO, просто добавив атрибут к классу домена. Довольно круто. При этом бенчмарк сгенерированного маппинга по времени такой же быстрый (а то и превосходит) ручной маппинг, и примерно в 4 раза быстрее, чем AutoMapper. То есть даже о тех микроскопических потерях в скорости при использовании автоматического маппинга относительно ручного, теперь говорить не приходится.
Подробности бенчмарка и описание работы Mapster'а в видео по ссылке ниже.
Источник: https://www.youtube.com/watch?v=UIslFVEHkzA
👍1
День семьсот восьмой.
Функциональное программирование. Начало
Термин функциональное программирование может сбивать с толку. Во многих ООП языках есть функции, замаскированные под методы объектов. Что значит этот новый термин?
Во-первых, термин не новый. Концептуально функциональное программирование как лямбда-исчисление было разработано еще в 1930 году Алонзо Черчем, а первый функциональный язык программирования LISP был доступен к концу 50-х годов.
Во-вторых, слово функция здесь не обозначает методы, которые мы называем функциями в программировании, а скорее относится к математическим функциям, таким как синус и косинус. И именно их чистота отличает их от функций в императивных языках программирования. Чистая функция при одном и том же вводе даёт один и тот же результат, без побочных эффектов (то есть, не изменяя состояния никаких других объектов). В отличие от функционального, императивное программирование не заставляет вас делать функции чистыми.
Заблуждения о функциональном программировании
Если спросить разработчиков, каковы характеристики хорошего кода скорее всего, вы услышите, что хороший код:
- легче поддерживать,
- улучшает читаемость,
- обычно короче и лаконичнее,
- можно тестировать, а зависимости изолировать,
- можно расширять,
- в нём меньше ошибок.
ФП - это не код и не язык, а парадигма. Использовать её, вероятно, можно в любом языке, просто некоторые языки больше приспособлены для него (или даже требуют его использования), тогда как функциональный код на других языках многословен и сложен для поддержки. Ещё раз отметим:
1. ФП не обязательно ведет к более удобному для сопровождения коду и не нацелено на это.
2. Код, написанный на функциональных языках, не обязательно более читабелен.
3. Использование ФП также может превратить код в спагетти, если вы не будете осторожны.
Тогда зачем его использовать?
ФП бережёт разум и нервы разработчика! Рассмотрим на примере. Предположим, у нас есть класс
1. Как автор
2. Что произойдёт, если я дважды вызову
3. Как узнать, после возврата из
Очевидно, что даже такой простой код заставляет разработчика отслеживать и запоминать состояние на различных этапах процесса. Его может быть легко запомнить для одного объекта, но, если объектов много, это может свести вас с ума. Проблема заключается в отслеживании состояния. Если бы у нас не было состояния, у нас не было бы этой проблемы.
Продолжение следует…
Источник: https://onurgumus.github.io/2022/12/26/Functional-Programming.html
Функциональное программирование. Начало
Термин функциональное программирование может сбивать с толку. Во многих ООП языках есть функции, замаскированные под методы объектов. Что значит этот новый термин?
Во-первых, термин не новый. Концептуально функциональное программирование как лямбда-исчисление было разработано еще в 1930 году Алонзо Черчем, а первый функциональный язык программирования LISP был доступен к концу 50-х годов.
Во-вторых, слово функция здесь не обозначает методы, которые мы называем функциями в программировании, а скорее относится к математическим функциям, таким как синус и косинус. И именно их чистота отличает их от функций в императивных языках программирования. Чистая функция при одном и том же вводе даёт один и тот же результат, без побочных эффектов (то есть, не изменяя состояния никаких других объектов). В отличие от функционального, императивное программирование не заставляет вас делать функции чистыми.
Заблуждения о функциональном программировании
Если спросить разработчиков, каковы характеристики хорошего кода скорее всего, вы услышите, что хороший код:
- легче поддерживать,
- улучшает читаемость,
- обычно короче и лаконичнее,
- можно тестировать, а зависимости изолировать,
- можно расширять,
- в нём меньше ошибок.
ФП - это не код и не язык, а парадигма. Использовать её, вероятно, можно в любом языке, просто некоторые языки больше приспособлены для него (или даже требуют его использования), тогда как функциональный код на других языках многословен и сложен для поддержки. Ещё раз отметим:
1. ФП не обязательно ведет к более удобному для сопровождения коду и не нацелено на это.
2. Код, написанный на функциональных языках, не обязательно более читабелен.
3. Использование ФП также может превратить код в спагетти, если вы не будете осторожны.
Тогда зачем его использовать?
ФП бережёт разум и нервы разработчика! Рассмотрим на примере. Предположим, у нас есть класс
Car со свойством Color и двумя методами Run() и Stop(). Метод Run делает все, что необходимо для запуска машины. Рассмотрим следующий код:var car = new Car();
car.Run();
… //какой-то код
SomeOtherFunction(car);
… // ещё код
SomeOtherFunction остановила машину? Непонятно, надо заглянуть в реализацию:SomeOtherFunction(Car car) {
//машина уже запущена? Непонятно
car.Run();
//возможно, мы запустили уже запущенную машину
//что произойдёт в этом случае?
}
Здесь у нас 3 проблемы:1. Как автор
SomeOtherFunction, как я узнаю, был ли ранее вызван метод Run? Мне нужно найти вызывающий код, т.е. для разработчика это дополнительная нагрузка. Можно добавить свойство IsRunning, но ничто не заставляет меня проверять его значение. И не всегда такие свойства и методы связаны между собой. Всё равно нужно проверять вызывающий код. Хуже того, если SomeOtherFunction публичная в моём API, мне придётся прибегать к защитному программированию, документировать свой API, чётко описывать ожидаемое состояние входных данных и молиться, чтобы пользователь моего API прочитал документацию.2. Что произойдёт, если я дважды вызову
Run? Исключение? Второй вызов проигнорируется? Единственный способ узнать это - прочитать исходный код класса Car. Ещё одна головная боль.3. Как узнать, после возврата из
SomeOtherFunction, остановлена машина или нет. Опять придётся лезть в исходный код SomeOtherFunction.Очевидно, что даже такой простой код заставляет разработчика отслеживать и запоминать состояние на различных этапах процесса. Его может быть легко запомнить для одного объекта, но, если объектов много, это может свести вас с ума. Проблема заключается в отслеживании состояния. Если бы у нас не было состояния, у нас не было бы этой проблемы.
Продолжение следует…
Источник: https://onurgumus.github.io/2022/12/26/Functional-Programming.html
День семьсот девятый.
Функциональное программирование. Окончание
Начало
Функциональное решение
Итак, чтобы избавиться от состояния, представим состояние с помощью типов. Таким образом, вместо
Если ФП такое замечательное, почему оно не так популярно?
Во-первых, ФП - это не синтаксис, а парадигма. Например, недавно в C#9 появились записи. Запись - это функциональная концепция, и если вы не знакомы с функциональной парадигмой, вы можете не понимать, зачем они нужны. Можно сказать, что они неизменяемы, но это слишком упрощённо. На самом деле они обеспечивают семантику значений и ссылочную прозрачность, поэтому нас не волнует их расположение в памяти.
Я пытаюсь сказать, что для овладения ФП вы должны забыть о большинстве вещей, которые вы уже знаете в императивном программировании. И это одна из основных причин, по которой люди избегают ФП. В императивном мире есть инструкции, которые сообщают компилятору, что делать:
Однако исторически проблемы с бОльшим потреблением ресурсов в ФП, позволили императивной парадигме процветать, а люди продолжали скептически относиться к ФП. Маленькое сообщество, меньше примеров, меньше ресурсов и инструментов. Статей, книг и руководств по ФП множество, но попробуйте найти функциональный пример приложения для простого списка дел с сохранением в БД. Или попробуйте использовать инструменты вроде ORM. Скорее всего вас ждёт разочарование и необходимость изучать новые способы сохранения данных в ФП.
Учитывая этот процесс переобучения, функциональные программисты составляют меньшинство в сообществе разработчиков. При этом сегодняшние проблемы требуют сложных решений, и такие решения, как реактивное программирование, становятся все более популярными. Наверное, одна из самых известных и востребованных библиотек javascript - React - хороший пример того, как выгодно функциональное и реактивное программирование. Одностраничные клиентские приложения гораздо чаще отслеживают состояние, чем их серверные части, поскольку обычно серверная часть только ретранслирует данные из и в базу данных. Сегодня много разработчиков оценили React, который помогает им масштабировать сложные приложения.
Похоже, что мы подошли к грани безумия в отношении ООП и императивного программирования, и дальше так нельзя. ФП - это ответ. Но откажутся ли разработчики от своих навыков и начнут ли заново процесс обучения? Кто знает. На сегодняшний день нехватка ресурсов и инструментов, стоимость переобучения, неизвестность и другие исторические причины создают проблемы для процветания парадигмы ФП, но в будущем это может измениться.
Источник: https://onurgumus.github.io/2022/12/26/Functional-Programming.html
Функциональное программирование. Окончание
Начало
Функциональное решение
Итак, чтобы избавиться от состояния, представим состояние с помощью типов. Таким образом, вместо
Car, у нас будет два разных типа: StoppedCar и RunningCar. А также функция запуска, которая принимает StoppedCar и возвращает RunningCar. Таким образом мы решим все три проблемы:SomeOtherFunction(RunningCar car){…}
Мы всегда знаем запущена ли машина на входе, и мы не сможем вызвать функцию Run повторно, потому что такой код не скомпилируется. Также в зависимости от типа возвращаемого значения, мы будем знать, в каком состоянии возвращается машина из SomeOtherFunction. Теперь у нас меньше забот, жизнь стала легче, не так ли?Если ФП такое замечательное, почему оно не так популярно?
Во-первых, ФП - это не синтаксис, а парадигма. Например, недавно в C#9 появились записи. Запись - это функциональная концепция, и если вы не знакомы с функциональной парадигмой, вы можете не понимать, зачем они нужны. Можно сказать, что они неизменяемы, но это слишком упрощённо. На самом деле они обеспечивают семантику значений и ссылочную прозрачность, поэтому нас не волнует их расположение в памяти.
Я пытаюсь сказать, что для овладения ФП вы должны забыть о большинстве вещей, которые вы уже знаете в императивном программировании. И это одна из основных причин, по которой люди избегают ФП. В императивном мире есть инструкции, которые сообщают компилятору, что делать:
делай раз;Тогда как ФП – это как кадры фильма. Каждый кадр неизменяем, но, если мы меняем их 24 раза в секунду, создаётся иллюзия движущейся картинки. ФП делает то же самое.
делай два;
фрейм1 -> функция преобразования -> фрейм2Мы никогда не меняем данные, но каждый раз, когда нам нужно что-то изменить, мы создаем новый экземпляр этого типа. И очевидно, что это лишние циклы процессора и дополнительное выделение памяти по сравнению с императивным подходом. Но в наши дни, в отличие от 30 лет назад, инженеры стоят дорого, а серверы - нет. Сейчас ваши пользователи вряд ли заметят задержку в несколько сотен наносекунд. А вы можете использовать мощь оборудования ради повышения продуктивности программиста. Благодаря неизменяемости функциональная парадигма лучше масштабируется в распределенных и многопоточных средах.
Однако исторически проблемы с бОльшим потреблением ресурсов в ФП, позволили императивной парадигме процветать, а люди продолжали скептически относиться к ФП. Маленькое сообщество, меньше примеров, меньше ресурсов и инструментов. Статей, книг и руководств по ФП множество, но попробуйте найти функциональный пример приложения для простого списка дел с сохранением в БД. Или попробуйте использовать инструменты вроде ORM. Скорее всего вас ждёт разочарование и необходимость изучать новые способы сохранения данных в ФП.
Учитывая этот процесс переобучения, функциональные программисты составляют меньшинство в сообществе разработчиков. При этом сегодняшние проблемы требуют сложных решений, и такие решения, как реактивное программирование, становятся все более популярными. Наверное, одна из самых известных и востребованных библиотек javascript - React - хороший пример того, как выгодно функциональное и реактивное программирование. Одностраничные клиентские приложения гораздо чаще отслеживают состояние, чем их серверные части, поскольку обычно серверная часть только ретранслирует данные из и в базу данных. Сегодня много разработчиков оценили React, который помогает им масштабировать сложные приложения.
Похоже, что мы подошли к грани безумия в отношении ООП и императивного программирования, и дальше так нельзя. ФП - это ответ. Но откажутся ли разработчики от своих навыков и начнут ли заново процесс обучения? Кто знает. На сегодняшний день нехватка ресурсов и инструментов, стоимость переобучения, неизвестность и другие исторические причины создают проблемы для процветания парадигмы ФП, но в будущем это может измениться.
Источник: https://onurgumus.github.io/2022/12/26/Functional-Programming.html
День семьсот десятый. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
6. Замечайте Странности
Как-то раз работал я с датой в Python. Это были даты, которые наша поисковая система должна была индексировать, и мы хотели, чтобы они были в формате UTC. Поэтому добавил преобразование даты в UTC перед загрузкой. Для этого нужно было добавить к датам часовой пояс. Я создал такие дату и время:
Это довольно серьёзная ошибка. В библиотеке Pytz есть историческая информация о часовых поясах. До 1942 года смещение для часового пояса
Чтобы этого больше не повторилось, я начал тренировать «мускулы внимания». То есть замечать, что меня смущает. Не только при написании кода, но и во всём остальном. Каждый раз, когда я замечаю, что меня что-то смущает, я делаю паузу, и пытаюсь выяснить, в чём дело. Возможно, теоретически это звучит банально, но я надеюсь, что рассказанная выше история поможет вам понять важность этого приёма. Самое сложное теперь – это понять, что же конкретно вас смущает.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
6. Замечайте Странности
Как-то раз работал я с датой в Python. Это были даты, которые наша поисковая система должна была индексировать, и мы хотели, чтобы они были в формате UTC. Поэтому добавил преобразование даты в UTC перед загрузкой. Для этого нужно было добавить к датам часовой пояс. Я создал такие дату и время:
import datetimeВ моих тестах преобразованное время отличалось от ожидаемого на 23 минуты. Тогда я не придал этому значения, хотя это и смутило меня. Я просто поправил ожидаемое время на
from pytz import timezone
indexed_date =
datetime.datetime(2020, 11, 20,
12, 2, 0,
tzinfo=timezone('Asia/Kolkata'))
-23 минуты, чтобы тесты проходили. Да, я слышу, как вы осуждаете меня, это было однозначно хреновой идеей. Когда я это осознал, я уже не мог перестать думать об этом. До сих пор этот случай преследует меня. Как я мог позволить себе так «решить» проблему? Конечно, на код ревью кто-то из коллег прокомментировал это словами «это выглядит неправильно». Я был готов провалиться сквозь землю, и решил выяснить, что здесь пошло не так.Это довольно серьёзная ошибка. В библиотеке Pytz есть историческая информация о часовых поясах. До 1942 года смещение для часового пояса
Asia/Calcutta (Да, даже название города было другое) было +5:53:20. Когда часовой пояс из pytz передаётся в новую дату, библиотека не имеет информации о дате, чтобы выбрать актуальное на дату смещение, поэтому по умолчанию используется первое доступное смещение, что неверно. И в документации об этом упоминается. Правильный способ - использовать tzinfo.localize(), который выбирает часовой пояс соответственно дате:from pytz import timezoneЯ бы не узнал об этом, если бы не получил «пинка» от коллег на код ревью. Это выявило у меня довольно распространённый образ мышления: когда нас что-то смущает, мы стараемся «спрятать это под ковёр». С тех пор я был осторожен.
tz=timezone('Asia/Kolkata')
indexed_date = tz.localize(
datetime.datetime(2020, 11, 20,
12, 2, 0))
Чтобы этого больше не повторилось, я начал тренировать «мускулы внимания». То есть замечать, что меня смущает. Не только при написании кода, но и во всём остальном. Каждый раз, когда я замечаю, что меня что-то смущает, я делаю паузу, и пытаюсь выяснить, в чём дело. Возможно, теоретически это звучит банально, но я надеюсь, что рассказанная выше история поможет вам понять важность этого приёма. Самое сложное теперь – это понять, что же конкретно вас смущает.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
День семьсот одиннадцатый. #MoreEffectiveCSharp
19. Избегайте Перегрузки Методов, Определённых в Базовых Классах
Когда базовый класс выбирает имя члена, он назначает определённый семантический смысл этому имени. Ни при каких обстоятельствах производный класс не должен использовать то же самое имя для других целей. И всё же есть много причин, по которым производный класс может захотеть использовать то же имя. Например, реализовать ту же семантику другим способом или с другими параметрами. Но вы не должны перегружать методы, объявленные в базовом классе.
Правила разрешения перегрузки сложны по определению. Возможными кандидатами могут быть методы класса, любого из его базовых классов, методы расширения класса или интерфейсов, которые он реализует. Добавьте к этому обобщённые методы и обобщённые методы расширения, методы с необязательными параметрами, и уже вообще непонятно, сможет ли хоть кто-нибудь поручиться, какой из методов будет вызван. Вы действительно хотите ещё больше усложнить ситуацию?
Добавление перегрузки для метода базового класса увеличивает вероятность того, что ваша интерпретация спецификации не совпадёт с интерпретацией компилятора, и, безусловно, запутает ваших пользователей. Решение простое: выберите другое имя метода.
Рассмотрим пару примеров:
Больше ада! Добавим дженериков:
Да, вы можете удивить друзей на вечеринке программистов глубокими познаниями логики разрешения перегрузок в C#. Но не ожидайте, что пользователи вашего API будут иметь такие подробные знания, чтобы правильно использовать ваш API. Просто не перегружайте методы, объявленные в базовом классе. Это не представляет никакой ценности и только приведёт ваших пользователей в замешательство.
Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 19.
19. Избегайте Перегрузки Методов, Определённых в Базовых Классах
Когда базовый класс выбирает имя члена, он назначает определённый семантический смысл этому имени. Ни при каких обстоятельствах производный класс не должен использовать то же самое имя для других целей. И всё же есть много причин, по которым производный класс может захотеть использовать то же имя. Например, реализовать ту же семантику другим способом или с другими параметрами. Но вы не должны перегружать методы, объявленные в базовом классе.
Правила разрешения перегрузки сложны по определению. Возможными кандидатами могут быть методы класса, любого из его базовых классов, методы расширения класса или интерфейсов, которые он реализует. Добавьте к этому обобщённые методы и обобщённые методы расширения, методы с необязательными параметрами, и уже вообще непонятно, сможет ли хоть кто-нибудь поручиться, какой из методов будет вызван. Вы действительно хотите ещё больше усложнить ситуацию?
Добавление перегрузки для метода базового класса увеличивает вероятность того, что ваша интерпретация спецификации не совпадёт с интерпретацией компилятора, и, безусловно, запутает ваших пользователей. Решение простое: выберите другое имя метода.
Рассмотрим пару примеров:
public class Fruit { }
public class Apple : Fruit { }
Вот класс с методом, использующим производный параметр (Apple):public class Animal {
public void Eat(Apple food) =>
WriteLine("Animal.Eat");
}
var obj1 = new Animal();
obj1.Eat(new Apple());
Понятно, что это выведет "Animal.Eat". Добавим производный класс с перегруженным методом с параметром базового типа:public class Monkey : Animal {
public void Eat(Fruit food) =>
WriteLine("Monkey.Eat");
}
Итак, что выведет следующий код?var obj2 = new Monkey();Оба вызова выведут "Monkey.Eat". Всегда в первую очередь вызывается метод производного класса, даже если в базовом классе есть более подходящий кандидат. Смысл в том, что автор производного класса лучше знает сценарий использования, поэтому производному методу отдаётся предпочтение. А если вот так:
obj2.Eat(new Apple());
obj2.Eat(new Fruit());
Animal obj3 = new Monkey();Смотрим внимательно: тип времени компиляции
obj3.Eat(new Apple());
obj3 - Animal (базовый), хотя, во время выполнения тип будет Monkey (производный). Метод Eat не виртуальный, поэтому obj3.Eat() должен использовать Animal.Eat.Больше ада! Добавим дженериков:
public class Animal {
…
public void Consume(IEnumerable<Apple> food) =>
WriteLine("Animal.Consume");
}
И перегрузку с коллекцией базового типа в производном классе:public class Monkey : Animal {
…
public void Consume(IEnumerable<Fruit> food) =>
WriteLine("Monkey.Consume");
}
var food = new List<Apple> { new Apple(), new Apple() };
var obj2 = new Monkey();
obj2.Consume(food);
Что будет выведено на этот раз? Начиная с C#4.0 обобщённые интерфейсы поддерживают ковариантность и контравариантность. Это означает, что Monkey.Consume является кандидатом для IEnumerable<Apple>, хотя формально тип его параметра IEnumerable<Fruit>. Однако более ранние версии C# не поддерживают вариантности, и в них обобщённые параметры инвариантны. В этом случае единственным кандидатом будет Animal.Consume.Да, вы можете удивить друзей на вечеринке программистов глубокими познаниями логики разрешения перегрузок в C#. Но не ожидайте, что пользователи вашего API будут иметь такие подробные знания, чтобы правильно использовать ваш API. Просто не перегружайте методы, объявленные в базовом классе. Это не представляет никакой ценности и только приведёт ваших пользователей в замешательство.
Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 19.