• Какой выбрать учебник по Java для новичка в программировании?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Если будешь читать много книжек - научишься читать книжки.
    Если будешь писать код - научишься писать код.

    Не нужно поперечитывать книжки и только потом начинать что-то писать.
    Не нужно прочитать ЦЕЛУЮ (на самом деле всего лишь одну) книжку и сразу писать свою большую 2д игру.
    Напиши сперва простую программку. Простой калькулятор. Простое окошко с кнопкой. Если 2д игру, то крестики нолики или морской бой - тебе нужно освоить базовые вещи, чтобы не было простых вопросов. Потом усложняй.

    А цела куча ошибок? Я просидел 2 дня над 5 минутной задачей? Ошибка 1 надо было понимать в начале что это " a" а не "a", пазлы ошибки и т.д

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

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

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

    , а это нормально что прочитав книгу ты вот захотел что то написать, перед этим посмотреть и проанализировать как кто то написал что то похожее

    Ну а почему бы нет? Все упирается исключительно во время. У кого есть возможность анализировать, у кого нет. Анализировать как это написали другие полезно. Прикол в том, что "посмотреть" чужой код - это не полистать. Это нужно сесть и долго разбираться, пока вникнешь в логику чужого кода. Быстро подсмотреть можно какую-то совсем мелочь.

    А вот теперь другая ситуация. Вас привели на завод и прикрепиле к мастеру, вам не стали показывать ВСЕ инструменты и объяснять как они работают, а МАСТЕР стал делать КАРКАС для двигателя (ну то на что все крепиться будет) и попутно ПО шагово объясняя ход своих мыслей

    Вот на базе вашего примера поясню суть.
    Двигатель, а точнее современный двигатель, это такая деталь, которую создавали много людей на протяжении поколений. И пока вам МАСТЕР пояснит ход всех своих мыслей, у вас уйдет жизнь.
    И основная проблема, что вы предыдущую мою фразу может и прочитали, но не осознали. Жизнь человека - действительно ОЧЕНЬ короткая. И если 20 летнему студенту может показаться, что 40 лет это уже старик, можно умножить 20 на два и внезапно осознать что молодой 20-летний студент уже половину своей жизни прожил.

    Поэтому иногда стоит сразу показать все существующие инструменты ВКРАТЦЕ, чтобы человек знал что уже было изобретено и можно взять готовым, а потом уже давать задачи, чтобы пользуясь готовыми инструментами новичок создавал программу, а не изобретал с нуля колесо, молоток, увеличительное стекло и так далее.

    Учись задавать правильные вопросы. Это когда ты знаешь примерно половину ответа. В ИТ начало пути это не тогда, когда ты выбираешь книгу почитать. А когда ты уже написал свою первую сложную программу, и после этого, читая ОЧЕРЕДНУЮ книжку думаешь что ее можно было написать гораздо лучше и гораздо проще.
    Ответ написан
    Комментировать