Pull to refresh
  • by relevance
  • by date
  • by rating

Принцип самурая

Designing and refactoring *
В мире разработки софта существует много идей и «метафор», позаимствованных из других, казалось бы, не сильно связанных с программированием областей. Можно вспомнить паттерны проектирования, позаимствованные у архитекторов, или понятие «технического долга», пришедшее из финансовой индустрии, да и «эффектом второй системы» страдают проектировщики любых систем, а не только программных (*). Все это упрощает коммуникацию между разработчиками или между разработчиками и заказчиками, а также упрощает понимание той или иной проблемы в разработке ПО.

Еще одной метафорой, или скорее принципом разработки, является «принцип самурая», призванный описать «контракт» между функцией и вызывающим ее кодом и заключается в следующем. Любая функция, реализующая некоторую единицу работы должна следовать тому же кодексу чести «бусидо», по которому живет любой самурай. Так, самурай не будет выполнять никаких заданий, противоречащих его «кодексу чести» и если к нему подойти с «непристойным» предложением, то он снесет вам башку раньше, чем вы успеете глазом моргнуть. Но если уж самурай возьмется за дело, то можно быть уверенным в том, что он доведет его до конца (**).
Читать дальше →
Total votes 64: ↑60 and ↓4 +56
Views 6.3K
Comments 40

Идеальная архитектура

Designing and refactoring *
Существует много разных взглядов на разработку архитектуры и дизайна современных приложений. Некоторые архитекторы стремятся продумать все до мелочей, разрисовать use case-ы всех классов и модулей, проанализировать миллион возможных способов их использования, все их обязательно задокументировать и уже потом приступить к этапу кодирования.

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

Читать дальше →
Total votes 61: ↑50 and ↓11 +39
Views 52K
Comments 22

Progressive Enhancement или всё-таки Graceful Degradation

Website development *Designing and refactoring *
SerenityНельзя просто так взять и рассказать про progressive enhancement, не упомянув о graceful degradation. В чем же разница между этими понятиями? Как уже говорилось в более ранней статье, graceful degradation можно перевести, как отказоустойчивость. Это очень широкое понятие, но в контексте веба его можно понимать как отказоустойчивость клиентских веб-интерфейсов, серверной части сайтов и так далее. В этой статье graceful degradation будет пониматься как отказоустойчивость клиентских веб-интерфейсов.

Graceful degradation может выражаться в возможности работы при отключенном JavaScript, в достаточно аккуратном отображении интерфейса в браузере, не поддерживающем новые свойства CSS3, в адекватном отображении сайта при отключенных изображениях. В каждом из этих случаев работа пользователя с интерфейсом будет в принципе возможна, хотя и не так удобна.
Читать дальше →
Total votes 39: ↑38 and ↓1 +37
Views 86K
Comments 49

Так ли дорого прогрессивное улучшение?

Website development *Designing and refactoring *

В предыдущей статье рассматривалась теория и практика прогрессивного улучшения (progressive enhancement). В этой статье мы от идеологии перейдем к аксиологии и рассмотрим финансово-экономическую обоснованность применения прогрессивного улучшения.

В некоторых комментариях к предыдущей статье выражалось мнение, что использовать прогрессивное улучшение в реальной разработке не стоит. Причины сводились к излишней дороговизне: «На то, чтобы создать сайт в соответствии с этим подходом, нужно потратить слишком много времени, а это слишком дорого и не нужно ни заказчику (за такие деньги), ни исполнителю».
Читать дальше →
Total votes 30: ↑27 and ↓3 +24
Views 15K
Comments 18

О бедном C++ API замолвите словцо!

