5171

Ответ на пост «"Программисты не умеют программировать"»19

А я соглашусь, хоть и сам программист.

Я типичный крудошлеп, без бэкграунда в computer science. Кое-как выучил Java Core, кое-как посмотрел Spring, что-то там по реляционкам - и устроился на работу джуном аж за 35к в Хабаровске в местный бодишоп. Там, понятное дело, уже подтянулся к остальным, через три месяца круды пилил не хуже местных "мидлов". Через семь месяцев Сбербанк схантил за 100к с переездом в Москву, я и согласился - что я, дурак что ли?

Там зарплата довольно быстро выросла до 135к, и в принципе на этом этапе я считал, что схватил госпожу удачу за хвост - я весь такой умный, зарабатываю x2 по Москве и x5 по России. Правда, когда я попробовал пройти собес в другую компанию (по-моему, Luxoft), моя радость быстро омрачилась - меня спросили что-то примитивное, в духе "а как устроена HashMap в Java", а я вообще ни сном, ни духом. Какие хэш-функции, нафиг они нужны? Какие коллизиии? Какая потокобезопасность? Ребята, есть класс HashMap, как его использовать, я знаю, что вам еще надо то?

Впрочем, печалился я недолго - просто выучил ответы на типовые вопросы Java / Spring собеседований, благо, таких материалов в интернете море. Да, на одном собесе не смог реверснуть связанный список и пролетел, зато на другом были довольно типовые вопросы, и я без особых проблем перешел уже на 250к в другой бодишоп.

Был ли я хорошим крудошлепом? О да, я мог быстро написать хороший, покрытый тестами круд на Java. Был ли я хорошим программистом? О нет.

  1. Многопоток - паника

  2. Другой ЯП - паника

  3. Вообще что угодно, связанное с алгоритмами или нестандартными структурами данных - паника

  4. Внутрянка Java (как устроена JMM, как работает GC и т.д.) - паника

  5. Просьба задизайнить приложение сводилась к разбиению на микросервисы. Любые попытки вывести на темы доступности / производительности / консистентности данных - паника.

  6. Любые попытки выйти за пределы базовых понятий реляционок - паника.

И вот уже второй год я пытаюсь закрыть эти пробелы и дать самому себе нормальное образование в computer science.Алгоритмы, concurrency, базы данных, распределенные системы и вычисления, внезапно - базовая математика (дискретка, комбинаторика, теорвер), битовые манипуляции. Пригодилось ли мне это на работе? Нет, я все так же пилю круды в массе своей (сейчас меньше, т.к. работа связана больше с менеджментом). Разве что знания системного дизайна здорово выручает при создании архитектуры приложений. Но.

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

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

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

Вы смотрите срез комментариев. Показать все
11
Автор поста оценил этот комментарий

А че там concurrency? У вас JVM блин и async/await как у всех. Сейчас все на SpringBoot с blueprints и Hibernate. Есть конечно отчаянные с raw SQL, но хрен пойми зачем. Java это джунгли абстракций и так

раскрыть ветку (17)
7
Автор поста оценил этот комментарий

О каких асинк-эвэйтах речь? В Жабке их нет, в Котлине они виде корутин, JVM ваще не про это, не помню спецификаций на такое. Можешь пояснить, что имел в виду пожалуйста?

раскрыть ветку (9)
0
Автор поста оценил этот комментарий

Черт попутал. async/await в .NET завезли, а в Java еще ThreadPoolExecutor, футуры и корутины использовать предлагают.

Штош. Java много где еще используется и видимо асинхронность там не всралась.

Тогда действительно кучу времени реализация занимает.

Ну без куска хлеба никто не останется. Вряд ли банковские сервисы будут на Go перепиливать или Rust ради миллисекунд в бенчмарках.

Вообще забавно получается. Бич питонистов это GIL, а бич джавистов JVM.

У .NET даже не могу представить что. Наверное если на Mono превозмогать, хотя Core на Linux удалось запустить, правда ресурсы (Pi4 4Gb приложение скушало в момент).

Так что да, не всегда у разработчиков руки кривые. ЯП тоже со своими прибабахами как всегда.

раскрыть ветку (8)
1
Автор поста оценил этот комментарий

Бич питонистов это GIL

Таки наконец-то с прошлого года core devs взяли путь на постепенное избавление от GIL в CPython:
https://habr.com/ru/articles/801675/

Обещают соответствующие флаги сборки уже в 3.13, а полный переход завершить за 5 лет.
Я когда в прошлом году новость на опеннете прочитал, аж бутылочку красного раскупорил)

