Комментарии 8
Делитесь своими историями и методами которые помогли именно вам сдвинутся с мертвой точки.Не разговаривай о проекте, пока не доделал до определённого состояния завершённости.
Делитесь своими историями и методами которые помогли именно вам сдвинутся с мертвой точки.
Для меня работали следующие практики:
- не бросаться сразу писать код
Лучше неделю/месяц потерпеть и потратить это время на анализ конкурентов, составить примерный план работ, завести задачи, если прийдётся с чем-то новым работать, то сделать несколько прототипов и т.п. А вот потом если всё ещё есть смысл продолжать, то браться за написание MVP/прототипа.
- тратить на MVP проект не больше 2-х (максимум 3-х) месяцев (это грязное время т.е. работая после работы, в выходные, сидя в машине и т.п.)
Суть в том что на такой период мотивации обычно хватает, а вот на больший период уже нет. Плюс виден результать работы (+ проблемы, возможности и т.п.) и можно оценить стоит продолжать или нет.
- не останавливаться даже на день т.е. что-то да надо для проекта каждый день сделать (здоров — пишешь код, заводишь issue, рисуешь иконки и т.п., заболел и не можешь писать код — заведи issue или добавь хотя бы строчку к существующей)
Начнешь пропускать дни — всё встанет и никогда не будет сделано.
- использовать инструменты которые ориентированы на быстрое создание прототипов и с которыми есть опыть работы
Я для веб приложений использовал Rails т.к. ИМХО он идеально подходит для создания прототипов/MVP если есть опыт работы с ним. Он посути как конструктор т.е. из готовых блоков можно буквально за пару дней собрать основные экраны, админку, API, за пол часа «прикрутить» аутентификацию, настроить деплой и т.п. При наличии опыта всё делается очень быстро.
Для десктоп приложений всё намного печальнее т.к. обычно хочется сразу сделать крос-платформенное приложение. Пересмотрел/перепробывал много UI фреймворков на разных языках, но у всех у них есть проблемы т.е. вместо того чтобы работать над проектом начинаешь бороться с ограничениями и проблемами этих фреймворков. Всё это сильно демотивирует. Поэтому тут ничего советовать не буду.
Как-то так.
Очень исчерпывающе!
А что конкретно рассматривали из кросс-платформы для десктоп приложений?
А что конкретно рассматривали из кросс-платформы для десктоп приложений?
Это долгая история. Побробно рассказывать про выбор фреймворка не хочу т.к. это холиварная тема.
Дело было чуть больше 5 лет назад. Выбирал из Qt, Electron, SWT, Swing и JavaFX. Выбрал JavaFX. Практика показала что сделать приложение на JavaFX можно и оно будет неплохо выглядеть и работать, но проблем с ним как и с другими фреймворками хватает. Например, чтобы было понятно, после Jigsaw в JDK «выпилили» jpackage и на несколько лет сборка инсталяторов под разные ОС стала очень не тривиальной задачей. Или например где-то в это же время сломали ListView т.е. если он раньше мог без проблем работать с 1М элементов и более, то теперь он загибается на нескольких тысячах. Это особенно критично если учесть что виртуального режима у ListView нет (как например было в WinForms или Swing) и это кстати тоже серёзная проблема (вроде как glazedlists может ее решить, но я уже не помню чем закончились эксперементы с ним). Всё это можно поправить/обойти при желании, но вместо работы над продуктом прийдётся решать эти проблемы и тратить кучу времени посути впустую и как я писал выше всё это сильно демотивирует.
Я сейчас время от времени смотрю на крос-платформенные UI фреймворки которые уже имеют какую-то историю или недавно появились, но что-то не один не внушает доверия.
Дело было чуть больше 5 лет назад. Выбирал из Qt, Electron, SWT, Swing и JavaFX. Выбрал JavaFX. Практика показала что сделать приложение на JavaFX можно и оно будет неплохо выглядеть и работать, но проблем с ним как и с другими фреймворками хватает. Например, чтобы было понятно, после Jigsaw в JDK «выпилили» jpackage и на несколько лет сборка инсталяторов под разные ОС стала очень не тривиальной задачей. Или например где-то в это же время сломали ListView т.е. если он раньше мог без проблем работать с 1М элементов и более, то теперь он загибается на нескольких тысячах. Это особенно критично если учесть что виртуального режима у ListView нет (как например было в WinForms или Swing) и это кстати тоже серёзная проблема (вроде как glazedlists может ее решить, но я уже не помню чем закончились эксперементы с ним). Всё это можно поправить/обойти при желании, но вместо работы над продуктом прийдётся решать эти проблемы и тратить кучу времени посути впустую и как я писал выше всё это сильно демотивирует.
Я сейчас время от времени смотрю на крос-платформенные UI фреймворки которые уже имеют какую-то историю или недавно появились, но что-то не один не внушает доверия.
А собственно зачем заставлять себя, если не лежит душа? Не хочешь заниматься pet проектами — не занимайся. А хочешь — так занимайся.
P.S. Сам я все свое свободное время провожу за личным проектами, но не по тому, что это «надо» а просто мне нравится так проводить время… Зачем же еще это может быть?
P.S. Сам я все свое свободное время провожу за личным проектами, но не по тому, что это «надо» а просто мне нравится так проводить время… Зачем же еще это может быть?
Мне помогает следующий метод: Пользуйся своим проектом. В процессе использования понимаешь, что не так и что надо добавить, чтобы самому было комфортнее пользоваться.
У меня тут свой термин образовался: pet code in production project. Это когда вместо проверенного и знакомого кода суёшь в проект что-то новое и молодежное, потому что "ну а где и когда я это ещё попробую?".
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я научился получать удовольствие от pet-проектов