Советы разработчикам (python и не только) @advice17 Channel on Telegram

Советы разработчикам (python и не только)

Советы разработчикам (python и не только)
Советы для разработчиков ПО от @Tishka17

Поддержать материально https://www.tinkoff.ru/cf/2NkdXaljivI

Programming, python, software architecture и все такое
7,619 Subscribers
3 Photos
52 Videos
Last Updated 27.02.2025 14:58

Similar Channels

addmeto
78,202 Subscribers
Zen of Python
20,438 Subscribers

Советы разработчикам: Как улучшить свои навыки программирования

Современный рынок программного обеспечения развивается стремительными темпами, и разработчики сталкиваются с новыми вызовами и возможностями каждый день. Бренды, такие как Google, Facebook и Microsoft, постоянно ищут талантливых инженеров, способных создавать интуитивно понятные и высокопроизводительные приложения. В этой динамичной среде, где на кону стоят инновации, необходимо постоянно обновлять свои знания и навыки, особенно в таких популярных языках, как Python, Java и JavaScript. В этой статье мы рассмотрим ряд советов для разработчиков ПО, которые помогут вам улучшить свои навыки программирования и не только. Мы обсудим важность практики, участие в сообществах, использование различных инструментов и технологий, а также лучшие подходы к архитектуре программного обеспечения.

Каковы лучшие практики программирования на Python?

При программировании на Python лучше всего придерживаться принципов чистого кода, что подразумевает создание удобочитаемого и понятного кода. Использование комментариев и документации, таких как docstrings, помогает другим разработчикам (и вам самим) быстрее понять логику программы. Также стоит придерживаться стандартов PEP 8, которые предоставляют рекомендации по стилю кода в Python.

Не менее важной практикой является написание тестов. Использование фреймворков, таких как pytest или unittest, позволяет уверенно выполнять рефакторинг кода, зная, что функциональность остается неизменной. Внедрение тестирования может повысить качество вашего кода и упростить поиск ошибок.

Как участие в сообществах может помочь разработчикам?

Участие в сообществах для разработчиков, таких как Stack Overflow, GitHub или различные форумы, позволяет не только получать помощь от более опытных коллег, но и делиться своими знаниями. Обсуждение сложных задач, обмен опытом и сотрудничество с другими разработчиками — это отличные способы углубить свои знания и расширить кругозор.

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

Какие инструменты и технологии важны для современных разработчиков?

Современным разработчикам стоит обратить внимание на системы контроля версий, такие как Git. Они позволяют отслеживать изменения в коде и управлять совместной работой над проектами. Это особенно важно в командах, где может быть множество сотрудников, работающих над одним проектом.

Также использование среды разработки (IDE) или текстового редактора с поддержкой расширений, например, PyCharm или VS Code, существенно ускоряет процесс программирования. Эти инструменты предоставляют множество функций, включая автозавершение кода, отладку и интеграцию с системами контроля версий.

Как улучшить свои навыки работы с архитектурой программного обеспечения?

Чтобы стать более опытным в проектировании архитектуры программного обеспечения, стоит изучить основные паттерны проектирования, такие как MVC (Model-View-Controller), MVVM (Model-View-ViewModel) и микросервисную архитектуру. Понимание этих паттернов поможет вам выбрать правильный подход к разработке и улучшить структуру ваших проектов.

Чтение книг по архитектуре ПО и участие в курсах может также обогатить ваши знания. Практика и применение новых концепций в реальных проектах — это лучший способ освоить архитектурные решения.

Как оставаться в курсе новых трендов в программировании?

Следите за новыми языками, фреймворками и инструментами, посещая технологии и разработки на таких платформах, как Hacker News или GitHub Trends. Существуют также ресурсы, такие как Coursera и Udemy, которые предлагают курсы по самым последним технологиям.

Подписка на блоги и подкасты, посвященные программированию, также может стать отличным способом оставаться в курсе новых изменений и тенденций в мире разработки ПО.

Советы разработчикам (python и не только) Telegram Channel

Вы разработчик ПО или просто увлеченный программированием? Тогда канал "Советы разработчикам (python и не только)" идеально подойдет для вас! Здесь вы найдете полезные советы и рекомендации от @Tishka17 - опытного специалиста в области программирования.

В канале вы сможете не только узнать много нового о Python, но и получить ценные советы по созданию программного обеспечения, архитектуре ПО и многому другому.

Хотите поддержать развитие канала и его создателя материально? Присоединяйтесь к благотворительному фонду по ссылке https://www.tinkoff.ru/cf/2NkdXaljivI

Присоединяйтесь к каналу "Советы разработчикам (python и не только)" прямо сейчас, чтобы быть в курсе всех новостей и получать эксклюзивные советы от профессионала! Programming, python, software architecture и многое другое вас ждет на этом удивительном канале!

