Highload fwdays — спікери зі Stackoverflow, Netflix, Google, AWS, Rovio | Київ, 5 жовтня
×Закрыть

Этот хитрый переход от «учи матчасть» к «решай задачу»

Всем привет!

В процессе самообучения программированию с нуля без технического образования столкнулся с такой интересной штукой: на традиционный для новичков вопрос «С чего начать?» одна половина знакомых спецов сказала читать хорошие книги или пройти онлайн-курсы, а другая предложила сразу приступить к написанию кода и обучаться по ходу («решать реальную задачу»). В итоге спустя год самообучения я до сих пор не уверен, что понимаю самое оптимальное соотношение теории и практики.

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

В общем... получается в процессе самообучения легко свалиться в крайности:

а) если знаешь слишком мало синтаксиса и принципов (алгоритмы, структуры данных, ООП, паттерны) попытка сразу что-то программировать будет на 90% изобретением колеса, решением тупых синтаксических и логических ошибок, неупорядоченным узнаванием базовых вещей и частым переписыванием структуры и кода программы;

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

Мысли, комментарии? :)

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Про всевозможное изучение IT я на опыте понял такую вещь:
Иногда в книгах или видеокурсах какая-то глава обозначается как «advanced». Это обманчивое слово. На самом деле, почти все эти «advanced» темы — это повседневные нормальные вещи в реальных проектах. То есть слову «advanced» в учебниках не надо придавать значения. Это не «advanced», это всего лишь продолжение основ.

Я просто подытожу. Те люди, которые предложили вам

сразу приступить к написанию кода и обучаться по ходу («решать реальную задачу»)
дали вредный совет.

Вот именно поэтому я пошла на второе высшее в КПИ. Сейчас проходим теорию алгоритмов, там как раз и обьясняется на примерах, как самые простые алгоритмы, вроде того же сложения, вычитания, умножения, нахождения чисел Фибоначчи и т.д. какими алгоритмами этого можно добиться, а также сложность алгоритма, которая задается О(х). Что алгоритмы делятся по сложности на: линейные, логарифмические, полиномиальные, экспоненциальные. Сложность алгоритма зависит от числа операций. Вообще, все это очень увлекательно и затягивает. Рекомендую книгу, которую изучаю сама «Алгоритмы» авторы: С.Дасгупта, Х.Пападимитриу, У.Вазирани, перевод А.С.Куликова

Такое впечатление, что вам не сказали ещё одно важное свойство алгоритма — корректность. :-) Для большинства задач первое попавшееся решение является эффективным (использование памяти и времени в разумных пределах), потому что типичное количество входных данных мало́, то есть сложность алгоритма не имеет значения. Если кода много или он запутанный, то легко допустить ошибку, и корректность выходит на первый план.

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

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

Залежить від складності обраної мови програмування. PHP, Python — достатньо пройти 1-2 онлайн туторіала, щоб вже пробувати практикуватись. А в процесі довчати необхідні концепції і бібліотеки.

З C++ наприклад так не розженешся. Тут треба як мінімум книжку прочитати і трохи попрактикуватись на простих прикладах.

А далі, з будь-якою мовою, зв’язка теорія-практика в різних співвідношення, почерзі і паралельно :-) Загалом, без наявності практичного цілісного проекту практика буде не та.

Ось детальніше про практику, як шукати і де проекти: www.vitaliypodoba.com/...mmer-how-to-get-practice

Значит слушай....

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

По-моему все нормально. В процессе работы программисты постоянно сталкиваются с подобными задачами-проблемами и постоянно их решают. Это часть работы. С набором опыта просто значительно сокращается время на их решение.
Продолжайте учиться — пишите как можно больше приложений.

А потом увидеть что расстояние между кораблями высчитывается два часа вместо двух секунд — и переделать. И так далее.

Ну не факт, что новичек вообще догадается, что некая операция (особенно когда интуитивно много данных) должна проводиться за 2 минуты, а не 2 часа. В том то и беда: ты не знаешь чего именно ты не знаешь. Соответственно, не видишь где этого не хватает или где это является более эффективным способом. Это вечная проблема в процессе обучения :)

именно поэтому волшебный пинок в нужную сторону просто необходим в некоторых случаях

Ну не факт, что новичек вообще догадается, что некая операция (особенно когда интуитивно много данных) должна проводиться за 2 минуты, а не 2 часа.

Раз не догадался, значит все нормально. Когда что-то будет не так — ты точно догадаешься.

Оптимизировать можно многое и всякое — но не всегда это нужно на практике. Красивый и элегантный способ нахождения пути будет занимать 2 мс, а твой трэшевый и некрасивый — 50 мс. Я думаю, пользователь этой разницы просто не увидит.

