3238

Советы тем, кто реально хочет стать программистом6

1. Перед тем, как отвалить крупную сумму за курсы - попробуйте почитать книги, это сильно дешевле. Например, по Java есть замечательная "Философия Java", хоть и немного устаревшая. Ключевые концепции языка в ней изложены просто великолепно.


2. Не верьте тем, кто обещает быстрый прогресс и гарантированное трудоустройство - это верный признак инфоцыган (за очень редкими исключениями). В той же Java сейчас требуется гигантский объем информации для успешного трудоустройства - ну как минимум кроме синтаксиса еще Spring, базы данных, Maven/Gradle, автотесты. За три месяца это выучить невозможно. За год -  вполне.


3. Избегайте курсов для "умственно отсталых". Тут нужно понимать: можно немного сгладить кривую сложности в начале - подбирать всякие метафоры с паровозиками при объяснении логических операторов, делать красиво анимированные схемы etc. Это отличное завлекалово, когда после вывода трех строк на экран и примитивной программки типа "четное ли число или нет", кажется, что это просто и вообще непонятно, из-за чего сыр-бор. Но потом вам попадется какой-нибудь принцип подстановки Лисков, который вообще-то одна из базовых концепций ООП - и его уже с помощью метафор так просто не объяснить. Или вот вы читаете про особенности индексации таблиц в БД, например, и не понимаете ни слова. Некоторые концепции сложные сами по себе. Это как выпустить учебник "Квантовая механика для дошкольников" (нет, я не уравниваю в сложности квантовую механику и программирование). 


4. Вообще старайтесь не забывать про теорию. Немного алгоритмов (хотя бы простейшие сортировки типа пузырьковой и вставкой, бинарный поиск, оценка сложности). Немного структур данных - массивы, связанные списки, бинарные деревья, мапы. Немного спецификаций типа REST.


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


6. Обязательно выкроите время на git. Просто поверьте - он будет нужен.


7. Если не знаете английский - учите. В контексте IT та информация, что есть в рунете - это жалкий, недостойный упоминания огрызок по сравнению с тем, что можно найти на английском.


8. Проявляйте инициативу, не ждите, будьте готовы работать за копейки - главное опыт. Свою первую работу я нашел просто - вбил в поисковике "Java Хабаровск работа", открыл первый попавшийся сайт (галера для госа), скопировал телефон, написал в WhatsApp и напросился на собес. Думаете, меня взяли сразу? Нет, меня попросили написать реализацию стека. Я попробовал родить код на доске на массивах, и спустя полчаса меня милостиво отпустили - доучиваться. В итоге я к ним попал через три месяца. Зп на испытательном - 25к, 35к после испытательного.


9. Если уверены в своих силах и чувствуете, что готовы искать работу - старайтесь абсолютно всеми возможными способами попасть на стажировку, такую, где вас условно кинут на амбразуры, где ваш первый pull-request разнесут в такие щепки, что вы потом будете четыре дня плакать на больничном. Именно в таких местах качается реальный скилл программирования. Рост в начале идет только при условии разницы в опыте между участниками, если все на одной ступени - это стагнация.


10. Многие новички не могут родить pet проект, это нормально. Просите тестовое. Поскольку до мидла вам еще как до луны, цель вашего тестового - просто проверка на то, как вы будете писать код (спагетти, названия переменных транслитом,  методы по 600 строк и другие признаки идиота сразу отпугнут) и знаете ли вы базовые концепции языка (если в языке иммутабельные строки и вы в цикле их конкатенируете - тревожный колокольчик).


11. Самое главное - подумайте, готовы ли вы этим заниматься всю жизнь даже за большие деньги? Готовы ли вы регулярно говорить "я не знаю, покажи мне, как надо"? Готовы ли вы защемить свое ЧСВ и признать, что всегда и в любой момент времени рядом с вами может оказаться кто-то, кто знает больше вас - и вам придется у него учиться, даже если вы principal с 15-летним опытом? Готовы ли вы в свободное время висеть на литкоде по два-три часа в день, чтобы не уходить в крудо/формошлепство? Потому что нет большего вреда для проекта, чем закостенелый дебил, который тащит в работу архитектурные решения, популярные эдак лет 15 назад. Или придурок, который выгружает всю таблицу БД в оперативку, чтобы отсортировать ее там и вытащить одну запись, потому что он так делал раньше и это работало. Или идиот, который считает, что автотесты - это трата времени, мол, есть же тестировщики.


