codingblog

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

Don’t Repeat Yourself (DRY) — Не повторяйся!

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

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

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

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

Occam’s Razor (OR) — Бритва Оккама

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

Keep It Simple Stupid (KISS) — Делай это проще

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

You Aren’t Gonna Need IT (YAGNI) — Вам это не понадобится

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

Big Design Up Front (BDUF) — Масштабное проектирование прежде всего

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

Avoid Premature Optimization (APO) — Избегайте преждевременной оптимизации

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

Principle Of Least Astonishment (POLA) — Принцип наименьшего удивления

Данный принцип гласит, что ваш исходный код должен быть интуитивно понятен, очевиден, и как можно меньше удивлять другого программиста, во время чтения листинга. Это означает, что если в метод называется «Сделать автомобиль», а в результате получается мотоцикл, это плохая идея и плохой код. На самом деле я сейчас конечно утрирую, но в любом случае, ваши методы должны делать только то, что можно понять из их названия. А имена должны быть наиболее как можно более информативными, но при этом лаконичными. Не нужно писать в имя переменно целое предложение, но и называть ее одной буквой тоже не стоит. Стремитесь к тому, чтобы написанный вами код можно было читать как книгу.

Law of Demeter (LOD) — Закон Деметры

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

- Классы должны быть самостоятельными

- Нужно стараться сократить количество связей между различными классами

- Классы должны быть выстроены иерархически

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

Благодаря соблюдению данного принципа приложения становится более гибким и понятным.

Заключение

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

Источник: CODE BLOG

Сегодня вряд ли найдется человек, который не слышал бы о великолепной нейронной сети, что научилась писать стихи или роботах, которые подсматривают за людьми, чтобы чему-то научиться. То есть электронные мозги обучаются, самосовершенствуются и будто бы даже растут. Но является ли это интеллектом?

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

Итак, что же делает так называемый ИИ (искусственный интеллект)? На основе данных, предусмотренных разработчиком и в рамках поставленной задачи. Трудно спорить, наука сделала гигантский шаг в области систематизации и цифровой обработки данных. И, как уже говорилось ранее, разрабатываемые программы могут писать стихи, сочинять музыку и решать достаточно сложные задачи. Другой вопрос состоит в том, насколько интеллектуальной можно считать сию деятельность. По сути, любая подобная программа обучается на огромных, даже гигантских, массивах данных, притом данных строго систематизированных. На этапе обучения ИИ за ним наблюдает команда разработчиков, которые внимательно следят за «усвоением» этих данных. И только потом, опираясь на слог сотен поэтов и словарный запас, коим вряд ли обладал хоть один из писателей (десятки, а то и сотни справочников), система начинает подбирать слова и обороты из тех, что уже неоднократно использовались… С музыкой все обстоит точно так же. Загрузка и обработка огромных массивов данных с последующей имитацией интеллектуальной деятельности.

Что же до решения сложных задач и адаптации к внешним условиям, ни одна нейронная сеть из тех, что существует сегодня, не способна адаптироваться к быстро изменяющимся условиям. Хотя, оно на самом деле и логично, учитывая, что любая «нейросеть» строится на простейших сумматорах и одной, а в сложнейшем случае, нескольких математических формулах, что никак не может заменить нейрон природный, способный создавать новые связи, адаптироваться к изменениям состояния организма и, увы, погибать.

Кроме того, следует заметить интересную особенность. Процессы обмена информацией в нашем организме происходят значительно медленнее, чем в компьютерах. То есть, фактически даже самый слабый ИИ должен превосходить человека. Однако упс, Джарвиса собрать так и не вышло. Да что там Джарвиса, даже Терминатор пока не родился, и вряд ли родится ближайшие несколько десятилетий. А все потому, что при всей своей скорости железки все еще слишком прямолинейны. Они обрабатывают один, два, может десять потоков – зависит от таланта разработчика. В то время как человеческий мозг 24 / 7 обрабатывает сотни информационных потоков и генерирует тысячи реакций ежесекундно.

И лично я все чаще прихожу к выводу, что на данном этапе развития технологий искусственный интеллект является чем-то вроде «Прекрасного далека», когда-нибудь, быть может мы и придем к этому, но сегодня это фантастика, которую пытаются выдать за действительность.

Источник: Дзен CODE BLOG

Идея паттерна проектирования Состояние (State)

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

Существует три вида паттернов проектирования:

1. Порождающие паттерны позволяют возможность выполнять инициализацию объектов наиболее удобным и оптимальным способом.

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

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

Состояние (State) — это поведенческий паттерн, который предоставляет возможность экземпляру класса самостоятельно регулировать свое поведение, ориентируясь на его текущее внутреннем статусе. То есть, при изменении каких-либо внутренних значений класс может кардинально изменять свое поведение.

Архитектура паттерна Состояние (State)

Давайте рассмотрим UML диаграмму данного поведенческого паттерна

1. Widget — основной объект, поведение которого изменяется в зависимости от его текущего состояния;

2. IState — базовый интерфейс для всех возможных состояний объекта;

3. State1, State2 — конкретные состояния объекта, влияющие на его поведение.

Логика работы паттерна Состояние (State)

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

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

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

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

P.S. Я не претендую на правильность, оптимальность и красоту реализации. Единственная цель, которую я преследую, поделиться полезной информацией о программировании, которая может кому-то пригодиться.

Источник: https://shwan.ru/state/