Рубрика «принципы»

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

При разработке нашей формы мы будем следовать принципам «KISS», «YAGNI», «DRY». Для успешного прохождения данного туториала вам не нужно знать этих принципов, я буду объяснять их по ходу дела.Читать полностью »

Законы, теории, принципы и закономерности, полезные для разработчиков

Введение

Перевод репозитория github.com/dwmkerr/hacker-laws

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

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

Законы

Закон Амдала

Закон Амдала — это формула, демонстрирующая потенциал ускорения вычислительной задачи, которого можно достичь при увеличении количества ресурсов системы. Обычно он используется в параллельных вычислениях, и может предсказать наличие реальных преимуществ от увеличения количества процессоров с учётом ограничений параллелизуемости программы.
Читать полностью »

Давайте глянем на определение принципа инверсии зависимостей из википедии:

Принцип инверсии зависимостей (англ. dependency inversion principle, DIP) — важный принцип объектно-ориентированного программирования, используемый для уменьшения связанности в компьютерных программах. Входит в пятёрку принципов SOLID.

Формулировка:

A. Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
B. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Большинство разработчиков, с которыми мне доводилось общаться, понимают только вторую часть определения. Мол "ну а что тут такого, надо завязывать классы не на конкретную реализацию а на интерфейс". И вроде бы верно, но только кому должен принадлежать интерфейс? Да и почему вообще этот принцип так важен? Давайте разбираться.

Читать полностью »

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

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

12 неписаных правил в дизайне - 1

1. Узнайте, что на самом деле хочет ваш клиент

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

Читать полностью »

image
В этой статье я привожу примеры основных принципов или концепций, которыми руководствуюсь при проектировании десктопных интерфейсов. Не планирую выступать новатором или поучителем, но с радостью поделюсь набором установок, который помогает мне в работе.Читать полностью »

Добрый день, уважаемые друзья. Рад представить на ваше обсуждение мое видение технологии создания фирмы. Первая статья — определение миссии, целей и принципов компании. Ведь без них никуда, правда?
Читать полностью »

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

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

Принципы условно сгруппированы в три группы: принципы принятия решений; принципы, направленные на повышение качества кода; принципы, направленные на повышение производительности кода.

  • Принятие решений
    • Любое техническое решение должно быть обосновано
    • Ответственность за принятое решение всегда лежит на том или тех, кто принял данное решение
    • При принятии технических решений необходимо учитывать их действие во времени и их соответствие потребностям бизнеса
    • Одним из основных критериев при принятии технических и иных решений должна быть их наибольшая эффективность
    • Смело отступать от правил, методологий, шаблонов и прочих ограничений, если эффект от такого отступления превышает возможные потери (Special cases aren't special enough to break the rules, although practicality beats purity)
    • При необходимости сделать работающее, но, возможно, не наилучшее, решение сразу, а позднее улучшить его (Now is better than never, although never is often better than *right* now)
    • Если сложно выбрать между двумя альтернативными техническими решениями, то нужно выбрать любое и двигаться с ним дальше, когда появится больше инфорации, то можно будет сделать рефакторинг, если решение оказалось неоптимальным
    • Гибкость технических решений крайне желательна, а универсальность не обязательна
  • Качество исходного кода
    • Качество кода следует оптимизировать на базе сформированной системы критериев, сбалансированной по отношению к затратам в краткосрочном и долгосрочном периодах
    • Писать оптимальный код сразу, если это не увеличивает его сложность и сроки разработки (Beautiful is better than ugly)
    • Самодокументируемый код имеет приоритет над хорошо прокомментированным (Beautiful is better than ugly)
    • Писать TODO и FIXME в коде
    • Давать переменным, функциям, методам, классам и другим объектам исходного кода имена точно отражающие их назначение, несмотря на увеличение длины названий (Explicit is better than implicit)
    • Меньшее число строк и объем кода предпочтительнее, при сохранении прежней читабельности кода (Simple is better than complex)
    • Применять инспекцию кода (code review) как инструмент обнаружения ошибок, выравнивания стиля разработки, знакомства с чужим кодом и обучения в команде
    • Применять повторное использование своего и чужого кода
    • Использовать специализированные библиотеки для решения конкретных задач, вместо разработки своего аналогичного кода
  • Производительность
    • Производительность разработки кода имеет приоритет над производительностью исполнения кода
    • Оптимизация производительности исполнения кода должна быть обоснована соответствующей потребностью
    • Оптимизация производительности исполнения кода должна выполняться за счет устранения наиболее серьезных узких мест
    • В первую очередь должны быть использованы наиболее эффективные методы оптимизации производительности исполнения кода

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

image

Дорогие друзья!

Рады снова приветствовать вас.

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

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

Читать полностью »

imageПреамбула

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

Читать полностью »

Позвольте представить вам, уважаемые читатели, мой телефон!
Чемпионат заслуженных вещейУдостоить его такой чести решаюсь не только потому, что мое почтение к этому труженику коммуникаций растет от года к году уже… почти 10 лет. Или больше. Точно сказать не могу, поскольку паспорт его канул в этом море лет безвозвратно, а память мне подсказывает, что обзавелся я им в первые годы тысячелетия. Зовут его Alcatel 411 — опять же, если мне не изменяет память.

Было бы странно утомлять внимание уважаемых читателей описанием теплого отношения к телефону, если бы из этой истории ничего не следовало — это я понимаю. Но позвольте мне продолжить начатый рассказ под клятвенное обещание чуть ниже все объяснить и поделиться идеей нового хорошо монетизируемого сервиса. Он может работать и самостоятельно, но мои надежды связывают его с возможностями первого этапа материализации замыслов «Солярисом» — «новым общественным институтом», представленном в хабратопике «Физика инноваций»Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js