Вот уж что-что, а читать то, что пишут гуманитарии, всегда приятно :)
Я убежден, что IT это не совсем то место, куда надо идти из меркантильных соображений. Надо реально этим жить, интуитивно понимать программирование, постоянно изучать новомодные фреймворки. А на работе приходится реально вкалывать, напрягаться, сражаться с новыми непонятными задачами. Особенно за хорошую зарплату. А уж про то, сколько всего надо выучить и на какие ухищрения пойти, чтобы пробиться через HR, это вообще что-то нереальное.
Насчет того, что базовой теории мало и нужен опыт, согласен. Но насчет знания математики поспорю. Многим знакомым программистам математика, как и алгоритмы, за десятки лет просто не пригодились (очевидно, в основном там были сервисы, веб, джейсоны, интерфейсы интерфейсов, бд и т.д.). А во-вторых, в школе ведь математику проходят по верхам. Если надо сделать реальную задачу связанную с математикой, гугление учебника равносильно использованию документации. Такие вещи, как и какой-нибудь CSS, помнить наизусть скорее вредно, чем полезно
Не понял претензии. Ну да, надо понимать, как будет работать код. Отладчики и консоль это не заменит, но иногда пригождается. А уж архитектуры продумывать или алгоритмы на листочке бумаги - это вообще база
Желаю немного отдохнуть, переосмыслить увиденное и всë-таки попробовать ворваться в IT. Переосмыслить на мой взгляд придëтся всë очень сильно.
Базовое знание языка, алгоритмов и стандартных библиотек это самое начало и это реально просто. Если никогда не программировал, задачки типа "пересчитайте буковки в строке" могут поставить в тупик, я такое видел не раз. Нужно просто снять психологический блок.
Я заметил главную ошибку у любых программистов: они начинают фокусироваться на коде до того, как полностью поняли задачу. Особенно новички. А надо просто сесть, порисовать схему, написать что-то обычным текстом. Когда алгоритм будет сформирован в отрыве от языка, то код напишется сам собой.
Ну а если то же самое можно сделать одной строкой, это просто знание стандартной библиотеки пайтона, там действительно много уже готовых функций.
А если решение не очевидное, то всегда есть гугл и ChatGPT, это нормально не знать наизусть вообще всë. Главное знать, что гуглить. Когда осознание уверенности придет, можно переходить к более сложному.
А вот сложным могу назвать освоение фреймворков и чтение чужого кода. Для этого надо реально держать в уме то, как работает огромная кодобаза от незнакомых людей. Надо знать приколы архитектуры и основные паттерны, чтобы просто на автомате ориентироваться в нагромождении абстракций. Мне кажется, гуманитарий вполне себе заточен под накопление большого количества знаний, почему нет?
Чаще всего, люди просто не понимают, в чем именно лучшая практика заключается
Недавний хайп вокруг критики "чистого кода" заключался в том, что критик применил его к бутылочному горлышку, требующему оптимизации. Странно, что эта очевидная манипуляция так расфорсилась.
Таскать с собой энергию не обязательно, по крайней мере, электричество можно получать лазером. При желании можно даже без двигателя ускоряться на одноп солнечном парусе. Для торможения это уже не подойдет, но вещество для ионных двигателей это не атомный реактор, много его не нужно
На что только ни пойдут разрабы, лишь бы названия нормальные не придумывать. Компилятор-то можно настроить как угодно. Но языки программирования ведь придуманы прежде всего для людей, чтобы они понимали, что происходит. И сами же дают такие названия из разряда value для переменной
А обязательно вот так сложно говорить на собеседовании, например, "инверсия зависимостей"?
Для меня SOLID это просто набор рекомендаций, которые помогают держать код в порядке. Это даже не что-то конкретное, что можно описать словами. Это такое состояние ума, к которому рано или поздно приходишь сам, набивая шишки, либо тебя этому учат коллеги на код-ревью.
То есть рекомендаций/лайфхаков, как делать код гибким/понятным такое огромное множество, что любое перечисление принципов SOLID, KISS и прочих - это маленькая капля в море личного опыта.
Конкретные правила - это скорее решения лида, которых должна придерживаться вся команда. И правила эти могут идти вразрез и с SOLID, и с кодстайлом. Особенно это касается лямбд, ломающих сокрытие данных, либо каких-нибудь паттернов, делающих то же самое.
Было бы неплохо, если бы все программисты на личном опыте понимали, зачем придуман SOLID. Но есть ли способ при приеме на работу не парить мозг зубрежкой терминов из конкретных книг/статей?
Та же "инверсия зависимостей" странный термин. Зависимостей в идеале быть вообще не должно. Если один кусок кода лезет в другой, это просто невозможно тестировать
Преимущество LINQ больше не в читаемости, а в том, что там есть оптимизации. Например, из всех команд выборок он формирует один запрос к БД
В С++ скорее всего будет просто цикл с наивным перебором элементов по условию. Так же можно и на шарпе написать. Но если очень хочется имено LINQ синтаксиса, можно использовать CLINQ. Или что-то свое сделать, уж лямбды-то в плюсах имеются
Но сейчас мне не нравится то, куда идет современный С++ - туда пытаются втащить все на свете
Мне кажется, это должен решать каждый программист сам. Например, пользоваться только модерн C++, запретив себе использовать старые парадигмы после перехода на новый стандарт. Тогда код будет написан в одном стиле, понятен и легок в масштабировании. Получится фактически тот самый новый прекрасный язык с небольшим количеством нужных инструментов. И новый язык изобретать будет уже не нужно только для того, чтобы новички не "стреляли себе в ногу", просто потому что им в руки попалось ружьë. То есть искусственно ограничивать набор инструментов путем создания нового языка
В моем случае это были ресурсы OpenGL, к которому из других потоков обращаться запрещено драйвером. А объекты могут удаляться и создаваться в разных потоках. Пришлось писать отдельную очередь, которая собирает графические ресурсы, а потом основной поток, владеющий контекстом OpenGL, все это обрабатывает, когда до него добирается
Очень актуально для игрового движка. При отрисовке каждого кадра приходится создавать и чистить большое количество данных (треугольники, иерархии игровых сущностей). Быстрее всего сразу "застолбить" побольше памяти, а потом с помощью собственного аллокатора брать оттуда кусочки под расчеты. Поскольку игра должна работать быстро и плавно, обращаться в ОС за памятью не эффективно, а данных перекладывать с места на место надо очень много
Действительно, после такого опыта многопоток кажется не сложным. Это и "один пишет, другие читают", и "как танцевать девушку". При этом мютексы ставились только на очень узкие места (в основном взятие или добавление объектов в контейнеры).
Но поскольку у нас игра, объекты может создавать и игрок, и поток подгрузки. Возникают очень хаотичные взаимодействия потоков в самых разных комбинациях. Каким-то образом всë это получилось разрулить и заставить работать быстро и без вылетов.
В том-то и дело, что существует не только вэб-программирование. Можно связать жизнь с чем-то другим и с линуксом вообще никогда не сталкиваться. Если уж на то пошло, то для клиентских приложений лучше подходит Макось, потому что на чем-то другом разрабатывать под Айос нельзя, а клиентские программы очень хотят существовать и там тоже. Нельзя именно из-за хитрой лицензии Эппл, запрещающей разработку на чем-то другом.
Статья слишком сильно манипулирует выводами на основе субъективных ощущений автора
Она и начинается с дисклеймера о субъективности написанного. Но при этом в самой статье встречаются радикальные заявления о понятии "инженер", что немножко противоречит дисклеймеру.
Спасибо за статью. Очень ëмко и просто навела на некоторые мысли.
Я не мог начать пользоваться Rust пять лет назад из-за того, что просто не представлял, как со всеми этими ограничениями можно что-то сделать. То есть нужно действительно начать мыслить по-другому.
Сейчас у меня есть опыт параллельного программирования в С++, в этом очень сильно помогли умные указатели, которые следят за владением объекта и чисткой памяти. Они гарантируют отсутствие битых указателей, т.к. пока какой-то поток "одолжил" указатель, память в нем не чистится. Как недостаток, нельзя сказать точно, когда в рантайме объект освободится и в какой момент запустится деструктор, а главное из какого потока (например, к OpenGL можно обращаться только из главного потока, поэтому просто так из деструктора объекта, хранящиеся в shared_ptr, данные OpenGL не удалишь).
Тем не менее умные указатели и ссылки в плюсах - очень крутые средства, спасающие от выстрела в ногу. Мне кажется, заставив себя на них перекатиться, я постепенно дойду и до понимания Rust.
А теперь вопрос (он наверняка гуглится, но если всë гуглить, то о чем писать в комментах?). Rust многие вещи делает в компиляторе. Это ведь и по эффективности получается лучше, чем ООП в плюсах со всякими контейнерами и умными указателями? В плюсах это наверняка сплошной рантайм и достаточно тяжелый.
А можно мне не выбирать между лямбдой и наследованием, а использовать нужный инструмент в нужной ситуации? Спасибо
Вот уж что-что, а читать то, что пишут гуманитарии, всегда приятно :)
Я убежден, что IT это не совсем то место, куда надо идти из меркантильных соображений. Надо реально этим жить, интуитивно понимать программирование, постоянно изучать новомодные фреймворки. А на работе приходится реально вкалывать, напрягаться, сражаться с новыми непонятными задачами. Особенно за хорошую зарплату. А уж про то, сколько всего надо выучить и на какие ухищрения пойти, чтобы пробиться через HR, это вообще что-то нереальное.
Насчет того, что базовой теории мало и нужен опыт, согласен. Но насчет знания математики поспорю. Многим знакомым программистам математика, как и алгоритмы, за десятки лет просто не пригодились (очевидно, в основном там были сервисы, веб, джейсоны, интерфейсы интерфейсов, бд и т.д.). А во-вторых, в школе ведь математику проходят по верхам. Если надо сделать реальную задачу связанную с математикой, гугление учебника равносильно использованию документации. Такие вещи, как и какой-нибудь CSS, помнить наизусть скорее вредно, чем полезно
Реально, нафига формулы гуглить. Надо гуглить библиотеку и функцию, которая все это делает сама
Не понял претензии. Ну да, надо понимать, как будет работать код. Отладчики и консоль это не заменит, но иногда пригождается. А уж архитектуры продумывать или алгоритмы на листочке бумаги - это вообще база
Желаю немного отдохнуть, переосмыслить увиденное и всë-таки попробовать ворваться в IT. Переосмыслить на мой взгляд придëтся всë очень сильно.
Базовое знание языка, алгоритмов и стандартных библиотек это самое начало и это реально просто. Если никогда не программировал, задачки типа "пересчитайте буковки в строке" могут поставить в тупик, я такое видел не раз. Нужно просто снять психологический блок.
Я заметил главную ошибку у любых программистов: они начинают фокусироваться на коде до того, как полностью поняли задачу. Особенно новички. А надо просто сесть, порисовать схему, написать что-то обычным текстом. Когда алгоритм будет сформирован в отрыве от языка, то код напишется сам собой.
Ну а если то же самое можно сделать одной строкой, это просто знание стандартной библиотеки пайтона, там действительно много уже готовых функций.
А если решение не очевидное, то всегда есть гугл и ChatGPT, это нормально не знать наизусть вообще всë. Главное знать, что гуглить. Когда осознание уверенности придет, можно переходить к более сложному.
А вот сложным могу назвать освоение фреймворков и чтение чужого кода. Для этого надо реально держать в уме то, как работает огромная кодобаза от незнакомых людей. Надо знать приколы архитектуры и основные паттерны, чтобы просто на автомате ориентироваться в нагромождении абстракций. Мне кажется, гуманитарий вполне себе заточен под накопление большого количества знаний, почему нет?
Недавний хайп вокруг критики "чистого кода" заключался в том, что критик применил его к бутылочному горлышку, требующему оптимизации. Странно, что эта очевидная манипуляция так расфорсилась.
Ну всë, завтра полетим
Таскать с собой энергию не обязательно, по крайней мере, электричество можно получать лазером. При желании можно даже без двигателя ускоряться на одноп солнечном парусе. Для торможения это уже не подойдет, но вещество для ионных двигателей это не атомный реактор, много его не нужно
- Мам, купи мне варп-двигатель
- Но у нас есть варп-двигатель дома
Варп двигатель дома:
На что только ни пойдут разрабы, лишь бы названия нормальные не придумывать. Компилятор-то можно настроить как угодно. Но языки программирования ведь придуманы прежде всего для людей, чтобы они понимали, что происходит. И сами же дают такие названия из разряда value для переменной
А обязательно вот так сложно говорить на собеседовании, например, "инверсия зависимостей"?
Для меня SOLID это просто набор рекомендаций, которые помогают держать код в порядке. Это даже не что-то конкретное, что можно описать словами. Это такое состояние ума, к которому рано или поздно приходишь сам, набивая шишки, либо тебя этому учат коллеги на код-ревью.
То есть рекомендаций/лайфхаков, как делать код гибким/понятным такое огромное множество, что любое перечисление принципов SOLID, KISS и прочих - это маленькая капля в море личного опыта.
Конкретные правила - это скорее решения лида, которых должна придерживаться вся команда. И правила эти могут идти вразрез и с SOLID, и с кодстайлом. Особенно это касается лямбд, ломающих сокрытие данных, либо каких-нибудь паттернов, делающих то же самое.
Было бы неплохо, если бы все программисты на личном опыте понимали, зачем придуман SOLID. Но есть ли способ при приеме на работу не парить мозг зубрежкой терминов из конкретных книг/статей?
Та же "инверсия зависимостей" странный термин. Зависимостей в идеале быть вообще не должно. Если один кусок кода лезет в другой, это просто невозможно тестировать
Преимущество LINQ больше не в читаемости, а в том, что там есть оптимизации. Например, из всех команд выборок он формирует один запрос к БД
В С++ скорее всего будет просто цикл с наивным перебором элементов по условию. Так же можно и на шарпе написать. Но если очень хочется имено LINQ синтаксиса, можно использовать CLINQ. Или что-то свое сделать, уж лямбды-то в плюсах имеются
Мне кажется, это должен решать каждый программист сам. Например, пользоваться только модерн C++, запретив себе использовать старые парадигмы после перехода на новый стандарт. Тогда код будет написан в одном стиле, понятен и легок в масштабировании. Получится фактически тот самый новый прекрасный язык с небольшим количеством нужных инструментов. И новый язык изобретать будет уже не нужно только для того, чтобы новички не "стреляли себе в ногу", просто потому что им в руки попалось ружьë. То есть искусственно ограничивать набор инструментов путем создания нового языка
В моем случае это были ресурсы OpenGL, к которому из других потоков обращаться запрещено драйвером. А объекты могут удаляться и создаваться в разных потоках. Пришлось писать отдельную очередь, которая собирает графические ресурсы, а потом основной поток, владеющий контекстом OpenGL, все это обрабатывает, когда до него добирается
Очень актуально для игрового движка. При отрисовке каждого кадра приходится создавать и чистить большое количество данных (треугольники, иерархии игровых сущностей). Быстрее всего сразу "застолбить" побольше памяти, а потом с помощью собственного аллокатора брать оттуда кусочки под расчеты. Поскольку игра должна работать быстро и плавно, обращаться в ОС за памятью не эффективно, а данных перекладывать с места на место надо очень много
Действительно, после такого опыта многопоток кажется не сложным. Это и "один пишет, другие читают", и "как танцевать девушку". При этом мютексы ставились только на очень узкие места (в основном взятие или добавление объектов в контейнеры).
Но поскольку у нас игра, объекты может создавать и игрок, и поток подгрузки. Возникают очень хаотичные взаимодействия потоков в самых разных комбинациях. Каким-то образом всë это получилось разрулить и заставить работать быстро и без вылетов.
В том-то и дело, что существует не только вэб-программирование. Можно связать жизнь с чем-то другим и с линуксом вообще никогда не сталкиваться. Если уж на то пошло, то для клиентских приложений лучше подходит Макось, потому что на чем-то другом разрабатывать под Айос нельзя, а клиентские программы очень хотят существовать и там тоже. Нельзя именно из-за хитрой лицензии Эппл, запрещающей разработку на чем-то другом.
Она и начинается с дисклеймера о субъективности написанного. Но при этом в самой статье встречаются радикальные заявления о понятии "инженер", что немножко противоречит дисклеймеру.
Спасибо за статью. Очень ëмко и просто навела на некоторые мысли.
Я не мог начать пользоваться Rust пять лет назад из-за того, что просто не представлял, как со всеми этими ограничениями можно что-то сделать. То есть нужно действительно начать мыслить по-другому.
Сейчас у меня есть опыт параллельного программирования в С++, в этом очень сильно помогли умные указатели, которые следят за владением объекта и чисткой памяти. Они гарантируют отсутствие битых указателей, т.к. пока какой-то поток "одолжил" указатель, память в нем не чистится. Как недостаток, нельзя сказать точно, когда в рантайме объект освободится и в какой момент запустится деструктор, а главное из какого потока (например, к OpenGL можно обращаться только из главного потока, поэтому просто так из деструктора объекта, хранящиеся в shared_ptr, данные OpenGL не удалишь).
Тем не менее умные указатели и ссылки в плюсах - очень крутые средства, спасающие от выстрела в ногу. Мне кажется, заставив себя на них перекатиться, я постепенно дойду и до понимания Rust.
А теперь вопрос (он наверняка гуглится, но если всë гуглить, то о чем писать в комментах?). Rust многие вещи делает в компиляторе. Это ведь и по эффективности получается лучше, чем ООП в плюсах со всякими контейнерами и умными указателями? В плюсах это наверняка сплошной рантайм и достаточно тяжелый.