Programming *C++ *API *
Tutorial
Желание написать об C++ API у меня возникло давно, и вот наконец выдался спокойный вечер. По роду деятельности я и мои ребята пишем код на C++ для программистов на C++ и Python, общее ядро функционала, который используется во всех продуктах нашей компании. Разумеется это подразумевает, что код должен иметь интуитивно понятный API, с общей логикой как для низкоуровневого C++, так и для высокоуровневого Python, вне зависимости от разночтения в языках некоторых базовых конструкций. Об объединении C++ и Python я много писал ранее в статьях про Boost.Python, сейчас я очень благодарен архитектуре и логике языка Python, я многое понял и перенял в С++ именно благодаря опыту построения общего API для этих двух таких разных языков, но сейчас речь пойдёт только и исключительно о C++, про API и про то, что такой зверский гибкий язык позволяет сделать с интерфейсом вашей замечательной библиотеки, если не учитывать ряд важных особенностей языка C++.
Читать дальше →
Total votes 38: ↑29 and ↓9 +20
Views 37K
Comments 71

KISS — принцип проектирования, содержащий все остальные принципы проектирования

Programming *Designing and refactoring *
Постараюсь объяснить сущность принципа проектирования KISS просто и одновременно очень подробно. KISS – это очень общий и абстрактный принцип проектирования, который содержит в себе практически все остальные принципы проектирования. Принципы проектирования описывают как писать «хороший» код. Однако что значит хороший код? Некоторые считают, что это код, который выполняется максимально быстро, некоторые – что это код, в котором задействовано как можно больше паттернов проектирования… Но верный ответ лежит на поверхности. Код – это информация в чистом виде. А основные критерии ценности информации – это 1)достоверность 2)доступность 3)понятность. То, почему важны достоверностью и доступность – очевидно. От кода нет проку, если он работает с ошибками или если сервер с приложением «лежит». Почему же важна понятность кода? В понятном коде проще искать ошибки, проще его изменять, дорабатывать и сопровождать. Итак, понятность – основная ценность, к которой должен стремиться программист. Однако тут есть одна неувязочка. Дело в том, что понятность – вещь сугубо субъективная.
Читать дальше →
Total votes 22: ↑9 and ↓13 -4
Views 47K
Comments 84

Управление API и SOA

GeekFamily corporate blog .NET *ASP *API *C# *
Translation
Достижение начального успеха для Сервис-ориентированной Архитектуры (Service Oriented Architecture, SOA) определяется:
  • созданием слабосвязанных соединений «потребитель-поставщик»,
  • соблюдение принципа разделения ответственностей между потребителем и поставщиком,
  • публикация набора повторно используемых, общих сервисов
  • и обеспечение того, чтобы потребители приняли и стали использовать сервис.

Множество команд разработчиков создают и используют сервисы, но до сих пор идет мучительный подбор архитектуры, при которой сервисы будут широко использованы, с потенциалом для повторного использования внутренними командами разработки. Вместо создания согласованной сервисной архитектуры и демонстрации множественного использования одних и тех же сервисов, разработчики вновь и вновь не нарочно создают «Просто Набор Веб Сервисов» (Just a Bunch of Web Services (JBOWS)) или «Просто Набор REST Сервисов» (Just a Bunch of REST Services (JBORS)).

Простое приложение чаще всего работает с неким сервисом и спагетти-сетью конечных точек, поставщиков данных этого сервиса, которые переплетены связями один-к-одному. Многие команды в этом случае сходятся во мнении что фокус на SOA и REST не то чтобы помогал в решении вопросов гибкости решений. Скорее просто происходит подмена набора IT инструментов, форматов сообщений и протоколов.

Управление SOA, API, и приложением может стать мостом между этими концепциями и улучшить архитектурную согласованность всего решения.

Сервисы, API и архитектура


Когда вы будете решать, что использовать как лучшие практики для сервис-ориентированной архитектуры, определять дизайн RESTful сервисов, когда будете формировать план по управлению ими, четко определите, как ваши сервисы и API вместе будут укладываться в общую архитектурную картину.
Читать дальше →
Total votes 14: ↑13 and ↓1 +12
Views 16K
Comments 2

Создание архитектуры программы или как проектировать табуретку

Website development *System Analysis and Design *Designing and refactoring *
Sandbox
Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.
Читать дальше →
Total votes 88: ↑85 and ↓3 +82
Views 542K
Comments 44