Потому что если не готовы - пожалуйста, не идите в программисты.

Лига программистов

2.3K постов12K подписчиков

Правила сообщества

- Будьте взаимовежливы, аргументируйте критику

- Приветствуются любые посты по тематике программирования

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

Вы смотрите срез комментариев. Показать все
9
Автор поста оценил этот комментарий
Я может покажусь не совсем умным и опытным программистом, но в чем проблема конкатенации имутабельных строк? В языках, которые мне известны строк везде имутабельны(не берем в расчёт Си строки из C/C++), и конкатенация, единственный способ слепить из 2 строк одну(ну ладно не единственный, но основной)
раскрыть ветку (33)
6
Автор поста оценил этот комментарий

Реаллокация памяти. Я далек от этой темы в Java, но я бы слепил массив строк в цикле, после цикла слепил бы итоговую строку нужного общего размера и заполнил бы ее данными из массива.

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

Примерно это происходит в StringBuilder'е, а если ещё и сначала размер предпосчитать, то вообще будет огонь.

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

Каждая конкатенация - новый объект, поэтому именно в цикле этого делать не стоит, уборщик мусора чудеса творит до определенного момента. В Java есть StringBuilder/Buffer. В других языках с иммутабельными строками тоже наверняка есть что-то подобное.

раскрыть ветку (10)
9
Автор поста оценил этот комментарий
В Java был StringBuilder. В последние версиях хитрую оптимизацию подвезли, и можно безвредно складывать сырые строки.
Вообще современные промышленные языки уже достаточно сложны чтобы теоретически верный принцип мог стать ложным на практике и наоборот
раскрыть ветку (8)
0
Рыцарь горячего
Автор поста оценил этот комментарий

Вы вводите в заблуждение. "Хитрая оптимизация" - это, вероятно, https://openjdk.org/jeps/280 (в 9й джаве, да). И она никак не связана с циклами, она про позднее связывание через invoke dynamic, что позволяет JiT'у выбрасывать лишние аллокации в некоторых частных случаях. Циклы в этот частный случай не входят.

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

Это как вопрос про выбор коллекции для частого удаления/добавления элементов. В теории в Java это LinkedList - пару ссылок поменять в соседних объектах и дело сделано. На практике - начиная вроде как с 11 версии ArrayList оптимизирован через нативный метод System.copyArrray (или как-то так, не помню точное название), который ускоряет эту операцию в хрен знает сколько раз. По факту, теперь LinkedList нужен только в редких ситуациях, когда надо гарантированно сохранить изначальный порядок вставки.

раскрыть ветку (6)
2
Рыцарь горячего
Автор поста оценил этот комментарий

System.arrayCopy в ArrayList был с начала времён, и он не просто нативный (нативные методы стоят очень дорого), он на интринсиках - JiT инлайнит вместо него непосредственно имплементацию, в зависимости от процессора, обычно на SIMD.

В споре ArrayList vs LinkedList придумать ситуацию, когда LinkedList лучше, безумно сложно. Показательный твит от Джошуа Блоха, автора LinkedList'а в джаве: https://twitter.com/joshbloch/status/583813919019573248?lang...

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

System.copyArrray будет охеренно эффективен, если добавляешь/удаляешь в конец списка. Как только встретиться операция с началом списка - будет уже не так весело.

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

Только вот LinkedList насмерть ломает сборку мусора, потому что придется сканить все ссылки последовательно, без какой бы то ни было возможности параллелить. Самая бесполезная коллекция. Если ArrayList стал недостаточно эффективен, придется писать что-то своё, узкозаточенное под ваши задачи.

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

Fair enough, но будем честными - с изначальными преимуществами ArrayList + докрученными к нему оптимизациями LinkedList становится нужен прям ну в совсем редких случаях. В большинстве случаев вставка идет в конец списка через банальный add() без индекса первым параметром.

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

Ну да, обычно вставка в конец. ArrayList поди кусками с запасом память под себя выделяет.

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

При превышении размера массива аллоцируется новый, размером х1.5.

0
Рыцарь горячего
Автор поста оценил этот комментарий

Помимо сборки мусора есть ещё escape analyze, который может вообще убрать аллокацию объекта, когда JiT смог доказать (сам себе), что объект не покидает локального скоупа. Но конкатенацию строки в цикле это действительно никак не спасает)

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

В Java наверное какой-нибудь String Builder есть

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

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

раскрыть ветку (15)
4
Рыцарь горячего
Автор поста оценил этот комментарий

