После прохождения первого этапа обучения, советуют начать писать свой проект. Но на самом деле это сделать не так уж просто.
Во первых - мы плохо представляем возможности языка.
Во вторых - в силу малого опыта мы не можем оценить степень сложности того проекта что мы выбрали и/или задумали. Как правило, если он интересен Вам, то он совсем не простой, и без наличие Ментора запросто может обломать зубки или на долго застопорить в плевом месте.
В третьих - в силу малого опыта, отсутствия навыков построения архитектуры ( если мы говорим о хоть каком то проекте) то он будет в виде одной большой спагетти и хардкодом. Костыль на костыле. И можно ли это считать обучением!?
Как правило это заканчивается тем, что такой проект бросается. Появляется ощущение неполноценности- несостоятельности. Падает уверенность и мотивация.
Если же выбирать из того что предлагает интернет, то как правило это на уровне примеров, простые до элементарного, без возможности как либо усложнить или оживить его. И опять мы пробегаем их бегло в качестве ознакомления и без какого либо желания копнуть глубже.
А то что не цепляет эмоционально - так же быстро забывается.
В связи с этим появилось желание обменяться опытом, идеями, обсудить интересные решения или может у кого есть предложения.
Допустим, у меня появилось идея написать элементарный игровой движок , на подобии движка из раздела Игры JavaRush.
Маленькое уточнение - в силу того что я параллельно капаю в сторону Android- движок будет под Android.
Пока это конечно громко сказано - "Игровой движок под Android". Но первые шаги уже сделаны.
Разобрался с отрисовкой сетки через Canvas.
Сделаны первые шаги по обработке события по нажатию кнопок и/или нажатия на экран Touch.
Hardy
32 уровень
все статьи по обучению рекомендуют...
Комментарии (16)
- популярные
- новые
- старые
Для того, чтобы оставить комментарий Вы должны авторизоваться
wan-derer.ru
23 августа 2021, 13:41
Тут всё просто. Есть идея проекта - делай. Нет идеи - продолжай идти по курсу.
То что проект не будет идеальным - это 100%. Ну и что? По мере получения новых знаний будешь что-то переписывать. Или вообще бросишь (проект, не учёбу). В чём опасения? Боишься лишний раз кнопы потыкать?
0
Vlad
22 августа 2021, 18:02
Имхо, следует расписать для себя концепцию проекта и его цели (что делает и для чего).
Концепцию нужно декомпозировать на отдельные крупные компоненты и "скоуп" работ
Далее декомпозировать все эти "компоненты" на отдельные фичи и задачи (epics ==> user stories ==> tasks).
Это поможет тебе сформировать общее видение проекта и обнаружить "проблемные" места, которым стоит уделить больше внимания, чтобы в процессе работы ты вдруг не осознал, что без костылей не обойтись.
Когда это будет готово, ты сможешь уже более предметно оперировать выбором паттернов проектирования, выбора подходящего стэка и т.д.
+ полагаю, тебе стоит все твои фичи приоретизировать, чтобы ты смог в голове или на листочке для себя создать так называемую "дорожную карту" жизни проекта и последовательность реализации. *все доп фичи со свистелками-перделками и красивостями нужно определить как самые низкоприоритетные и брать в работу уже в конце
+ опять таки, имхо, стоит сначала писать тесты, а потом уже сам код, чтобы ты мог отслеживать корректность реализации бизнес-логики своего приложения.
Думаю, что если ты будешь придерживаться подобного принципа, то шансы все забросить будут гораздо меньше
0
Hardy
23 августа 2021, 12:02
Так и делаю , дроблю задачу, пока не пойму как это реализовать . До архитектуры и паттернов пока еще очень далеко. Нет четкого понимания как это будет взаимоджействовать.
Пока только на уровне отдельных методов.
- Можно по подробнее про - "дорожную карту" жизни проекта ?
- Тесты! Вроде как понятно как и для чего! а начать как то не решаюсь!
0
Vlad
23 августа 2021, 18:31
Грубо говоря, "дорожная карта" проекта (project/product roadmap) - это его жизненный путь от начала до конечного готового продукта. весь этот путь состоит из так называемых ключевых точек (milestones).
Вначале ты должен сформировать видение проекта и, в идеале, задокументировать (project vision) чтобы ты не начал теряться в процессе работы и чтобы ты четко понямал что и зачем делаешь.
Далее тебе следует это декомпозировать (work breakdown structure или wbs).
Если ты пока что не понимаешь, каким образом заложить архитектуру, то это не страшно - есть шаблоны, которые тебе подойдут. Нужно будет немного позаниматься с гуглом. Можешь попробовать реализовать каркас, чтобы проверить на сколько подходит тот или иной подход (proof of concept)
Когда сможешь описать и структурировать свой объем работ - основной функционал (первостепенное), фичи(вторичное) и т.д, то можешь приступать к низкоуровневой декомпозиции задач (epics => user stories => tasks) и дальнейшей реализации проекта только с основным функционалом - основной рабочий прототип (mvp) - это уже какой то конкретный "майлстоун" + условный релиз.
После уже приступай к реализации другого объема задач - следующий майлстоун + условный релиз.
И так далее, пока проект не будет готов, исходя из твоей изначальной задумке и обозначенного объема работ.
- все что жирным шрифтом - рекомендую загуглить и разобраться.
- я тебе описал очень упрощенную версию подхода касательно процесса разработки. это кадется, на первый взгляд, излишним, но это очень приблежен к тому, как этот процесс организован в IT компаниях. Если разберешься с этим и привыкнешь, то потом проблем будет гораздо меньше.
- тебе есть смысл посмотреть что такое функциональные (functional requirements) и нефункциональные требования (non-functional)
+1
Hardy
24 августа 2021, 06:28
То что нужно! Большое спасибо! Теперь хоть будет общее представление как это все живет!
0
Сергеев ВикторMaster
21 августа 2021, 19:18
Да это и есть обучение. Когда вы пишите так как считаете нужным, а потом смотрите и оцениваете. Даже разработчики с опытом переписывают свои куски кода, это называется гордо "рефакторинг", а по факту часто попытка выпилить костыли. Если вы понимаете, что такое хардкод, то не пишите его. Если не понимаете, пишите, когда поймете и появятся проблемы с ним это будет ваш первый рефакторинг.
Архитектура штука сложная, она очень сильно зависит от требований. Часто идеальная архитектура на первых этапах ломается о фразу "а давайте в этом кирпиче добавим немного фиолетового дикообраза". И все, тут начинаются споры о целесообразности доработки.
Я бы сказал, что в силу неопытности вы не смодете объяснить ментору все свои хотелки и он их не учтет, а значит архитектура будет правиться.
Зато уже готовая архитектура и полное понимание где конец проекта и как будет выглядеть результат.
Это к
Она падает когда результата не видно. Когда не понятно что и зачем делается.
Вы предлагаете написать движок, а вы готовы, что кодить будете примерно несколько мес и только потом возможно увидите какой-то результат?
0
Hardy
23 августа 2021, 11:44
Движок - это громко сказано.
Как правильно подметил Vlad Nestrugin идея идти от простого к сложному. Разбивая задачу на более мелкие подзадачи.
Пока делаю несколько иначе. Так ка еще не понимаю как будет реализован некоторый код.
Разбиваю его на элементарные задачки.
То есть, сначала разубираюсь как работают куски код, а потом уже займусь компоновкой в рабочие куски .
как это выглядит на практике, как делаю это сейчас.
задача 1 научиться рисовать сетку на андроиде. 3 на 3. Жесткий хард код.
задача 2 научится рисовать сетку X на У так чтобы поля были квадратными. и размерность задавалась 2мя цифрами.
задача 3 к задаче 2 добавить кнопки управления и заставить их работать. ( допустим заставить двигаться ячейку с другим цветом по ранее созданному полю).
задача 4 научится вставлять картинку в ячейку. не зависимо от размера ячейки. Так как размер ячейки будет меняться в зависимости от количества ячеек по горизонтали и по вертикали.
сейчас решаю, как реализовать задачу - сохранение параметров для каждой ячейки.
Скорей всего будет двумерный массив объектов <ячейка> с параметрами: Х, У, картинка....
потом буду прикручивать обработку события toch ( это чуть позже!)
И останется последний вопрос как отрисовать матрицу ландшафта , матрицу игрового объекта на игровом поле (как для игр Moon Lander, Raser).
А дальше начну компоновать.
Мысль такая, создать сначало
0
Сергеев ВикторMaster
23 августа 2021, 16:54
Я писал к тому, что часто от таких начинаний ожидают очень много сами разработчики )
Важно научиться радоваться решению небольших задач а не ждать глобального решения
0
Hardy
24 августа 2021, 06:34
Это точно заметил . Нужно уметь радоваться и получать удовольствие от микрозадач, процесса.
Глобальная цель слишком призрачна, размытая и далекая!
0
Александр
18 августа 2021, 12:40
А вообще, я тут вспомнил с чего все началось и чего я вообще собственно зашел на JavaRush в марте прошлого года. Я решил погрузиться в системы безопасности и в частности учился этичному хакингу(точно!!!!). В определенный момент меня заинтересовал один эксплоит и понятия не имею почему, но он был на java. Мне надо было посмотреть синтаксис языка и я зарегистрировался на этом сайте:) Как говорится, часов 400 спустя...
0
Александр
18 августа 2021, 12:30
Я зациклился на крестиках-ноликах и постоянно делаю их😉 Пока консольные, потом хочу сделать с нормальной визуализацией. Сделайте приложение морского боя. Наверное будет интересно.
0
Hardy
18 августа 2021, 12:52
визуализация - пользовательский интерфейс над этим как раз сейчас и работаю.
Чтобы можно было отображать и управлять игрой с экрана Андроид.
Есть еще некоторые моменты пока не знаю как реализовать.
Что касается UI компе то Java FX мне не далась. Попробуй может тебе удастся. На Eclipse не смог подключить. Удалось только на JB
0
Justinian Judge в Mega City One Master
18 августа 2021, 12:30
не все, по крайней мере не по джаве.
Я уже приводил ранее аналогию, когда у ученика была ломка, что он учит учит джаву, а не может ничего осязаемого сделать, что джава программиста можно сравнить с ракетоконструктором или нейрохирургом. Нельзя студента первокурсника с меда выдернуть и сказать "ну тыж нейрохирург, ну да, ты еще учишься, потом ты будешь делать операции на всем мозге, а ну-ка, сделай операцию пока на маленьком участке мозга, сделаем скидку на то, что ты только поступил в мед" или "ну ты учишься на ракетоконструктора, ну ок, ты еще только второй курс, ты не можешь сконструировать ракету на Марс, ну давай трехступенчатую ракету, которая хотя бы пару тысяч км пролетела с набором высоты в 60 км. Ну такая градация "личных проектов" должна быть?
Тоже самое касается и джавистов особенно энтерпрайз, ну нельзя без опыта работы даже подобие реального большого проекта создать, это просто невозможно.
Поскольку деревянная кривая лошадка никогда не будет и отдаленно напоминать современный автомобиль.
Именно поэтому, в джава веб энтерпрайз направлении обучаются дискретно, этот маленький кусочек пазла изучили, этот кусочек, этот кусочек, а картинка сложится только на работе. И поэтому у начинающих специалистов почти не спрашивают о пет-проектах, я когда искал первую работу, у меня предложений было достаточно и при этом проектов у меня не было, и у меня их никто не спрашивал, поскольку понимали расклады, озвученные выше. Почему не спрашивают...либо проектов нет, либо если есть,то лучше их даже не открывать практикующему программисту.
Для себя устроить песочницу если сильно хочется, можно, но необходимости нет.
Это в энтерпрайзе
В андроид наоборот, поскольку даже без опыта работы, можно написать маленькое, но осмысленное и похожее на настоящее. Вот для мобайл разработчиков это конечно имеет смысл и совсем другой разговор, так что этот пост действительно актуальный
+1
Justinian Judge в Mega City One Master
18 августа 2021, 12:36
справедливости ради, озвучу, иногда на проекты и для веб энтерпрайз девелоперов могут обращать внимания, отчасти это может показать, что человек владеет рядом технологий (хотя более дискретные проекты имхо более выгодно представят соискателя), но нужно понимать, что бывает разное, например я знаю реальные кейсы , когда существенный фактор при принятии решения рассмотреть/отказать кандидату были - веган или мясоед, бухает по страшному или трезвенник, знак гороскопа и даже ауру анализировали, какого она цвета..
Бывает реально всякое.
Суть моего коммента - это понимание того, что для НЕ мобайл разработчиков, личные проекты осмысленные не являются необходимыми.
Более выиграшная тактика это налегать на базу, джава кор, технологии, безусловно прорабатывать практически технологии, но вполне допустима ограниченная реализация, например реализовать только data layer, или сделать с ацентом на security, то есть 1-2 темы на проработку как акцент, остальное упрощается, за счет этого идет более глубокая проработка конкретной темы, если пытаться соединить 100 технологий в одном проекте, высока вероятность что получится равномерно плохо по всем направлениям.
Это может дать правда некую уверенность соискателю, в этой части может и да, в любом случае, каждый сам решает оптимальную по его мнению и в его ситуации стратегию, у каждого свои обстоятельства
0
Hardy
18 августа 2021, 12:41
Вопрос по интерпрайсу. Насколько необходимо начинать изучать фреймворк ?
0
Justinian Judge в Mega City One Master
18 августа 2021, 13:47
джентельменский набор технологий и фреймворков необходим конечно,
git/maven(или gradle)/sql/базы данных/MySQL(или PostgreSQL)/JDBC/Servlet/Apache Tomcat/HTML/Junit/Mockito/Hibernate/Spring MVC/Spring Boot/Spring Data/Spring Security/REST API + теория транзакции, реляционные бд, ACID, FIRST, SOLID, дизайн паттерны
это краткий список самого необходимого для стажера/джуна.
Выглядит внушительно, но начинать нужно хотя бы с базового понимания этих вещей, большинство из этого в частности осваивается на той же стажировке от джава раш.
Но опять же, все зависит от конкретной индивидуальной ситуации, если цель получить работу программистом - изучается джава кор(джава раш), изучаются технологии и фреймворки (стажировка джава раш), подготовка к собесам и латание дыр пробелов в знаниях, подготовка резюме и активный поиск любых возможностей с продолжением углубления в джава стек.
Если изучать джаву для других целей, для себя или чтобы что-то себе написать, то можно отталкиваться от того, что хочется (при изучении для себя) или от конкретных идей и конкретной задачи (если пишется какой-то проект свой).
+1