Publications Hubs Companies Users Comments

SergeyT Sep 14 2011 at 00:03

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

3 min

6.8K

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

Еще одной метафорой, или скорее принципом разработки, является «принцип самурая», призванный описать «контракт» между функцией и вызывающим ее кодом и заключается в следующем. Любая функция, реализующая некоторую единицу работы должна следовать тому же кодексу чести «бусидо», по которому живет любой самурай. Так, самурай не будет выполнять никаких заданий, противоречащих его «кодексу чести» и если к нему подойти с «непристойным» предложением, то он снесет вам башку раньше, чем вы успеете глазом моргнуть. Но если уж самурай возьмется за дело, то можно быть уверенным в том, что он доведет его до конца (**).

Читать дальше →

+56

SergeyT Nov 24 2011 at 01:01

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

4 min

56K

Designing and refactoring *

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

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

Читать дальше →

+39

Mexos Nov 2 2012 at 12:47

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

6 min

90K

Website development *Designing and refactoring *

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

Graceful degradation может выражаться в возможности работы при отключенном JavaScript, в достаточно аккуратном отображении интерфейса в браузере, не поддерживающем новые свойства CSS3, в адекватном отображении сайта при отключенных изображениях. В каждом из этих случаев работа пользователя с интерфейсом будет в принципе возможна, хотя и не так удобна.

Читать дальше →

+37

meritt Dec 25 2012 at 15:07

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

7 min

16K

Website development *Designing and refactoring *

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

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

Читать дальше →

+24

Qualab Jul 11 2014 at 04:16

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

15 min

40K

Programming *C++ *API *

Tutorial

Желание написать об C++ API у меня возникло давно, и вот наконец выдался спокойный вечер. По роду деятельности я и мои ребята пишем код на C++ для программистов на C++ и Python, общее ядро функционала, который используется во всех продуктах нашей компании. Разумеется это подразумевает, что код должен иметь интуитивно понятный API, с общей логикой как для низкоуровневого C++, так и для высокоуровневого Python, вне зависимости от разночтения в языках некоторых базовых конструкций. Об объединении C++ и Python я много писал ранее в статьях про Boost.Python, сейчас я очень благодарен архитектуре и логике языка Python, я многое понял и перенял в С++ именно благодаря опыту построения общего API для этих двух таких разных языков, но сейчас речь пойдёт только и исключительно о C++, про API и про то, что такой ~~зверский~~ гибкий язык позволяет сделать с интерфейсом вашей замечательной библиотеки, если не учитывать ряд важных особенностей языка C++.

Читать дальше →

+20

FiresShadow Feb 3 2015 at 20:45

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

12 min

68K

Programming *Designing and refactoring *

Постараюсь объяснить сущность принципа проектирования KISS просто и одновременно очень подробно. KISS – это очень общий и абстрактный принцип проектирования, который содержит в себе практически все остальные принципы проектирования. Принципы проектирования описывают как писать «хороший» код. Однако что значит хороший код? Некоторые считают, что это код, который выполняется максимально быстро, некоторые – что это код, в котором задействовано как можно больше паттернов проектирования… Но верный ответ лежит на поверхности. Код – это информация в чистом виде. А основные критерии ценности информации – это 1)достоверность 2)доступность 3)понятность. То, почему важны достоверностью и доступность – очевидно. От кода нет проку, если он работает с ошибками или если сервер с приложением «лежит». Почему же важна понятность кода? В понятном коде проще искать ошибки, проще его изменять, дорабатывать и сопровождать. Итак, понятность – основная ценность, к которой должен стремиться программист. Однако тут есть одна неувязочка. Дело в том, что понятность – вещь сугубо субъективная.

Читать дальше →

-4

VioletTape Apr 20 2015 at 11:51

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

9 min

17K

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 вместе будут укладываться в общую архитектурную картину.

Читать дальше →

+12

cobiot Feb 4 2016 at 16:18

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

25 min

645K

Website development *System Analysis and Design *Designing and refactoring *

Sandbox

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

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

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

Читать дальше →

+82

alexzfort Feb 12 2016 at 10:52

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

5 min

13K

Zfort Group corporate blog Website development *Programming *C# *

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

Читать дальше →

vvzvlad Dec 17 2018 at 12:38

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

14 min

22K

Samsung corporate blog Interfaces *Development for IOT *Smart House IOT

Мы предлагаем вашему вниманию статью Владислава Зайцева (vvzvlad), приглашенного гостя нашего блога. Владислав давно занимается темой «умных домов», и обобщив свой опыт, он предлагает следующие основные принципы дизайна такого рода систем.

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

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

Собственно, сам disclaimer

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

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

Умный дом — это система, которая берёт на себя часть повседневных забот человека. Отсюда следует первый и самый основной принцип:

Читать дальше →

+49

sergiisavchenko Dec 22 2018 at 17:35

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

9 min

3.3K

Interfaces *Development for IOT *Smart House IOT

Sandbox

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

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

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

Читать дальше →

+13

ai_borisov Mar 23 2019 at 10:59

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

8 min

20K

Programming *System Analysis and Design *Designing and refactoring *

Sandbox

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

Читать дальше →

+19

Anna_Kopyrneva Jan 25 2021 at 11:02

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

4 min

7.1K

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

Translation

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

+24

Cuckooshka Jun 5 2021 at 22:00

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

5 min

36K

Programming *Perfect code *Designing and refactoring *

Translation

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

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

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

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

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

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

+36

GeorgKDeft Sep 2 2021 at 13:56

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

6 min

6.2K

Tutorial

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

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

№1

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

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

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

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

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

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

№2

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

thenonsense Dec 9 2021 at 21:19

Сферические практики в Godot

7 min

4.3K

Game development *Prototyping *Games and game consoles Godot *

Написал некоторый разбор того, как внутренне устроена конкретная игра для джема на движке Godot.

PavloPoliakov Jan 11 2022 at 16:34

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

9 min

10K

Programming *Amazon Web Services *IT career IT-companies

Translation

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

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

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

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

rikki_tikki Feb 15 2022 at 18:39

Принципы проектирования SOLID с примерами на Python

9 min

36K

OTUS corporate blog Python *

Translation

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

+18

romblin Jun 6 2022 at 00:10

Еще раз о KISS и трендах

4 min

12K

Python *Programming *

Последние несколько лет async вообще и asyncio в частности в питоне все больше набирают популярность и их все чаще используют. При этом иногда забывают о принципе KISS (Keep it simple, stupid) и о том, какие вообще проблемы решает асинхронный код и зачем он нужен. В этой статье я бы хотел описать пример, когда задачу можно и, на мой взгляд, нужно решать без использования async. И вообще, практически без всего.

Amega Jul 1 2022 at 12:43

“Перевод стрелок” в проектировании

6 min

1.7K

Programming *Designing and refactoring *

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