All streams
Search
Write a publication
Pull to refresh
-10
0
Send message
И какой смысл? Огромное количество изменений в коммите просто убивает всю историю, никто не сможет понять что там изменилось. Практика микрокоммитов и проблемы в неймниге отпадет само собой.
нейросети — это не AI. Это machine learning.
Есть другие модели, которые приближены к реальной работе мозга. А об квантовой природе мозга не может идти речь, это не тот уровень. Нельзя запутать макрообъекты.
Легко понять принцип, если изучить синергетику и теорию хаоса.
Ну сомневаюсь что генерал сможет заменить солдата)
Ну про надежность я с вами согласен. Но это уже другая архитектура, более жидкая и уже ближе к распределённой системе. Натуральная, так сказать
Но идеально применить SOLID не получиться, чем-то придется жертвовать и все будещие изменения не предскажешь. В добавок, у нас получиться solid система, очень жесткая и не гибкая.
PS Принцип подстановки Барбары Лисков запомнить тоже легко, она о том что предок должен быть абстрактным, а не для того чтобы убрать дублирование кода.
И хороший пример нарушения принципа -
class Square: Rectangle
пирамида управления — это из системного анализа.
Задача состоит в том, чтобы из сложной системы сделать простую управляемую. Сложная система — это система со множеством связей, результат работы которую сложно предсказать(лапша-код).
Один из вариантов — это декомпозиция модулей. Сверху-вниз. В итоге, если убрать циклические зависимости и минимизировать количество связей(инкапсуляция), мы получим дерево, которое разделено по уровням абстракции.
В армии, генерал управляет и владеет своими полковниками. Полковники не знают об генерале и не могут ему давать приказы. Но полковники управляют уже сержантами, а сержанты уже солдатами. А солдаты вообще ничего не знаю, они лишь выполняют что скажут. В итоге, мы получили классическую строгую многоуровневую архитектуру.
Если применить на границе слоя инверсию зависимости, например абстрагировать солдат и чтобы они реализовали интерефейс который им дал сержант. Т.е. сержанту все равно кем управлять, лишь бы умели копать, бежать и отжиматься. Тогда можно легко дополнить солдат боевыми роботами и боевыми дельфинами.
Управлять такой системой легко, нужно лишь дать команду генералу «Разбомби Вашинктон», он уже делегирует на полковников «запустить ракету по таким-то координатам», они делегирует команду солдатам «нажми красную кнопку». Красная кнопка делегирует уже системе запуска.
полиморфизм же был задолго до ооп, iostream например. Да и реализация ооп была еще даже на чистом Си.
Запоминать расшифровку SOLID не нужно, нужно лишь запомнить перевод solid;
Суть очень простая — это кибернетический подход управления сложными системами. Хороший пример — это иерархия власти в армии.
И к ооп это не имеет никакого отношения, SOLID — это пакет архитектурных принципов;
Почитать «Чистая архитектура» и «Чистый код» самого Мартина — одна из самых важных книжек для программиста и для кодера
в .Net много костылей. Та же утинная типизация для коллекций, например
крайне неудачное название «микросервисная архитектура». К архитектуре она не имеет отношения.
не вижу связи между стать отличным разработчиком — и работать как можно больше, концетрироваться на узкой задачи.

Отказ от прокрастинации (хотя бы частичный) сделает из вас человека лучшего разработчика.

не согласен. Тут обратная корреляция. Ленивый разработчик — лучший разработчик.
Сложно подобрать для файла кода лучшее название, чем «walk_monster.cpp»
— это уже о много говорит.
Ну и додуматься использовать такой алгоритм, когда есть множество стандартных Navigation Mesh алгоритмов.
Удивительно как с таким кодером игра работает.
Либо это крутой QA-щник.
Еще добавлю:
  1. Практика микрокоммитов выручает всегда;
  2. Не использовать мердж со сквошем, иначе смысл в гита пропадает;
  3. Ревью кода нужно делать сразу, в тот же день;
  4. Обязательно нужно связывать git c таск-трекером. И писать в таске как можно больше информации в коментарии. Она пригодиться и вам самим. И это является юридическим документом, заодно;
  5. Связывать похожие таски. Баги редко фиксят до конца;
Спасибо, интересная статья. Но хотелось бы подробнее про шумы на GPU
Ну так-то понятно, почему крупные it-компании поддерживают этот пакет.
Невозможно подсчитать ценность такой бигдаты на каждого гражданина. Гугл заинтересован однозначно тоже. 1984
Это я о своем опыте говорю)
И о том, что проще написать простые тесты заранее, а потом уже писать код под них.
Но unit-тесты применимы только к чистой логики. Для остального кода нужно нечто подобное, кроме функциональных
Вы хотите запретить бегать по утрам? Моралисты такие моралисты.
А мне страшно за ваших детей, родителям которых проще застрелиться чем стремиться к полноценной жизни.
Продолжайте винить игры, и они последуют вашему совету
а чего плохого в зависимости? Зависимость — это связь со средой. Когда есть потребность, неудовлетворенность, сенсорная депривация,- мозг ищет дополнительные зависимости. Зависимость может быть и от другого человека, от работы, от наркотиков, от хобби, от еды. И они не отличаются качественно друг от друга. Бегаете ли вы каждое утро или колетесь героином — эффект один
фишка unit-тестов как раз в рутине. Когда на каждый лишний if приходиться писать отдельный тест да еще и дать осмысленное название, а на вложенные еще больше. Когда просто невозможно покрыть говно-метод из 500 строк. Вот когда появится лень такое писать, unit-тесты уже не понадобятся.
А вот фаззинг не предназначен для тестирование логики. Мне вообще не понятен его смысл, он только толкает делать ненадежный код.

Information

Rating
Does not participate
Registered
Activity