Советы разработчикам (python и не только) Latest Posts

Post image

float и Decimal

Вас никогда не удивляло, что 0.1 + 0.2 != 0.3? Почему float считает с погрешностями, и всем норм?

Дело в том, что 0.1 выглядит как

0 0111111101 11001100110011001100110011001100110011001100110011010.

Где:
0 обозначает знак +1 обозначает -)
0111111101 обозначает exponent, равную 0^10 + 2^9 + 2^8 + 2^7 + 2^6 + итд = 1019. Вычтем 1023 (размерность double) и получим итоговое значение: 1019 - 1023 = 4
11001100110011001100110011001100110011001100110011010 обозначет "significand" или "мантису", которая равна: 2^-exp + 2^-exp-1 + 2^-exp-2 + итд ~= 0.1

Вот так мы можем примерно представить 0.1 в виде float. Примерно – потому что все вычисления идут с погрешностью. Мы можем проверить данное утверждение, добавив погрешность вручную:

>>> assert 0.1 + 2.220446049250313e-18 == 0.1

Значение внешне не изменилось при добавлении погрешности. Посмотрим на sys.float_info.epsilon, который устанавливает необходимый порог для минимальных отличий 1.0 от следующего float числа.

>>> import sys
>>> sys.float_info.epsilon
2.220446049250313e-16
>>> assert 1.0 + sys.float_info.epsilon > 1.0
>>> assert 1.0 + 2.220446049250313e-17 == 1.0 # число меньше epsilon

Как конкретно будет выглядеть 0.1? А вот тут нам уже поможет Decimal для отображения полного числа в десятичной системе:

>>> decimal.Decimal(0.1)
Decimal('0.1000000000000000055511151231257827021181583404541015625')

И вот ответ про 0.1 + 0.2, полное демо с битиками:

>>> decimal.Decimal(0.1)
Decimal('0.1000000000000000055511151231257827021181583404541015625')
>>> decimal.Decimal(0.2)
Decimal('0.200000000000000011102230246251565404236316680908203125')

>>> decimal.Decimal(0.1 + 0.2)
Decimal('0.3000000000000000444089209850062616169452667236328125')

>>> decimal.Decimal(0.3)
Decimal('0.299999999999999988897769753748434595763683319091796875')

Числа не равны друг другу, потому что их разница больше предельной точности float. А сам Decimal может использовать любую точность под задачу.

>>> from decimal import Decimal, getcontext
>>> getcontext().prec = 6
>>> Decimal(1) / Decimal(7)
Decimal('0.142857')

>>> getcontext().prec = 28
>>> Decimal(1) / Decimal(7)
Decimal('0.1428571428571428571428571429')

Но и Decimal не может в абсолютную точность, потому что есть в целом невыразимые в десятичной системе числа, такие как math.pi, , тд. С чем-то из них может помочь fractions.Fraction для большей точности, но от существования иррациональных чисел никуда не деться.

Почему всем норм, что у нас с float такие погрешности в вычислениях? Потому что во многих задачах абсолютная точность недостижима и не имеет смысла. Благодаря плавающей точке мы можем хранить как очень большие, так и очень маленькие числа без существенных затрат памяти. А ещё float - очень быстрый. В том числе за счет аппаратного ускорения.

» pyperf timeit -s 'a = 0.1; b = 0.2' 'a + b'
.....................
Mean +- std dev: 8.75 ns +- 0.2 ns

» pyperf timeit -s 'import decimal; a = decimal.Decimal("0.1"); b = decimal.Decimal("0.2")' 'a + b'
.....................
Mean +- std dev: 27.7 ns +- 0.1 ns

Разница в 3 раза.

Про то, как устроен float внутри – рассказывать не буду. У Никиты Соболева недавно было большое и подробное видео на тему внутреннего устройства float. У него действительно хороший технический контент, советую подписаться: @opensource_findings

Итого
Если у вас нет требований по работе именно с десятичной записью числа (как, например, в бухгалтерии), то используйте float. Он даст достаточную точность и хорошую скорость. Если вы хотите, чтобы расчеты велись в десятичных цифрах и ваши расчеты построены так, что абсолютная точность достижима, то используйте Decimal.

Дополнительные материалы:
• https://www.youtube.com/@sobolevn/
• https://0.30000000000000004.com
• https://en.wikipedia.org/wiki/X87
• http://aco.ifmo.ru/el_books/numerical_methods/lectures/app_1.html

20 Feb, 09:34
3,498
Post image

Паттерны работы с базами данных