Нет ни одного языка, где о подобном не надо парить мозги.

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

В JavaScript есть оптимизации на уровне движка, так что мозги парить не надо. Хотя возможно тот же .join() в каких-то моментах подойдёт лучше. Есть правда другой прикол, что из-за этих оптимизаций при получении строки нормального размера из JSON'а вся строка с этим JSON'ом может висеть в памяти, что неприятно, если это многомегабайтный ответ от сервера. А вот в Питоне со строками всё плохо, оптимизаций нет, легко на этом попасть.

раскрыть ветку (3)
0
Рыцарь горячего
Автор поста оценил этот комментарий

Нет, поверхностный гуглёж показывает, что ничего магическом образом не происходит (вот например: https://twitter.com/mourner/status/973664460291411969?lang=e... ), что вполне понятно: нельзя ничего чудесно оптимизировать, если заранее не знать размера данных (на самом деле можно: если создать огромный массив примитивов, вроде Uint32Array, то он будет создан мимо кучи через вызов malloc, который в свою очередь породит системный вызов mmap, который в свою очередь выдаст виртуальную память, которая будет материализована в физическую лениво по старницам при доступе, но к строкам это очевидно не относится).

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

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

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

Мы говорили о конкатенации. А эта "оптимизация" когда-то была и в Java, отпилили по озвученной вами причине.

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

О конкатенации строк? Понятное, дело, что неочевидные вещи есть всегда, но если это происходит на таком базовом уровне с такими базовыми вещами - это фундаментальная системная проблема. В принципе вся ява - фундаментальная системная проблема.

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

Ещё раз: нет ни одного языка, где конкатенация иммутабельных строк в цикле работала бы "автоматически".

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

А если в языке все иммутабельное?

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

А если все иммутабельное, это создает отдельный род проблем

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

Каких?

0
Рыцарь горячего
Автор поста оценил этот комментарий

Какая разница? Если есть императивные циклы, то всё то же самое. Если речь про функциональщину, то она, на текущий момент, несовместима с понятием "производительность".

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

Как раз о фунцкиональщине речь и идет. И по производительности, это вы где то прочитали и повторяете или на основе личного опыта пишите?

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

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

раскрыть ветку (3)
0
Рыцарь горячего
Автор поста оценил этот комментарий

Я исхожу из понимания принципов работы компиляторов, в т.ч. JiT'овых. Хаскель обладает кучей проблем с ленивыми вычислениями, которые, очевидно, ленивы не за бесплатно: требуют совершенно невменяемого количества памяти и паразитной нагрузки при уже непосредственном вычислении. "Может понять" - это особый кайф. А может не понять, и чаще - не понимает. А ещё хуже, когда сегодня всё понимал, завтра кто-то сбоку чихнул (а с функциональными языками это прям частый кейс), и всё, в совсем другом конце всё стало значительно медленнее. В Java относительно легко предсказать что и как скомпилируется JiT'ом, в крайнем случае профильнуть, благо тулинг развит лучше, чем во всех остальных языках вместе взятых.

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

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

«компилятор Может понять» это не некая угадайка или как карта лежат. Вот запрограммирована ассоциативная операция с некими константами в чистой функции. Этих знаний компилятору достаточно и не надо ничего гадать.  

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

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

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

С константнами - конечно же всё будет работать, единственное, где справляются фактически все компиляторы.

Когда производительность не важна - конкатенируйте строке в цикле, всё будет ок. Просто в мире Java, оказывается, пишут код, где производительность важна.

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

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

Хм, может влезаю не на свою территории, но в php, мне говорили тоже, что конкатенация зло, а правильный способ - это собрать строки в массив (желательно причем не циклом, а функцией типа array_map()), а потом один раз сделать implode(‘’, $arrayWithLines);

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

Ну конкретно сейчас в Java проблем с конкатенацией нет. Раньше юзали StringBuilder, но сейчас внутри конкатенации наделали много классных оптимизаций и в этом необходимость отпала. Более того насколько знаю они не остановились и продолжают    усовершенствовать внутри этот механизм

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

Проблема маляра (гуглится - сложность вместо N становится N* M) для кучи use-case когда тебе надо собирать строку (типа сборать адрес или что-то похожее) или чуть-чуть подшаманить (типа окончания менять).

Не зря в языки с иммутабельными строками стали заводить "string arena".

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

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества

Недвижимость и ремонт

Теги

Популярные авторы

Сообщества