Наш клуб книг по IT начал чтение новой книги - об Инженерии Программного Обеспечения в Google - процессах, культуре и инструментах, которые помогают Google создавать и поддерживать высококачественное программное обеспечение. Первая глава посвящена Инженерии Программного Обеспечения в общем:
Что такое Инженерия Программного Обеспечения по сравнению с Разработкой программного обеспечения? Три принципа, которые учитывает Google: Время и изменение Масштаб и рост Компромиссы и затраты Как эти три принципа применяются к Инженерии Программного Обеспечения и в чем она отличается от Разработки программного обеспечения.
Книжный клуб у нас в компании выбрал следующую чудесную книгу для чтения:
Роберт Мартин - Чистая Архитектура - Искусство Разработки Программного Обеспечения
Robert Martin - Clean Architecture - a Craftsman’s Guide to Software Structure and Design
Четвертая часть книги посвящена принципам объединения компонентов в программные системы.
Эта часть более интересна. Она содержит:
Обзор истории компонентов: возможность перемещения в памяти, линкеры Три принципа связности компонентов REP: Принцип эквивалентности повторного использования и выпусков CCP: Принцип согласованного изменения CRP: Принцип совместного повторного использования Три принципа соединения компонентов ADP: Принцип ацикличности зависимостей SDP: Принцип устойчивых зависимостей SAP: Принцип устойчивости абстракций Мне особенно понравилась эта глава из-за представленных метрик, которые можно использовать для измерения (!
Последние три года я много собеседую Golang-разработчиков. Go - это замечательный язык. Удачные концепции горутин и каналов позволяют очень просто и эффективно разрабатывать высоконагруженные приложения.
И всем кандидатам кто, как видно, еще не вполне освоил конкурентное программирование с каналами и горутинами, я неизменно советую пройти два замечательных курса (удивительно что они еще и бесплатные).
Эти курсы и я сам когда-то проходил и очень сильно их рекомендую всем разработчикам!
Курс даст основы программирования на языке Go, а так же опыт применения языка в основных задачах, которые встречаются сегодня в серверной веб-разработке.
Книжный клуб у нас в компании выбрал следующую чудесную книгу для чтения:
Роберт Мартин - Чистая Архитектура - Искусство Разработки Программного Обеспечения
Robert Martin - Clean Architecture - a Craftsman’s Guide to Software Structure and Design
👍
Третья часть книги посвящена принципам SOLID.
Принцип единственной ответственности: модуль должен быть ответственным перед одним и только одним действующим лицом. Принцип открытости-закрытости: программный артефакт должен быть открыт для расширения, но закрыт для модификации.
При запуске нового проекта по разработке ПО необходимо выбрать технологию для Frontend. В настоящее время существуют три ведущие технологии: Angular, React и Vue.
Но как выбрать из них?
Наша команда имеет опыт работы со всеми из них, но обычно выбор делается на основе «кто доступен в команде, и что они предпочитают».
Я хотел более глубокое сравнение плюсов и минусов, и я нашел его в отличном коротком курсе Udemy:
React JS, Angular & Vue JS - Quickstart & Comparison
Книжный клуб у нас в компании выбрал следующую чудесную книгу для чтения:
Роберт Мартин - Чистая Архитектура - Искусство Разработки Программного Обеспечения
Robert Martin - Clean Architecture - a Craftsman’s Guide to Software Structure and Design
👍
Книга пока поверхностная. Вот обзор второй части:
Есть три парадигмы программирования:
Структурированное программирование - накладывает ограничение на прямую передачу управления. Объектно-ориентированное программирование - накладывает ограничение на косвенную передачу управления.
Книжный клуб у нас в компании выбрал следующую чудесную книгу для чтения:
Роберт Мартин - Чистая Архитектура - Искусство Разработки Программного Обеспечения
Robert Martin - Clean Architecture - a Craftsman’s Guide to Software Structure and Design
👍
Краткий обзор первой части:
Цель архитектуры ПО уменьшить человеческие трудозатраты на создание и сопровождение системы Две ценности ПО Поведение (функционал) - удовлетворить требованиям заинтересованных сторон Структура (архитектура) - сложность внесения изменений должна быть пропорциональна содержанию, а не “форме” изменений Легкость внесения изменений более важна чем фунционал!
В Python существует известная проблема - вам нужно выбирать между моделями кода sync и async.
И если вы используете async код, вы можете вызвать sync код, но из этого кода вы НЕ МОЖЕТЕ снова вызвать async код.
Почему возникает эта проблема? Event loop, используемый кодом async, уже застрял в ожидании результата от кода sync. И если вы хотите вызвать async код сейчас, вы не можете повторно использовать тот же event loop.