В большинстве проектов мы храним какие-то данные. Для этого используются разные виды баз данных: реляционные, nosql или даже специализированные HTTP API. Такие хранилища имеют специфическое API, которое мы обычно хотим скрыть от основного кода за некоторой абстракцией. Вот стандартные варианты, описанные, в частности, Мартином Фаулером.

Первая группа паттернов работы с БД - отделяющие реализацию операций с хранилищем от данных. Благодаря такому разделению, мы можем построить несколько реализаций шлюза, возвращающих однотипные структуры (например, для заглушек на время тестирования или использования нескольких источников данных). Обратите внимание, что в паттернах этой группы мы можем полностью скрыть детали организации хранилища.

DAO - наиболее простой вариант, он представляет собой достаточно тупой класс, который просто выполняет операции с хранилищем и возвращает данные в том или ином виде. Он не должен содержать какого-то своего состояния (будь то кэши или IdentityMap). Он получает и возвращает только данные в виде неких абстрактных RecordSet или простых DTO, то есть структур, не содержащих логики. Плюсы такого паттерна: простота реализации, возможность точечного тюнинга запросов. Паттерн описан в "Core J2EE Patterns", а у Фаулера встречается очень близкое описание под именем Table Data Gateway.

Data Mapper - в отличие от DAO занимается не просто передачей данных, а двусторонней синхронизацией моделей бизнес логики с хранилищем. То есть он может загружать какие-то сущности и потом сохранять их обратно. Внутри он может содержать IdentityMap для исключения дублей модели с одним identity или создания лишних запросов на загрузку. Каждый маппер работает с моделью определенного типа, но в случае составных моделей он иногда может обращаться к другим мапперам (например, при использовании select-in load). При использовании Unit Of Work, тот обращается именно к мапперу для сохранения данных.

Repository - фактически вариант Data Mapper, предназначенный для работы с корневыми сущностями. Для прикладной бизнес логики репозиторий выглядит как коллекция, содержащая корни агрегатов. Он может использоваться для получения полиморфных моделей, а также может возвращать некоторую сводно-статистическую информацию (например, количество элементов или сумму полей) или даже выполнять какие-то расчеты, не выходящие за пределы общей компетенции хранилища данных. Это основной паттерн при использовании богатых доменных моделей. Паттерн описан у Эрика Эванса, а у Фаулера встречаются некоторые варианты его реализации.

Вторая группа - паттерны, смешивающие данные и работу с хранилищем. Их использование может усложнить тестирование или изменение кода, но, тем не менее, они используются.

Raw Data Gateway - предлагает каждой строке таблицы поставить в соответствие экземпляр класса. Мы получаем отдельный класс Finder для загрузки строк и собственно класс шлюза строки, который предоставляет доступ к загруженным данным и обладает методами сохранения себя в БД.

Active Record - вариант RDG, но содержащий бизнес логику. По факту, мы имеем богатые доменные модели не абстрагированные от хранилища. Часто методы загрузки данных реализованы просто как static-методы в этом же классе вместо выделения отдельного Finder.

Строит отметить, что многие ORM в Python реализуют Active Record и активно используют при этом неявный контроль соединений и транзакций. В отличие от них SQLAlchemy реализует паттерн Data Mapper и может дать больший уровень абстракции над хранилищем (обратите внимание на подход с map_imperatively).

Дополнительные материалы:
• http://www.corej2eepatterns.com/Patterns2ndEd/DataAccessObject.htm
• https://martinfowler.com/eaaCatalog/identityMap.html
• https://docs.sqlalchemy.org/en/20/orm/dataclasses.html#applying-orm-mappings-to-an-existing-dataclass-legacy-dataclass-use

03 Jan, 16:03
10,857
Post image

Data Transfer Object

Когда мы общаемся с удаленным кодом (посылаем запросы, сообщения), пересылаемые данные в коде зачастую удобнее передавать совместно и представлять не в виде отдельных параметров методов, а в виде некоторой структуры. Она называется DTO - Data Transfer Object (объект передачи данных).

DTO - любой объект/структура данных без своей логики, пригодная для сериализации для передачи по сети. При этом не обговаривается как именно она будет сериализована - она может содержать специальные методы, или этим может заниматься отдельный код (на основе интроспекции, макросов или как угодно).

DTO - это, в первую очередь, назначение объекта. Это данные, которые надо передать. Могут иметься в виду входящие, так и исходящие данные.