0
Автор поста оценил этот комментарий

Чувак, все нормально в джаве с многопоточкой. Нет асинк-аваит, ну и ладно. Это делается через код. Даже виртуальные потоки (аналог корутинам) завезли. Джава, имхо, лучший язык на данный момент.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Тоже считаю что всё нормально. Про лучший язык, конечно, не очень уверен)

0
Автор поста оценил этот комментарий

Вряд ли банковские сервисы будут на Go перепиливать или Rust ради миллисекунд в бенчмарках.

А вот и не ради миллисекунд в бенчмарках, а ради миллионов на оборудование. Асинхронность позволяет дешевле использовать ядра и не упираться в лимиты системы, типо линуховых лимитов на треды. И ещё очень большая экономия на переключении контекста. Но всё переписать дороже чем платить за инфру, так что не перепишут скорее всего, да.

Java много где еще используется и видимо асинхронность там не всралась.

Лишним не будет, но сделать сложно.

У .NET даже не могу представить что.

Всратый сборщик мусора)

хотя Core на Linux удалось запустить

Он там давно, очень давно, уже лет 6-8

Автор поста оценил этот комментарий

В Яве, по крайней мере андроидной, есть asynctask (который хотят убить). В дотнете асинки для тех, кто не осилил тренды и обертки над нами, типа бекграудворкера.

раскрыть ветку (3)
1
Автор поста оценил этот комментарий

Асинки это не про многопоточность, а про асинхронность, совсем другая степь.

раскрыть ветку (2)
1
Автор поста оценил этот комментарий

Asynctask это блин хелпер к Треду, это и есть многопоточность. И все так же требует синхронизации для доступа к объекту в другом потоке, например к контролам.

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

раскрыть ветку (1)
Автор поста оценил этот комментарий

Не, немножко не то, тебе правильно подсказали, погугли разницу между concurrency и parallelism

1
DELETED
Автор поста оценил этот комментарий

Ну вот хотя бы пример из книги, которую сегодня читал - использование synchronized на всем методе - это хреново, и лучше использовать блоки. Понятное дело, что в stateless приложениях это особо не упало, но по правде, есть ощущение, что я просто так и не дорос до проектов, где понимание теории многопотока - это реально важно, и воткнуть аннотацию async / впилить шедулер недостаточно.

раскрыть ветку (6)
3
Автор поста оценил этот комментарий

Такие проекты - редкость. В большинстве случаев хватит какой-нибудь RxJava для асинхрона. И думать про локи, synchronized и прочее вообще не придется.

1
Автор поста оценил этот комментарий

Ты попутал синхронизацию и синхронность/асинхронность. Первое - это из мира многопоточки, а второе - способ взаимодействия.

0
Автор поста оценил этот комментарий

че-то я запуталась. async это же про асинхронность, то есть всякие JavaRx, реактивные библиотеки вроде Mutiny и корутины Колтина? А synchronized это скорее про доступ к данным. Я понимаю, почему stateless решает проблему synchonized, там по идее не должно быть общих переменных, но не понимаю, как это связано с async/scheduler.

Или я что-то не так поняла и мне тоже пора почитать что-нибудь? :D Что за книга?

раскрыть ветку (2)
1
DELETED
Автор поста оценил этот комментарий

Все в порядке, это я просто про мои прошлые познания в многопотоке, которые сводились к «ну вроде аннотация async помогает стартовать процесс в отдельном потоке, это все»)

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Кстати, я в java изрядно отстала от жизни, но советую посмотреть Котлин и то, как там это сделано. Там не потоки (ну, внутри это все-таки потоки), а скорее код, который исполняется в потоке, но не обязательно тратит на себя целый поток. Получается писать неблокирующий код, если одна корутина закончила, другая может использовать тот же поток, то есть они гораздо легче и работают как load balancing между потоками что ли. То есть если использовать подходящую библиотеку для rest, то количество одновременных запросов просто в разы вырастает, если писать неблокирующий код.

Что-то я много написала :D Надеюсь, не напридумывала лишнего. Я тоже боюсь многопоточности :D

0
Автор поста оценил этот комментарий

synchronized на методе объекта (не статическом) === synchronized на экземпляре этого же объекта контейнер (читай сахар)

Когда есть конкурентный доступ к одному ресурсу критически важно.

Но (накину) в случае когда у тебя несколько образов крутятся нужно уже чуть больше заморочиться...

а, вообще, правильной дорогой идете, товарищ

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку