Почему многие разработчики не мыслят словами, а сразу «видят» архитектуру, блок-схемы, паттерны и фрагменты кода? Что особенного в мозге программиста и как он превращает абстрактные задачи в работающие системы? В этой статье я разбираюсь в когнитивной архитектуре программистского мышления: от памяти и нейронных связей до привычки «думать в коде», приводя примеры, личные наблюдения и немного кода на Python, C++ и Haskell.
Рубрика «абстракция»
Архитектура мозга программиста: почему мы думаем в коде, а не в словах
2025-07-26 в 0:07, admin, рубрики: абстракция, архитектура мозга, когнитивные паттерны, мышление программиста, рабочая памятьВам не нужна Чистая архитектура. Скорее всего
2025-03-06 в 8:33, admin, рубрики: DIP, абстракция, функциональная архитектура, чистая архитектураВведение
Сейчас среди Java/Kotlin команд распространено применение Чистой (ака Гексагональной, ака Луковой — Clean, Hexagonal, Onion) архитектуры для разработки бакэндов прикладных приложений (да и Android‑приложений тоже). Однако это семейство архитектур в контексте прикладной разработки зачастую не даёт никаких преимуществ, а только привносит лишние церемонии и тем самым замедляет её.
«Ты не видишь всей картины!»
2025-03-04 в 9:13, admin, рубрики: абстракция, исполнитель, менеджер, мозг, уровни абстракцииС завидной регулярностью эта фраза разжигает огонь моего... сердца. В ней, конечно, есть зерно здравого смысла, но и глупости тоже хватает.
Всем доброго.
Приветственный пост опубликую как-нибудь потом. Когда допишу.
А начну, как полагается, с выводов
Основная идея текста
Абстракции и наследование в Си — стреляем по ногам красиво
2022-06-24 в 12:05, admin, рубрики: C, абстракция, наследование, ненормальное программирование, ооп, упорюсьИногда нет-нет да и хочется что-нибудь абстрагировать и обобщить в коде на Си. К примеру, хочешь ты принтануть содержимое структуры несколько раз, пишешь везде, как дурак, printf("%s %d %fn", foo->bar, foo->baz, foo->boom), и интуитивно кажется, что есть способ сделать foo->print(foo), и так вообще со всеми структурами, не только с foo.
Возьмем пример: есть некий чувак с именем и фамилией, и есть птица, у которой есть имя и владелец.
typedef struct Person Person;
struct Person {
char *first_name;
char *last_name;
};
typedef struct Bird Bird;
struct Bird {
char *name;
Person *owner;
};Эволюция программного проекта и ООП
2019-04-14 в 10:27, admin, рубрики: абстракция, алгоритм, Анализ и проектирование систем, инкапсуляция, наследование, ооп, полиморфизм, Программирование, Проектирование и рефакторинг, эволюцияОсваивая рецепты эффективного развития программного проекта, постарался для себя найти причины, делающие полезным использование принципов развития архитектуры SOLID (статья Как не понимать принципы развития архитектуры SOLID).
Анализ этих принципов позволил выделить несколько ключевых закономерностей и базовых элементов, существующих в разработке. Они позволили описать, понять и внедрить SOLID в реальной работе с программным проектом.
Стало интересно выполнить анализ применимости этих понятий для общепринятых парадигм программирования, например для ООП. Хорошо, если результат этой работы будет полезен и Вам.
Кратко об абстракциях
2019-02-14 в 15:08, admin, рубрики: абстракция, Анализ и проектирование систем, мозг, Программирование, программные интерфейсы, психологияБывает так что проект заходит в тупик, и дальнейшее его развитие становится невозможным. Не редко причиной такого провала становится неудачная архитектура, заложенная в начале разработки. Или приходится наблюдать споры о том какой из "двух стульев" лучше, а может даже участвовать и искренне не понимать, как оппонент может так думать!?
Тогда попробуем не много разобраться в абстракциях, откуда они берутся и что с ними делать.
Ограничения глубинного обучения и будущее
2017-08-07 в 5:48, admin, рубрики: AlphaGo, AutoML, DeepMind, python, абстракция, антропоморфизация, апокалипсис, генерация нейросетей, глубинное обучение, градиентный спуск, ИИ, машинное обучение, нейросеть, обобщения, обратное распространение, Программирование, программный синтез, разум, рассуждения, сильный ИИ, Сингулярность, функция потерь
Эта статья представляет собой адаптацию разделов 2 и 3 из главы 9 моей книги «Глубинное обучение с Python» (Manning Publications).
Статья рассчитана на людей, у которых уже есть значительный опыт работы с глубинным обучением (например, тех, кто уже прочитал главы 1-8 этой книги). Предполагается наличие большого количества знаний.
Ограничения глубинного обучения
Глубинное обучение: геометрический вид
Самая удивительная вещь в глубинном обучении — то, насколько оно простое. Десять лет назад никто не мог представить, каких потрясающих результатов мы достигнем в проблемах машинного восприятия, используя простые параметрические модели, обученные с градиентным спуском. Теперь выходит, что нужны всего лишь достаточно большие параметрические модели, обученные на достаточно большом количестве образцов. Как сказал однажды Фейнман о Вселенной: «Она не сложная, её просто много».
Читать полностью »
От моноидов к алгебрам де Моргана. Строим абстракции на Haskell
2017-03-13 в 18:40, admin, рубрики: haskell, абстракция, алгебра везде, математика, моноид, функциональное программированиеЧто общего у нормального распределения, конечных автоматов, хеш-таблиц, произвольных предикатов, строк, выпуклых оболочек, афинных преобразований, файлов конфигураций и стилей CSS? А что объединяет целые числа, типы в Haskell, произвольные графы, альтернативные функторы, матрицы, регулярные выражения и статистические выборки? Наконец, можно ли как-то связать между собой булеву алгебру, электрические цепи, прямоугольные таблицы, теплоизоляцию труб или зданий и изображения на плоскости? На эти вопросы есть два важных ответа: 1) со всеми этими объектами работают программисты, 2) эти объекты имеют сходную алгебраическую структуру: первые являются моноидами, вторые — полукольцами, третьи — алгебрами де Моргана.
Длина функции
2016-12-02 в 10:01, admin, рубрики: абстракция, Анализ и проектирование систем, длина функции, Программирование, Проектирование и рефакторинг, размер функции, функциональное программирование, метки: длина функции, размер функции
На протяжении своей карьеры я слышал множество аргументов о длине функции. Более глубокий вопрос — когда код нужно выносить в отдельную функцию? Иногда рекомендации основаны на размере, например, функция должна помещаться на экране. Другие основаны на повторном использовании — любой код, используемый больше одного раза, должен быть вынесен в отдельную функцию. Но если код используется лишь один раз, то можно его оставить на месте. Мне кажется, что большим смыслом обладает аргумент о разделении намерения и реализации. Если нужно потратить время на поиски фрагмента кода чтобы понять, что он делает, то нужно вынести его в функцию и дать ей такое имя, которое отвечает на вопрос "что". Тогда в следующий раз смысл функции сразу будет очевидным, и в большинстве случаев вас не будет волновать то, как функция выполняет свою работу. Иными словами — что происходит в теле функции.
Когда я стал применять такой принцип, я развил в себе привычку писать очень маленькие функции — обычно не больше нескольких строк. Любая функция длиннее шести строк уже попахивает. Вполне обычное дело для меня — иметь функцию с одной строчкой кода. Кент Бек показал мне когда-то пример из оригинальной системы Smalltalk, и это помогло мне по-настоящему понять, что размер — это не важно. Smalltalk в те годы работал на черно-белых машинах. Если нужно было подсветить текст или графику, то приходилось реверсировать видео. Класс в Smalltalk, отвечающий за графику, содержал метод 'highlight', и в его реализации была лишь одна строка — вызов метода 'reverse'. Название метода было длиннее реализации, но это не имело значения, потому что между намерением и реализацией этого кода — большое расстояние.Читать полностью »
MBED, или о дырявых абстракциях
2015-12-01 в 11:38, admin, рубрики: arduino, mbed, nucleo, stm, stm32, абстракция, программирование микроконтроллеров, С++, Электроника для начинающих, метки: mbedПонадобилось взглянуть в сторону mbed. На первый взгляд выглядело весьма интересно – железонезависимый фреймворк, на С++, с поддержкой кучи микроконтроллеров и демо-плат, онлайн-компилятор с интеграцией в систему контроля версий. Куча примеров, еще более убеждающих в элегантности фреймворка. Прямо «из коробки» доступны практически все интерфейсы микроконтроллера при помощи соответствующих, уже реализованных классов. Вот прямо из коробки бери и программируй на С++, не заглядывая в даташит от микроконтроллера – ну не мечта ли?
Тестовой платформой стала давно лежащая без дела STM Nucleo F030, поддерживаемая этой платформой. О том, как зарегистрироваться и начать первый проект, есть много хороших туториалов, об этом не будем. Перейдем сразу к интересному.