1. Для существования DTO не требуется наличие каких-либо доменных моделей, это любые данные. Они могут собираться из других DTO, нескольких бизнес-сущностей или вообще генерироваться на ходу
2. Сериализация возможна в совершенно разные форматы (например: xml, json, protobuf). При это не обязательно использование одного DTO под несколько форматов
3. DTO может использоваться в разных адаптерах приложения: для данных, возвращаемых или принимаемых обработчиком сервера, из клиентов внешних апишек, как результат работы DAO и т.п. В целом, структуры, передаваемые между слоями приложения без удаленных вызовов, могут тоже называться DTO.
4. Если DTO содержит логику сериализации, мы обязаны ограничивать его использование на внешнем слое приложения. То есть, при возврате данных из интерактора мы должны логику их сериализации вынести наружу.
5. DTO не содержит логики, но содержит информацию об структуре данных и общеизвестных типах. Парсер DTO может содержать какие-то универсальные предохранители от загрузки слишком больших данных. Но, например, кастомизация длины строки или допустимого диапазона чисел на каждое поле - однозначно будет ошибкой.
6. DTO на сервере и клиенте могут иметь совершенно разную реализацию и она может меняться независимо, однако структура данных должна быть согласована. Изменение формата представления данных, состава полей и типов на отправителе потенциально могут сломать логику получателя данных и поэтому должны делаться аккуратно.

В качестве примеров объектов, которые можно использовать в качестве DTO можно назвать датаклассы (в python или kotlin). При этом, например, Pydantic-модели, из-за наличия логики сериализации в них самих, должны оставаться на уровне адаптеров (view-функций, обработчиков запросы) и не должны переиспользоваться между адаптерами совершенно разного назначения.

Дополнительные материалы:
• https://martinfowler.com/eaaCatalog/dataTransferObject.html
• https://docs.python.org/3/library/dataclasses.html
• https://www.oracle.com/technical-resources/articles/java/javareflection.html
• https://go.dev/blog/laws-of-reflection

27 Nov, 19:32
10,846
Post image

Полиморфизм при наследовании и LSP.

Когда мы строим иерархию объектов, мы часто делаем одноименные методы с разным поведением. Если в родительском классе такой метод отсутствует, то мы в целом вольны в наследниках делать что захотим.

Если же родительский класс содержит такой метод, то у нас есть следующие варианты:

1. Реализация в дочернем классе полностью сохраняет внешнее поведение метода (параметры, результат, побочные эффекты), но отличается реализацией и как следствие нефункциональными характеристиками (например, производительностью). В этом случае классы полностью взаимозаменяемы.
2. Реализация в дочернем классе полностью сохраняет поведение родительского класса, но делает дополнительную работу или меняет поля, отсутствующие в родительском классе. Мы все также можем использовать дочерний класс там, где ожидается родительский, но в других частях программы мы получаем дополнительные возможности.
3. Мы меняем поведение метода родительского класса, но не нарушаем его важные характеристики. В этом случае мы должны четко понимать, какие требования есть к базовому методу, чтобы не нарушить совместимость. Если мы не соблюдаем принцип инверсии зависимости и базовый класс не является абстрактным, может получиться, что требования к методу слишком конкретные и тогда этот вариант фактически сводится к предыдущему. При этом мы можем расширять область значений параметров метода (снимая некоторые ограничения или переходя к родительским типам), а иногда и сужать область значений результата.
4. Мы сохраняем формальные характеристики метода (сигнатуру, возвращаемое значение), но сильно меняем его поведение. Как правило, это происходит когда требования к методу не выделены или по ошибке. В этом случае инструменты, предоставляемые языком программирования, могут предполагать что методы все ещё совместимы, что не является правдой на самом деле.
5. Мы меняем даже сигнатуру метода несовместимым образом. Например, произвольно меняем тип результата или параметров, но не так как в п.3. Класс однозначно нельзя использовать там, где ожидается родительский и это могут обнаружить автоматические инструменты.

Если мы наследуемся от какого-то объекта, согласно принципу подстановки Барбары Лисков (LSP) мы не должны нарушать совместимость. То есть, если в каком-то коде ожидается экземпляр базового класса, а мы туда подставляем дочерний, код должен работать корректно и согласно нашим ожиданиям.

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

Может показаться, что в точности соблюдая требования, мы лишаемся полиморфизма, однако это не так. Обратите внимание на предложенные выше варианты. (Пример в комментариях)

Таким образом,
• LSP требует совместимости между родительским и дочерними классами на уровне выполнения требований.
• Дочерний объект должен сохранять ожидаемое поведение всегда, после вызова любых методов, включая отсутствующие у родителя.
• Дочерний объект должен проходить тесты, ожидающе экземпляр базового класса
• Использование абстракций позволяет нам добиться большей гибкости при реализации дочерних классов
• Даже при конкретных требованиях у нас есть альтернативные варианты реализации

Дополнительные материалы:
• https://news.mit.edu/2009/turing-liskov-0310
• https://ru.wikipedia.org/wiki/Абстрактный_тип_данных
• https://t.me/advice17/58
• https://en.wikipedia.org/wiki/Dependency_inversion_principle

14 Oct, 07:37
12,776