Околоархитектурные рассуждения или результаты одного спора

Zfort Group corporate blog Website development *Programming *C# *
В один прекрасный обыкновенный четверг в одной команде разработчиков появились разногласия по поводу некоторых архитектурных решений, реализация которых была утверждена приказом сверху, а не родилась в ходе аргументированного спора. По прошествии некоторого времени подобный спор возник опять, уже на новом проекте. Дискуссия становилась все жарче, и для прояснения ситуации и достижения просветления даже были привлечены сторонние высшие силы. Последнее достигнуто не было, и все же, тем же волевым решение, был принят один из вариантов развития бытия. Но мудрый Каа один из участников обсуждения решил не оставлять в команде неразрешенных споров — почвы для возникновения конфликтов в будущем, раскола команды и другого мордобития, и предложил все решить всеобщей пьянкой составлением данного документа, который поможет членам команды достичь просветления и снова стать мягкими и пушистыми.
В данном документе мне было предложено описать преимущества и недостатки двух подходов, достичь консенсуса и воцарить мир и справедливость во Вселенной.
Ниже я и попытаюсь в меру своих интеллектуальных возможностей это сделать (поэтому буду использовать очень простые слова и выражения) и вынести на суд кровавых мясников почтенной публики.
Читать дальше →
Total votes 12: ↑10 and ↓2 +8
Views 13K
Comments 24

Манифест разработчика умных систем: 15 принципов

Samsung corporate blog Interfaces *Development for IOT *Smart House IOT
Мы предлагаем вашему вниманию статью Владислава Зайцева (vvzvlad), приглашенного гостя нашего блога. Владислав давно занимается темой «умных домов», и обобщив свой опыт, он предлагает следующие основные принципы дизайна такого рода систем.

Сегодня я хочу поговорить с вами об «умных» домах в частности и IoT-устройствах в целом. Но это будет не обычная статья: тут не будет железок, ссылок на производителей, кусков кода и репозитариев на гитхабе. Сегодня мы будем обсуждать нечто более высокоуровневое — принципы, по которым организуются «умные» системы.

image

Продолжая читать статью, вы соглашаетесь с тем, что вас устраивает следующий disclaimer.

Собственно, сам disclaimer
  1. Все эти пункты касаются только потребительских IoT-систем (читай «умных домов»). Тех, что человек может купить в магазине и установить без привлечения специализированных инсталляторов/интеграторов.
  2. Часть этих принципов не применима к промышленным системам (там свои требования и принципы), а также, к системам, где есть отделённые от пользователя эксплуатанты (например, умный дом, который устанавливается и обслуживается специально обученными людьми).

    Также часть принципов не применима к системам уровня «игрушка для гиков», к самодельным и open-source системам, у которых нет единого product owner.
  3. И, конечно, всё написанное ниже — это исключительно моё мнение, основанное на моём многолетнем опыте. Вы имеете право не соглашаться с ним.



Умный дом — это система, которая берёт на себя часть повседневных забот человека. Отсюда следует первый и самый основной принцип:
Читать дальше →
Total votes 55: ↑52 and ↓3 +49
Views 21K
Comments 98

Размышления о Манифесте разработчика умных систем

Interfaces *Development for IOT *Smart House IOT
Sandbox

Несколько дней назад я прочитал отличную статью "Манифест разработчика умных систем: 15 принципов"


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


Ввиду природы поста, он будет еще более субъективным, чем Манифест.

Читать дальше →
Total votes 13: ↑13 and ↓0 +13
Views 3.2K
Comments 0

Как не понимать принципы развития архитектуры SOLID

Programming *System Analysis and Design *Designing and refactoring *
Sandbox

Есть проблема с описанием и толкованием принципов развития архитектуры SOLID (авторства Роберта Мартина). Во многих источниках дается их определение и даже примеры их использования. Изучая их и пробуя использованием примерить на себя, стабильно ловил себя на мысли, что не хватает объяснения магии их применения. И пытаясь увидеть внутренние шестеренки, понять — и для меня значит запомнить — разложил их по своим "терминам-полочкам". Хорошо если это будет полезно еще кому-нибудь.


