Comments 41
4 года ВУЗа дают ту же теоретическую базу, что и курс. Круто! Я за такой курс готов платить любые бабки! Куда заносить?
Паренек без образования и с опытом в 1 (один) год в профессии, собеседует стажеров и раздает советы. Круто. Хороший стартап. Точно взлетит.
Мой знакомый более 2х лет на курсах Java. Там учат только ЯП и технологиям, алгоритмов не изучают. Не может утроиться юниором. Это как? Нормально?
Учиться 2 года с нуля - это норм. Примерный срок, за который можно пойти работать нормальным джуном, а не подделкой с "курсов за 3 месяца".
Алгоритмы - штука специфическая, и очень прикладная.
Конечно, нужно понимать как всё это работает, и что такое сложность функции. Но прям углубляться в них чаще всего необходимости нет.
Гораздо важнее комплексность навыков, отовсюду понемножку. Работа с GIT, UNIX, SQL, ORM, OOP, Docker, HTTP, HTML, Bash и уметь рассказать что всё это за букевки
Учиться 2 года с нуля — это норм.
Java объективно более совершенный ЯП, чем фортран-4 или алгол-6о. Но когда-то студенты за семестр изучали фортран-4 или алгол-6о. ИМХО Java проще, т.к. более совершенный ЯП. Искренне не понимаю, что там 2 года учить, даже с нуля. Мне трудно судить, т.к. знаю много ЯП и технологий. Так пару лет назад за 2 недели выучил CUDA, чтобы решить нужные мне задачи.
При наличии базы в виде какого нибудь другого языка на подобии питона - конечно всё учится за пол года, год.
Тут скорее не столько сам синтаксис языка, сколько зашкаливающее количество абстракций в виде СУРОВОГО ООП, и работы с JVM. Для восприятия которых нужно время.
На счёт фортрана не могу прокомментировать, т.к. его не знаю. Но повторюсь, что сложность изучения жавы - не в синтаксисе. А именно в подходах, на которые этот язык заточен. В ту же копилку можно отнести и C#
Как язык Java довольно простая, но для нее существуют фреймворки, и вот они очень сложные. Ту же экосистему Spring можно изучать и 5, и 10 лет.
Необходимо ли изучать всю экосистему спринг для того чтоб стать джуниор разработчиком? На мой взгляд, для начальной позиции будет достаточно минимальных навыков, все таки на то она и начальная.
можно изучать и 5, и 10 лет.
За сколько стареют технологии? 5, и 10 лет? ИМХО 1-2 года в лучшем случае. ИМХО Вы — оптимист. ИМХО мои знания по технологии CUDA 2х летней давности сейчас ничего не стоят, даже для юниора. Кому нужен спец, владеющий технологиями 10 летней давности?
Одних курсов недостаточно - нужно еще порешать реальные задачи, на CoDeWars, например, сделать свой PET-проект и обязательно довести его до продакшн, и на своей работе сделать что-нибудь на Java, что позволит прокачать скиллы и набраться опыта. На стажировку бесплатную пойти в конце концов.
Многим людям такой реальной работой просто лень заниматься, гораздо легче просто лежать на диване и страдать, что меня - такого супер-проходителя 100500 курсов, злые и неадекватные работодатели не берут даже джуном.
С нуля, то есть за плечами вообще никакого опыта программирования? Тогда это нормально. Я входил в Джава с опытом (хоть и очень давним) бейсика, ассемблера, паскаля, немного плюсов и на это ушел год. И то, многие вещи я лишь поверхностно пощупал, как многопоточность, например. Если бы я ничего раньше не слышал про ООП, то нормальное понимание только этой парадигмы запросто сожрало бы полгода, не меньше. А потом еще столько же на паттерны. Зато с Джава на Сишарп получилочь перепрыгнуть примерно за месяц. Тоже, конечно, джуновский уровень, но довольно крепкий.
Кстати, алгоритмы и структуры данных понимать таки надо, потому что они мозги правильно ставят. Мне очень помог курс от Брайана Седжвика и Кевина Вэйна. Там же на Курсере есть отличный курс по алгоритмам от Калтеха и замечательное введение в Хаскель. Последнее вот вообще считаю необходимым любому студенту - потом на многие вещи из ООП смотришь под другим углом и лучще понимаешь. Ну и классический SICP надо осилить. Хотя бы и на питоне.
Если бы я ничего раньше не слышал про ООП, то нормальное понимание только этой парадигмы запросто сожрало бы полгода
ИМХО если знать простой Виртовский Паскаль, то чтобы понять базовые принципы ООП достаточно всего пары дней. Подробнее см. Мифы и реальность ООП. На всякие "загогулины" типа множественного наследования нужно больше времени, но не полгода.
Там же на Курсере есть отличный курс по алгоритмам от Калтеха и замечательное введение в Хаскель. Последнее вот вообще считаю необходимым любому студенту — потом на многие вещи из ООП смотришь под другим углом и лучще понимаешь. Ну и классический SICP надо осилить. Хотя бы и на питоне.
Алгоритмы можно и 3 года изучать. Но, по Вашему методу к ЯП Java добавляется еще и Хаскель. И Scheme и Питон? А еще упомянули знакомство с ЯП "бейсика, ассемблера, паскаля, немного плюсов". На это с нуля и год потратить можно. Но я говорил про юниорский уровень Java (без изучения алгоритмов), а не про вузовскую программу, где за 5 лет пытаются сделать спеца-универсала в IT.
если знать простой Виртовский Паскаль, то чтобы понять базовые принципы ООП достаточно всего пары дней.
Как сейчас помню: 1996 год, я поступаю на первый курс провинциального ВУЗа. В этом городе живет бывший однокурсник моего отца, он программист, и его просят взять меня под крыло. На тот момент за плечами Паскаль и ассемблеры под всякие zx80 и подобное. Я прихожу к нему домой знакомиться: в комнате курятся благовония, все полки уставлены толстенными томами с документацией и бесконечными рядами сидюков, из колонок тихо играет King Crimson. Меня знакомят с семьей, сажают за комп и просят написать программку, в которой шарик летает по прямоугольнику и отражается от стенок. Для простоты в текстовом режиме и все углы под 45 градусов. На С++, который я не то что первый раз увидел, а даже впервые услышал про его существование. Кое-как с подсказками по синтаксису пишу. Потом просят сделать то же самое, но для сотни шариков и все с разными скоростями а заодно разными цветами. Я кое-как, но пишу. В голове Паскаль -- на ходу с подсказками транслирую в незнакомые мне плюсы. Компилируется, собирается, запускается. Чувствую себя неимоверно крутым в свои 16 лет.
А потом мне говорят, что все эти мои глобальные массивы и процедуры над ними -- это фигня, и дарят книжку Страуструпа, не помню точно название, но вроде бы "Язык программирования С++". Желтая, в мягкой обложке, мелкого дешевого формата. И сразу дают домашнюю работу: написать просмотрщик бинарников, который по заданному алфавиту находит в файле текстовые строки и выводит на экран только их. С возможностью скроллить это все туда-сюда по экрану. И он должен обрабатывать файлы, которые не влезают целиком в память.
Тащу эту книжку как божье откровение в общагу, вечером с трепетом открываю, пробегаю вступление с благодарностями и, наконец-то, читаю первую фразу, которая откроет для меня мир ООП: "Объект есть инкапсулированная абстракция".
Я, безусловно, тупой. Но вот мне понадобилась неделя (!) и несколько встреч с моим гуру, чтобы просто понять эту фразу. Именно нормально понять. И дальше было нифига не легче. Задание я это делал больше месяца. До сих пор использую его как тест для всяких вайтишников с курсов.
Через 20 с лишним лет я открываю для себя современные языки. Ну вот понадобилось. Беру Джаву и никаких проблем. Некоторое концептуальное недопонимание поначалу вызвали интерфейсы, но с этим тоже разобраться было не сложно, особенно с пониманием что такое тайпклассы.
То есть первоначальное понимание концепции шло очень тяжело. Я противился этим вашим объектам как только мог: зачем это всё? Нафига эти ваши абстракции нужны, я все решу структурами и массивами? И только потом уже стало понятно, для чего вообще это надо. А после знакомства с функциональными языками появилось более четкое понимание, что такое класс и интерфейс в ООП. Теперь представьте, что человек вообще нулевой, то есть он в принципе код структурировать не умеет, даже по Вирту: на процедуры и функции. И про область видимости данных ничего не знает.
по Вашему методу к ЯП Java добавляется еще и Хаскель. И Scheme и Питон? А еще упомянули знакомство с ЯП "бейсика, ассемблера, паскаля, немного плюсов". На это с нуля и год потратить можно. Но я говорил про юниорский уровень Java (без изучения алгоритмов), а не про вузовскую программу, где за 5 лет пытаются сделать спеца-универсала в IT.
Я по диплому -- сварщик. Инженер-технолог бла-бла-бла, но сварщик. А по работе -- звукорежиссер. Просто с детства программированием увлекался и доступ к "взрослым" компьютерам получил раньше, чем к Денди. Вы говорите про джуниор-уровень Джава, то есть знание языка с актуальной обвязкой. Имея базу в виде просто опыта самоучки, не обязательно ВУЗа, это можно схавать за полгода прилежных занятий. Не всем удается, но можно. Не имея такой базы -- шансов ноль.
И я уверен, что "юниорский уровень Java (без изучения алгоритмов)" никому вообще не всрался, ибо программирование != знание языка. Потому и не находят работу выпускники курсов. Язык они изучили, экосистему под него пощупали, а вот как задачи решать понятия не имеют даже в принципе. Хаскель, Scheme (лучше уж он, чем Лисп), и прочее -- это бонус. Они позволяют расширить кругозор. Посмотреть, как можно решать проблемы по-другому. Не ООП единым. Но если цель с нуля за полгода войти в айти -- то да, нафиг Scheme и SICP. Только не надо потом удивляться, что работу найти невозможно.
Объект есть инкапсулированная абстракция
При всем уважении к автору (Страуструп) эта фраза вне контекста большого смысла не имеет. Для интереса погуглил:
Сказанное выше можно сформулировать более кратко и строго: объект — это инкапсулированная абстракция с четко определенным интерфейсом.… При этом нет необходимости иметь доступ к исходному коду родительского объекта. Наследование позволяет создавать иерархии объектов.
И чем это сложнее записи (record) примитивного Паскаля? Понятно ведь, что поля (x,y) записи point инкапсулированы в эту запись, и к ним нельзя обратится прямо, а только указав имя записи point.x. ИМХО сложное слово "инкапсулированы" интуитивно понятно: закопан внутри какой-то капсулы. Так локальные переменные функции закопаны в этой функции, и у нас нет к ним доступа вне функции.
И я уверен, что "юниорский уровень Java (без изучения алгоритмов)" никому вообще не всрался, ибо программирование != знание языка. Потому и не находят работу выпускники курсов. Язык они изучили, экосистему под него пощупали, а вот как задачи решать понятия не имеют даже в принципе.
Полностью согласен. Я об этом и говорил.
Это сложнее record тем, что у нас появляется интерфейс. И помимо инкапсуляции появляется сокрытие данных. И вот зачем это надо и как правильно использовать споры не утихают уже не один десяток лет.
Разве инкапсуляция это не "сокрытие данных"? В Вики читаем:
Инкапсуля́ция (лат. in capsula; от capsula «коробочка») — размещение в оболочке, изоляция, закрытие чего-либо инородного с целью исключения влияния на окружающее. Например, поместить радиоактивные отходы в капсулу, закрыть кожухом механизм, убрать мешающее в ящик или шкаф.
Вообще говоря, нет. Это в языках вроде С++ с его трактовкой ООП сокрытие и инкапсуляция идут рука об руку и практически неразличимы. Но это совершенно не обязательно (семейство ML или Smaltalk хорошие примеры) и концептуально это разные вещи. Сокрытие, к примеру, вполне можно обеспечить вообще без инкапсуляции. И это необходимо понимать, если уж осваивать ООП, а не конкретную его реализацию в конкретном языке.
Но разговор про конкретный ЯП Java, и освоение его на уровне юниора. В некоторых ЯП есть хитрости, но если судить по tiobe, то у ML низкий рейтинг, а Smalltalk вне таблиц. Неужели Вы хотели сказать, что не зная ML и Smalltalk, невозможно понять инкапсуляцию, а, значит, ООП?
Я хотел сказать (впрочем, уже повторяюсь), что одним ЯП ограничиваться не надо, и неплохо бы чуть глубже разобраться в той парадигме, в которой собираешься работать. Даже если ты джун зеленый только что с курсов. Хотя бы для того, чтоб порядок в собственной голове навести.
Завтра пойдет этот джун Python ковырять (раз не нравятся вам редкие языки) и с удивлением обнаружит, что инкапсуляция там вполне себе есть, а вот сокрытия нет. А он и не думал никогда, что это вообще два разных принципа, которые, кстати, не только в ООП существуют, и служат они разным целям. Посидит, подумает, почитает книжки, может начнет задумываться, а точно ли надо каждое поле в Джаве делать приватным и тут же бездумно генерировать к нему сеттер. Да и вообще о дизайне своих классов задумается.
То есть, я имею сказать, что даже такую относительно простую штуку как инкапсуляция можно определять и понимать по-разному. И даже абстрактному джуну после курсов с одним ЯП за плечами полезно хотя бы просто знать об этом. Потому-что не зная, он так никогда и не задаст себе вопроса "А почему здесь сделано именно так, а не иначе?". А это очень полезный вопрос, от него мозг становится гладким и шелковистым.
ИМХО тут работает Бритва Оккама: "Не следует множить сущее без необходимости". Факт, что м.б. примитивное ООП успешно работает во многих ЯП. Может и возможно усложнить, но зачем?
Однако, Эйнштейну приписывают фразу "Make everything as simple as possible, but not simpler". Примитивное понимание работает, пока задачи простые. Нельзя же совсем избавиться от сложности, где-то она должна жить. Поверхностное и однобокое понимание принципов, безусловно, простительно новичку, но рано или поздно с этим придется разобраться. Не думаю, что стоит вникать в тонкости, если только начал учиться с нуля, там и так мозг перегружен новыми концепциями и усложнение ни к чему. Но надо понимать, что у тебя в голове сильно упрощенная картина и по мере роста знаний и опыта углублять её, расширять. Проблема в "джунах после курсов без алгоритмов" (и вообще без теории) в том, что они как раз этого нифига не понимают. А их так научили. Показали один вариант, один подход, а про то, что существуют и другие, рассказывать не стали. Да и этот единственный подход показали очень поверхностно. Потом в голове у людей каша.
По работе решаю сложные н-т задачи в области мат.химии, при этом мне достаточно ООП Delphi-7, ну еще иногда CUDA-C. Раньше был нужен ассемблер — много их знаю, начиная с PDP-11, но к ООП это отношения не имеет. Интересуюсь экзотикой, нпр., ЯП Dee, но это факультативное любопытство ...
PS BTW у меня были работы на VBA, SQL, JS, Фортране.
PPS Контрактное программирование — очень интересный подход. Может юниору нужно и его изучить? ;)
Вы задаете вопросы, на которые нельзя дать точный ответ. В каком-то контексте вполне возможно, что и нужно. Возможно, джун приходит на проект, где это самое контрактное программирование основное. А возможно, что никогда до конца карьеры не понадобится. У нас же нет должностной инструкции и формальных требований к компетенциям этого джуна, о чем тут можно рассуждать?
Если джун хоть краем уха слышал, что вообще есть такая штука, -- это ему сразу плюс. Если может примерно объяснить, в чем суть этого подхода, -- жирный плюс. А если еще и сможет рассказать, в каких случаях его оправданно применить, то, может, это уже и не джун вовсе и стоит к нему внимательней присмотреться? Я уже говорил не раз, кругозор еще никому не мешал.
кругозор еще никому не мешал
Согласен. Но расширять кругозор можно годами. А "джун" стареет. До 30 можно не беспокоиться, а когда 40+ уже дадут понять, что возраст перевешивает кругозор. (Я про знакомых).
Я ничего вообще не понимаю в вашей области (матхимия), но по результатам быстрого гуглежа совершенно не ясно, зачем вам ООП? Если я правильно понял нагугленное, то у вас там больше математики, чем химии. Графы, комбинаторика, теория групп, нелинейные дифуры и т.п. Функциональная парадигма, как мне кажется, тут гораздо ближе. А скорее всего можно вообще чисто в процедурном стиле писать. Структурное программирование и хватит. Что вам дает ООП? Удобный способ сделать формочки для интерфейса?
Что вам дает ООП?
См. простейшие примеры.
Удобный способ сделать формочки для интерфейса?
И это уже не мало.
См. простейшие примеры.
Посмотрел. Не увидел причины использовать объекты для этой задачи. Вполне подойдет любой ФП, там и количество кода будет раз так в десять меньше. Правда, не факт, что будет такая же скорость, но это надо уже измерять и твикать по мере необходимости. Можно это очень компактно и вполне эффективно сделать на Питоне без всякого ООП. Кстати, для заведомо разреженного графа лучше подходят списки смежности, а не матрица.
И это уже не мало.
Да, это хорошая причина писать интерфейс с пользователем на чем-то объектно-ориентированном. Но считать графы при этом можно и без объектов, которые на мой вкус тут только добавляют бойлерплейта и лишней сложности.
Не увидел причины использовать объекты для этой задачи
А я там отметил случаи, когда методы будут различны (полиморфизм). Однако, все решенные задачи сводятся к ассемблеру без ООП. И GUI возможно сразу на ассемблере написать без ООП, но зачем такой мазохизм? Я писал код для GUI на Маке без ООП — остались сильные впечатления.
Можно это очень компактно и вполне эффективно сделать на Питоне
Не думаю, что с выборкой 90 "лимонов" графов по 10 вершин каждый Питон быстро справится. См. Вики:
Классический Python имеет общий со многими другими интерпретируемыми языками недостаток — сравнительно невысокую скорость выполнения программ
Вы, скорее всего, не писали на питоне. Иначе бы знали, что под него есть нативные библиотеки, которые работают очень быстро. Я больше про то, что всю простыню кода из вашей статьи можно легко сократить раз в 5, а скорее всего и больше, если применить подходящей к задаче язык. Полиморфизм существует и вне ООП.
У вас там сплошная математика. Есть граф, есть его обход, есть задача нахождения минимального пути... Зачем для решения этой задачи объекты?
Ваша программа манипулирует данными путем неких не очень простых вычислений. Первичны тут данные, при этом их структура весьма проста. Вычисления легко инкапсулируются в функции. Данные собираются в алгебраические типы. Программа представляет из себя композицию функций, которые обрабатывают эти типы. Никаких объектов нафиг не нужно.
Меня вот подмывает написать, что давайте я ту вашу простыню на Дельфи перепишу на чем-нибудь более подходящем задаче и покажу, но, честно говоря, я не могу этого обещать, ибо фиг знает когда у меня будет на это время и желание. Я мог бы дать ссылку на модули Хаскеля, где эта задача уже давно решена
в более общем виде меньше чем в сотню строк, но вы же не прочитаете это...
Есть граф, есть его обход
Есть орграф, а есть не ор. Методы обхода будут разные.
давайте я ту вашу простыню на Дельфи перепишу
У меня реальные задачи сложнее, чем в статье. Будет у Вас желание — можете порешать проблему тысячелетия про изоморфизм графов;)
можете порешать проблему тысячелетия про изоморфизм графов
Ой, нет, увольте. Я для этого слишком тупой и это ни разу не сарказм. Мне трудно дается математика.
Есть орграф, а есть не ор. Методы обхода будут разные.
Да не так уж и важно. Вы так и не ответили, зачем вам ООП тут понадобился? Вы решаете чисто математические задачи над данными. То есть первичны "циферки", над ними идет работа. Ну просто же идеально для функций. А если еще и типы добавить, то просто красота. Зачем в подобных задачах ООП?
Так подумать и для GUI ООП не нужно: всего 4 "циферки" для каждого из десятков окошков — координаты верхнего левого и нижнего правого углов. А что окошки перекрываются, то это уже математика. "Зачем в подобных задачах ООП?" Перерисовывать окна по циклу, как было в ранних версиях MacOS — "просто же идеально для функций".
Я, пожалуй, еще одну историю из жизни расскажу, уж простите за занудство.
Муж школьной подруги моей жены решил вайти и начал изучать Сишарп. С полного абсолютного нуля, не имея понятия вообще ничего о том, как комп работает. На каком-то платном курсе. По текущей работе он металообрабатывающие станки на заводах настраивает, как ни странно, за копейки.
А я на тот момент как раз относительно прилично разобрался с Джавой с её фреймворками (на уровне, когда уже делают офферы на джуна) и пытался начать что-то пилить за деньги, а всё свободное время раскуривал SICP, Хаскель и в довесок структуры данных. Ну и накидал человеку ссылок на несколько хороших бесплатных курсов. А он сам попросил, между прочим, посоветовать, ибо развития у него не наблюдалось.
Он этот список посмотрел, и пишет: "Это что, блин, всё это надо знать?" -- "Ну, не всё, но большую часть очень желательно." -- "А... это что, год надо потратить?" -- "Да нет, больше, но искать работу можно начинать раньше." И человек как-то притух.
Я ему говорю: "Гитхаб используешь?" -- "Нет... А что это?" -- "Клевая штука, вот тебе ссылка почитать про гит. Давай сделаем совместно пару проектиков, будет тебе прокачка в приближенных к работе условиям." -- "А что делаем?" -- "Ну, давай для начала Game of Life напишем", и ссылку кидаю на вики. "Или, если хочешь, давай крестики-нолики сделаем. Сначала просто консольную приложуху на двух игроков, потом для неё бота на минимакс сделаем, затем сервер чтоб можно было заходить и играть или с живыми игроками или с роботами, причем разными. Со статистикой, кабинетом, писькомерками и т.п. Сайтик под это дело соорудим. Потихоньку, начнем просто с консоли и ботов."
И вот человек просто слился. То есть он сам спрашивал меня, какие задачки можно порешать, я ему их накидал (много больше приведенных выше), предложил совместную разработку, фактически менторство (на его нулевом уровне я вполне себе ментор, ага), а человек -- просто слился. Ой, это всё для меня слишком сложно, я ничего не знаю про конечные автоматы, тут какой-то минимакс, да еще и с отсечением, а вот тот курс по алгоритмам, я вообще ничего не понял, что за деревья, графы и зачем мне это всё...
Итог. Второй год уже перевалил за половину. Человек забил на Сишарп, теперь он платит деньги за изучение Джавы на курсах при Бауманке. Написать "Жизнь" Конвея для него по-прежнему -- сложно. Зато умеет поднять простенький круд на спринге. От совместных проектов отказывается, да я и предлагать перестал.
Как думаете, он долго работу будет искать?
Как думаете, он долго работу будет искать?
Очень надеюсь, что очень долго при таком подходе. Сейчас многим таким, кто "Жизни" боится, удается устроиться и они начинают калечить хорошо работавшие сайты. Например, в крупном инет-магазине каждые 2 недели заказываю еду. Был удобный сайт, а теперь новый дизайн переселяет меня из Москвы в Тверь, что я не делай с профилем.
Написать "Жизнь" Конвея для него по-прежнему — сложно.
Уэзерелл свою великую книгу "Этюды для программистов" начинает главой под названием "Жизнь диктует свои законы" — ИМХО это название начинающим надо понимать буквально, а не только в применении к игре ;)
PS Про похожие проблемы на Хабре написал "Печаль: Хабра больше не будет?"
Дежавю какое-то)
Моя история:
Мне 20 лет, этим летом закончил техникум по специальности Сетевое и системное администрирование
Весной прошел практику в дата центре в it парке, написал там диплом про IP KVM. После выпуска и получения диплома, сразу накатал резюме на всем известном сайте, на следующий день пригласили на собеседование в it парк, и сразу же взяли на должность Технический специалист поддержки дата центра.
Моя мораль, что возможностей куча, лучше всего со школы начинать находить знакомства, повсюду столько стажировок, практики, олимпиад для студентов.
Почему работе с продуктом нельзя научиться на курсах? И как тогда быть студенту без опыта?