Вот когда ты пользуешься своим приложением и думаешь: «да что а *ерня, че оно так долго/криво/странно/*ерово...» — значит, пришла пора подумать о более оптимальных способах. А гнаться за оптимизацией или «правильностью» решения, по-моему, не нужно.

Причем «красивый и элегентный» может оказаться таковым только для автора, а для того, кому в будущем придется разбираться в коде для исправления баг — самым трешовым (особенно, если автор «забудет» нормально оформить код) ибо вместо 4-5 строк занимает 4-5 страниц... Да и не всегда теоретически самое эффективное решение на практике является таковым. Например, учитывая, что размер кораблей в классическом морском бое максимум 5 — то простая оптимизация кода «с перебором» может дать больший эффект....

Книгу по алгоритмам выше порекомендовала ;) сама читаю/практикую взахлеб. Хотя там код на паскале, а я пишу на с#

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

2 Изучение программирования — это как строительство стены
Слой раствора, слой кирпичей — слой теории, слой практики. Можно так же сказать,что изучение чего-то это развитие по спирали: вы постоянно переходите от теории к парктике, и снова возвращаетесь к теории, только уже на другом уровне.

3 Теория идет перед практикой
Сначала вы что-то новое прочитаете в книге или учебнике, а потом пробуйте это на практике и закрепляете его практикой.

4 Теория идет после практики
Сначла вы получаете уникальный личный практический опыт, а потом изучение теории и документации помогает вам структурировать ваш опыт, лучше понять, что вы делаете и зачем.
Сюда я отношу такие темы, как Design Patterns — помогает улучшить существующие навыки проектирвоания, а так же книгу «Совершенный код».

Да не надо писать знакомому архитектору. Надо просто сделать приложение. Закончить его. А потом увидеть что расстояние между кораблями высчитывается два часа вместо двух секунд — и переделать. И так далее.

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

А потом увидеть что расстояние между кораблями высчитывается два часа вместо двух секунд — и переделать. И так далее.

Если ты знаешь, что оно изначально должно было считаться хотя бы менее минуты — есть зачем обращаться к архитектору, чтобы спросить, как этого достичь.

потому что эти двое между собой не смогут договориться относительно того как правильно нужно делать.

Обычно таки не так радикально.

Спасибо за комментарии. Фишка еще в том (фактически отвечая Roman Gelembjuk), что за этот один год самообучения я прошел только Java Core, а им на хлеб не заработаешь. Ведь это лишь база, на которой построены компоненты Java EE, которые, в свою очередь, являются строительными блоками для реальных (оплачиваемых) продуктов — веб-сервисов, веб-приложений и т.п. И вот получается, что уже бы и начал писать какую-то программу, но без знания Java EE она не будет похожа на что-нибудь, над чем я буду реально работать на должности юниора. Т.е. теперь получается мне нужно еще почитать\посмотреть по Java EE, и только потом склеивать некое веб-приложение используя и Кор и ЕЕ... как-то так я это пока вижу.

Так и есть. Я учил Java Core также по Хорстманну, затем решал задачи на Java Rush и по книге для подготовки к OCA Java SE 7 + смотрел лекции Головача на YouTube. Думаю, что теорию Core знаю не плохо. Но с таким набором знаний на собеседования, ясное дело, не очень то и зовут, поскольку практически везде требуется EE и набор фреймворков.
Сейчас изучаю Spring и Hibernate сразу по нескольким источникам, выбираю где понятнее. Делаю небольшое приложение, нашел тестовое задание и пытаюсь его выполнить. И получается так, что нужно что-то добавить, ты ищешь, как решить задачу, пробуешь одно, другое, приложение не запускается. И так по новой.

Так у вас нет работы? Маловероятно, что вы заработаете на хлеб программированием, даже имея все знания, потому что есть и другие критерии отбора программистов. Сначала надо найти работу, а потом учиться. Как ни странно это звучит. ;-) Или получить от кого-то обещание, что он найдёт вам работу. Иначе потратите много времени и сил впустую.

Баланс теорія-практика треба повільно міняти в бік практики. Після року читання книг ти вже маєш майже весь час практикуватися.
можна почати якись «серйозний проект» але там ти будеш вчитися на початку а потім піде рутина і важко буде себе заставляти продовжувати
а можна робити маленькі різні проекти весь час із якимись новими підходами чи методами але тоді не будо що показати в резюме.
треба щось вибрати з двох варіантів :)

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

оказал одному опытному джависту-архитектору
Сделай его «ментором», возьми непосильную задачу и приставай с вопросами 1000 раз в день, все что непонятно спрашивай (если не допер сам за 5 мин) :) Походу это самое быстрое и качественное, но он может не выдержать и послать :))))

У меня из года в год принцип не меняется: смотрю в книгу вижу фигу.
Пока мне не дадут реальную задачу (или я сам себе ее придумаю) и пока выдача гугла не станет фиолетовой — прогресса не будет. Так и живу...

Зачастую происходит так: человек читает учебник по синтаксису ЯП, набирает примеры из учебника, компилирует — исправляет ошибки компиляции, смотрит результат. Как только исправление ошибок компиляции перестает отнимать ощутимое время (т.е. вы быстро исправляете все на что ругнулся компилятор), значит синтаксис в основном изучен. С этого момента лучше разнести по времени теорию и практику, к примеру — утром теория, вечером учебный проект. Теорию лучше вообще изучать и повторять постоянно. А также искать работу.

проблема в том, что в одну кучу неосознано сброшено умение кодировать (синтаксис), умение алгоритимизовать (т.е. создавать алгоритм работы) и умение проектировать (разделение на компоненты, паттерны). разумеется, это всё в принципе и является умением программировать, но вот ваш ревьювер критиковал вас по второму умению, которое вы (насколько я вас понимаю) еще не начали изучать

по этой теме могу посоветовать классику: Т. Кормен и другие, «Алгоритмы: построение и анализ»

Подписаться на комментарии