image

Читать дальше →
Total votes 27: ↑23 and ↓4 +19
Views 20K
Comments 14

Всё как в жизни: законы проектирования космических кораблей

System Analysis and Design *Designing and refactoring *IT Standards *Robotics development *Design
Translation

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

Читать далее
Total votes 30: ↑27 and ↓3 +24
Views 6.2K
Comments 5

Актуальность принципов SOLID

Programming *Perfect code *Designing and refactoring *
Translation

Впервые принципы SOLID были представлены в 2000 году в статье Design Principles and Design Patterns Роберта Мартина, также известного как Дядюшка Боб. 

С тех пор прошло два десятилетия. Возникает вопрос - релевантны ли эти принципы до сих пор?

Перед вами перевод статьи Дядюшки Боба, опубликованной в октябре 2020 года, в которой он рассуждает об актуальности принципов SOLID для современной разработки.   

Недавно я получил письмо с примерно следующими соображениями:

Годами знание принципов SOLID было стандартом при найме. От кандидатов ожидалось уверенное владение этими принципами. Однако позже один из наших менеджеров, который уже почти не пишет код, усомнился, разумно ли это. Он утверждал, что принцип открытости-закрытости стал менее важен, так как по большей части мы уже не пишем код для крупных монолитов. А вносить изменения в компактные микросервисы - безопасно и просто.

Принцип подстановки Лисков давно устарел, потому что мы уже не уделяем столько внимания наследованию, сколько уделяли 20 лет назад. Думаю, нам стоит рассмотреть позицию Дена Норса о SOLID - “Пишите простой код”

Читать далее
Total votes 48: ↑42 and ↓6 +36
Views 34K
Comments 87

Не Tesla. Что это может быть?

Popular science Transport Ecology The future is here
Tutorial

Как часто вы слышите выражение «убийца Теслы»? А потом на самом деле получается по набору технологий и принципов практически та же Тесла?

В этой статье я пойду от обратного — возьму основные известные факты об компании Илона и попытаюсь их «переиграть», чтобы представить потенциального конкурента(анти-теслу)!

№1

Факт первый и самый известный — название фирмы определяет конструкцию. Электромотор у теслы на основе переменного тока.

Антагонист настоящего Теслы(который ученый, а не машина) был Эдисон — сторонник постоянного тока. Следовательно, выбор только один — электродвигатели постоянного тока.

Такие электромоторы делятся на две категории, и имеют ряд преимуществ.

Первые коллекторные электродвигатели, известные наличием щеток внутри, от которых вытекают многие их недостатки потом.

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

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

№2

Общеизвестно, что практически все электромобили Теслы не имеют обычной коробки передач (за исключением первого родстера, но классическим вариантом КПП его не назовешь).

Читать далее
Total votes 6: ↑4 and ↓2 +2
Views 5.9K
Comments 18

Как разработчику применять принципы лидерства Amazon

Programming *Amazon Web Services *IT career IT-companies
Translation

Добрый день, меня зовут Павел Поляков, я Principal Engineer в каршеринг компании SHARE NOW, в Гамбурге в 🇩🇪 Германии. А еще я автор телеграм канала Хороший разработчик знает, где рассказываю обо всем, что обычно знает хороший разработчик.

Сегодня хочу поговорить о принципах лидерства в Amazon. Это перевод оригинальной статьи.

Amazon является одной из самых больших и дорогих технологических компаний в мире. На Amazon работают десятки тысяч разработчиков. Все они получают хорошую компенсацию от 150.000$ в год и выше. Удивительно, но вся внутренняя политика Amazon основывается всего лишь на 16 принципах. 16 коротких фраз, которые определяют как ведет себя хороший сотрудник в Amazon.

Давайте посмотрим что это за принципы и как они помогают разработчикам в Amazon быть наиболее продуктивными.

Читать далее
Total votes 19: ↑13 and ↓6 +7
Views 6.4K
Comments 25