Вчера на подкасте В Офисе пришлось разговаривать про политику. Из раза в раз одно и то же утверждение, что моя аудитория ждёт от меня каких то политических объявлений.
Моё мнение такое - я рассказываю про программирование, никого жизни не учу, мозг не колупаю.
Если аудитория хочет от меня политики, то это не моя аудитория.

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

Ребята хватит уже эту дичь разгонять. Это одна из самых тупых манипуляций, которую я встречал, направленная на усиление тревожности и общей истерии в обществе.
Нет никакой закономерности между тем занимаетесь вы политикой и тем, что вы будете от чего либо защищены. Это обычное "искажение вероятностных событий".

С одной стороны да, а с другой, если ты не лезешь в политику, это не значит, что она не полезет к тебе. Сегодняшний день заставляет об этом много думать

Вчера подарили раритетную вещь - приложение к журналу "юный техник", в нем речь про две ОС для микроЭВМ "ЮТ-88".
Прям в сердечко, спасибо.

Отличное выступление получилось у Дена. Особое впечатление произвёл барабанщик, его сольное выступление было вишенкой на торте. Спасибо всем кто пришёл!

Atomic Heart и Cyberpunk - хорошая иллюстрация того, чем российские разработчики отличаются от европейских. Наши функционируют в условиях сильно меньших бюджетов, ищут более оптимальные решения для одних и тех же задач, качают скилы и глубоко копают.
Причём такая ситуация и в других областях - финтех, 3д, системная разработка и т.д.
Я всегда говорил, что в условиях ограничений всегда формируются более качественные специалисты.
На мой взгляд "Российский программист" - это крутой бренд, на уровне с "русскими хакерами", которые, как известно, решают кто станет следующим президентом США и уводят секретные материалы на раз два.

Леша выпустил свой гайд как читать книги. Я не сторонник делать заметки на полях книги, вариант со стикерами мне нравится, но это очень очень медленно, сам я так никогда не делаю https://rutube.ru/video/7e28bbdb57ae5b65a7e0f0acc0704f8e/?r=a

Ветвление и линейность в коде

Давайте немного поговорим о том, что такое вложенные конструкции чем они вредны для кода. И почему линейность помогает улучшить код.

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

Ветвление делается с помощью операторов выбора if/then/else и по сути означает, что мы либо сворачиваем с "прямого пути", либо продолжаем двигаться дальше. На уровне машинного кода ветвление - это либо переход на следующий адрес, где расположена команда для выполнения, либо на какой-то произвольный адрес с командой.

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

Бывают ситуации, когда уже после перехода на другой адрес, нам нужно снова принять решение двигаться дальше или перейти еще куда-то, для этого так же используются операторы ветвления, но такие ситуации называют "вложенными" условиями.

Чем больше вложенных операторов ветвления мы используем, тем сложнее проводить анализ кода, потому что каждое условие увеличивает количество возможных путей вдвое. Таким образом операции ветвления увеличивают сложность понимания кода. С ростом сложности кода растет риск возникновения ошибок и неожиданных результатов работы программы.

Отсюда возникает хорошо известное правило: "плоское лучше вложенного".

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

Если уменьшить количество условий невозможно, то можно сделать код "визуально" прямым. Визуально означает, что мы используем ветвления не более чем с одним уровнем вложенности, а все ветки, которые возникают внутри условий, оборачиваются в подпрограммы, которые скрывают от программиста часть сложности, абстрагируясь от деталей реализации внутри условных переходов.

Отсюда возникает правило: "вложенные условия декомпозируй в виде функции". Практика показывает, что декомпозиция программы на функции не только упрощает повторное использование кода, но и значительно упрощает восприятие и анализ.

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

Чтобы код получился более читаемым и понятным нужно обратить внимание:

- на уровень вложенности - конструкции более двух уровней вложенности недопустимы;

- сложность выражений внутри условий - условия должны хорошо читаться и быть максимально простыми;

- декомпозицию содержимого if-ов с помощью функций, для визуального уменьшения вложенности программы.

#программирование #теория

Запускаю сбор тем на субботний ЗЭН. Отберу три коммента с наибольшим количеством лайкосов.
Только тематические комментарии.

Ссылка на канал с анонсами от Димы https://t.iss.one/ityoutubers_com

Оказалось, что видео со встречи с Антоном Назаровым я не вывел в стрим... Сорян!

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

Ответ на вопрос:

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

На одном из 1-1 с техлидом получил вводную, что слишком занимаюсь микроменеджементом: не даю развиваться членам команды, растягиваю CR и пр..

Вот я и задумался, насколько это действительно проблема и насколько на это надо обращать внимание? Не пониманию, как без доведения до коллег-бэкэндеров требований и схем, а так же соблюдения правил при реализации, поддерживать сервисы в адекватном состоянии? Можете поделиться как соблюдать баланс в этом вопросе?

p.s. Не планируется добавлять на платформу кроме техники еще и темы, связанные с взаимодействием в команде, когда находишься не на позиции менеджмента и вроде как не можешь напрямую влиять на коллег, но при этом, на мой взгляд, архитектура это подразумевает? Столкнулся, что этого не хватает.

RuTube | VK | Подкаст "S() Talks"

#вопрос #видео