Developer
Архитектура программного обеспечения — основа, от которой зависят качество, производительность и масштабируемость систем. В статье шаблон от экспертов в области архитектуры программного обеспечения с типовыми описаниями и примерами архитектурных представлений. Шаблон доступен для скачивания.
Привет, Хаброжители!
Привет, Хабр! Меня зовут Владислав Воячек, я работаю архитектором в ИТ‑холдинге Т1. Одна из моих задач — управление техническим долгом. И хочу поделиться с вами современными подходами к решению этой непростой задачи.
Не всегда следует любой ценой избегать технического долга, в некоторых случаях его разумное использование становится стратегическим инструментом для достижения целей проекта. Однако для того, чтобы технический долг перестал ощущаться как что‑то пугающее и неконтролируемое, важно научиться осознанно им управлять. Команда должна воспринимать обсуждение долга как часть рабочего процесса, а не как негативный аспект работы. Если долг рассматривается как управляемая часть системы, он становится менее тревожным. Вместо того, чтобы стремиться к его полному отсутствию — что часто невозможно, — следует поддерживать управляемый уровень долга, при котором система остаётся гибкой и производительной.
Не тратьте время на задачи – сначала разберитесь в основах. В статье:
1. Как проходят собеседования (ВАЖНО!)
2. Big O, оценка сложности алгоритмов
3. Популярные техники: два указателя, DFS, динамическое программирование и другие
4. Какие задачи решать, чтобы пройти в Яндекс
Читаем, практикуемся, получаем оффер!
В публикации речь пойдет о подходах в разработке ПО. Речь пойдет о некой компании, которой никогда не существовало и порядки, заведенные в ней – это исключительно собирательный образ. Если вы решили, что в вашей компании очень похожая ситуация, то это совпадение.
Scrum считается одной из самых популярных методологий управления проектами, особенно в сфере разработки. Однако во многих компаниях внедрение этого подхода оборачивается не ростом гибкости и эффективности, а изнуряющим микроменеджментом, постоянной гонкой за метриками и разочарованием в процессе. Почему так происходит? Почему команды называют свою работу Scrum, но игнорируют его базовые принципы? В этой статье разбираем, как искажение изначальных идей методологии приводит к провалам и что на самом деле нужно для того, чтобы Scrum работал так, как задумывали его создатели.
Недавно я прошла Agile-тренинг Certified Agile Professional вместе с такими же ребятами, которым, как и мне, пришлось или захотелось самостоятельно столкнуться с этим явлением. В первый же день у нас возник спор о том, что принципы гибкой разработки из Agile-манифеста устарели.
Agile-манифест был подписан аж в 2001 году, и неужели за прошедшие 25 лет, никто не захотел в нём что-то поменять?
Я предлагаю посмотреть на «12 принципов» с точки зрения того, как гибкие подходы могут адаптироваться к управлению проектами в зависимости от масштаба задач и стадии готовности продукта. Это не просто моё мнение — 3 дня обучения бок о бок с другими руководителями проектов из разных сфер только убедили меня в том, насколько важна эта тема.
Зачастую, когда речь заходит про принцип инверсии зависимостей, можно услышать, что инверсия зависимостей (далее DIP) — это что-то там про зависимость от абстракций, и приводятся примеры, где в качестве «плохого» случая, используются конкретные классы, а в исправленном случае, используются абстрактные классы или интерфейсы. Но такая трактовка принципа в корне неверна.
Почему такая трактовка неверна и в чем же суть принципа — об этом и пойдет речь далее.
Думаю, что каждый из читателей встречался с проблемами отдыха.
Знакомое всем слово "выгорел" и последствия этого выгорания встречаются на каждом шагу.
Казалось бы в чем проблема - требуется всего лишь побольше поспать, поесть и силы придут сами собой.
Однако минуты сменяются часами, а сил больше не становится.
Как итог решил разобраться в вопросе более детально и получил интересные выводы.
Информация рассматриваются со стороны работников сферы IT, но в целом может быть экстраполирована на любую область.
Материал будет интересным в первую очередь для Руководителей и службы HR.
Однако, он может оказаться занимательным и для тех, кто хочет лучше разобраться в том, как работает его организм в целом и почему именно так.
Я пишу коммерческий код с 2005 года и с 2014 года ищу способ систематически писать хороший код.
В рамках этих поисков я изучил всю популярную литературу о хорошем коде и его дизайне — от «Чистого кода» Анкл Боба до «DDD» Эрика Эванса. Однако все популярные подходы в значительной степени субъективны: они не дают объективного и последовательного судьи, который бы решал, какой код лучше.
Например, в чистом коде я до сих пор не знаю способа за конечное время дать ответ на вопрос «Сколько уровней абстракции в этой функции?». А если взять DDD — то я до сих пор не знаю способа, который бы позволял стабильно и за конечное время находить границы между ограниченными контекстами (прошу прощения за каламбур) или агрегатами.
Эта неопределённость ведёт к длительным дискуссиям на ревью и в голове разработчика о том, какой из способов является наилучшим для решения задачи. А после этих дискуссий, каждый из участников (включая того дилетанта в собственной голове) остаётся при своём мнении.
Отчаявшись научиться писать стабильно хороший объектно‑ориентированный код, в 2016 году я пошёл в сторону функционального программирования и архитектуры. Там с детерминированностью было получше: если в коде нет побочных эффектов (ввода‑вывода, оператора присваивания и чтения глобальных переменных) — то код хороший, если есть — плохой. Однако как затащить в коммерческий проект и, главное, собственную голову свободные монады и их интерпретаторы — я так и не понял.
Поэтому в 2020 году поиски своего Святого Грааля я продолжил в «эзотерических» и древних книгах. Одной из таких книг стал «Структурный дизайн» Ларри Константина. И в этой книге я, наконец, нашёл простой и понятный принцип, который лёг в основу моего текущего подхода к проектированию и кодированию, и для которого можно быстро и однозначно дать ответ, соответствует ли тот или иной кусочек кода этому принципу или нет.
В этом посте я даю краткий экскурс в идею сбалансированной формы системы из структурного дизайна и рассказываю на примере трёх кейсов о результатах применения этой идеи в моей коммерческой практике.
Привет, Хабр! Меня зовут Сергей Махнаткин, я работаю разработчиком в отделе User Experience в Yandex Cloud. В прошлом году мы писали о нашей дизайн-системе и библиотеке компонентов Gravity UI. С тех пор система не раз обновлялась и обрастала новыми функциями, и сегодня я хочу рассказать о новом инструменте — Markdown Editor, который значительно упрощает процесс работы с документацией.
Поговорим об истории создания пользовательского интерфейса, архитектурных особенностях и технических деталях интеграции и разработки собственных расширений, а потом — почему всё это доступно в опенсорсе.
Если вы полный ноль в интернет-технологиях, и хотите получить общее понимание Интернета, прочитав всего одну статью, то эта статья - для вас.
Здесь вы узнаете о 4 уровнях модели TCP/IP. О том, что такое MAC-адрес и IP-адрес, и зачем нам 2 типа цифровых адресов. Как работает DNS. Зачем нужны коммутаторы и роутеры. Как работает NAT. Как устанавливается защищённое соединение. Что такое инфраструктура открытых ключей, и зачем нужны TLS-сертификаты. Чем отличаются три версии протокола HTTP. Как происходит HTTP-аутентификация. И в конце будет несколько слов о VPN.
Сочетать учёбу и работу в IT – задача, мягко говоря, непростая. Даже если вы только ходите на занятия и делаете «домашку». А уж если вы захотите сами организовать обучение – сложности будут расти в геометрической прогрессии.
Недавно наша команда iOS-документов в МойОфис решила перейти на SwiftUI – декларативный UI-фреймворк от Apple. После достаточно безболезненного рефакторинга модуля с UIKit на SwiftUI оставалось всего ничего – обучить коллег новому фреймворку.
Под катом рассказываем, как нам удалось организовать и провести командное обучение, а также делимся своими подходами и лайфхаками, которые упростят жизнь тимлидов и менторов при подготовке учёбы для айтишников.
Скрам - это новый ватерфол, который все полюбили, ведь любить нужно новое и модное, а старое и не модное принято презирать. Скрам это лекарство от всех болезней, однако оно не помогает, если его неправильно принимать. Скрам это благословение и проклятие в одном флаконе, дар небес, который мы не заслужили, и наказание за грехи, которые мы не совершали. Скрам проник в самое сердце нашей индустрии, и теперь медленно убивает ее изнутри. Возникает один вопрос.
Как же часто мне приходилось слышать от рекрутеров одну и ту же фразу:
Мы работаем по Agile. Спринты по 1-2 недели
Под "Agile" они, конечно же, имеют в виду Scrum. Но я с уверенностью могу сказать, что ни в одной компании, что я работал, Agile'ом даже и не пахло. И тут я даже не говорю о том, что Agile каким он был задуман в принципе не дошел до массовой разработки (о чем рассказывал один из создателей Agile Дейв Томас на конференции GOTO 2015). Я говорю об Agile в общепринятом значении этого слова.
В дальнейшем, на техническом интервью, если спрашивать по пунктам, практически любой реальный работник компании подтвердит вам, что никакого Agile в компании нет, а используются лишь элементы Agile.
По некоторым причинам команде разработчиков либо не получается наладить работу по Agile, либо руководство знает, как лучше, и навязывает собственное видение методологии разработки. Эту проблему адресовал в своей статье Рон Джефрис (вот перевод на русский), дав красноречивое название подобным практикам — "Dark Scrum". Существует и более мягкая формулировка для тех, кто считает подобное положение вещей скорее фичей, а не багом — "Pseudo Agile" или "Post Agile".
В этой статье я постараюсь расставить точки над Ё и разобраться, что такое Agile на самом деле, и какие проблемы существуют у современных гибких методологий.
Привет, меня зовут Мялкин Максим, я занимаюсь мобильной разработкой в KTS.
Не за горами выпуск новой версии Kotlin 2.0, основной частью которого является изменение компилятора на K2.
По замерам JB, K2 ускоряет компиляцию на 94%. Также он позволит ускорить разработку новых языковых фич и унифицировать все платформы, предоставляя улучшенную архитектуру для мультиплатформенных проектов.
Но мало кто изучал, как работает K2, и чем он отличается от K1.
Эта статья освещает нюансы работы компилятора, которые будут полезны разработчикам для понимания, что же JB улучшают под капотом, и как это работает.
Для любого разработчика глубокое понимание основных принципов системного проектирования является необходимым условием для создания стабильных и масштабируемых программных систем, способных обеспечивать высокую производительность. Системное проектирование (System Design) включает разработку архитектуры и структуры программной системы, направленную на удовлетворение специфических требований и обеспечение требуемых показателей производительности.
С учетом стремительного прогресса в области технологий и возрастающей сложности программных приложений, овладение принципами системного проектирования становится критически важным для разработчиков, стремящихся создавать эффективные системы. Не имеет значения новичок вы или опытный специалист: освоение этих принципов позволит вам разрабатывать надежные и масштабируемые программные системы, отвечающие требованиям современных приложений.
Далее мы рассмотрим каждый из принципов более детально, чтобы понять их суть и способы применения в разработке приложений.