• Как составить план проектирования проекта?

    MarcusAurelius
    @MarcusAurelius
    автор Impress Application Server для Node.js
    Идея/концепция к проектированию не относится, это отдельный предварительный этап. Для проектов побольше, и в общем случае, проектирование включает такие шаги, многие из которых, конечно, можно пропустить или сократить до минимума, если задача не сложная:
    1. Системный анализ и изучение предметной области
    2. Формирование требований к разрабатываемой системе
    3. Архитектуная задача, которая сводится к простой формуле: разделять, называть и связывать подсистемы
    3.1. Декомпозиция сложных задач
    3.2. Слои (построение слоев абстракций)
    3.3. Планирование топологии системы, программной и серверной инфраструктур
    3.4. Решение вопроса интеграции подсистем, программные интерфейсы, контракты и связывание
    3.5. Интеграция с унаследованными приложениями
    3.6. Минимизация изменений, для случаев, когда постоянно происходят изменения в предметной области
    4. Выбор инструментов решения
    4.1. Выбор парадигм программирования и языков
    4.2. Выбор технологий и платформ
    4.3. Выбор моделей данных, алгоритмов и библиотек
    4.4. Выбор топологий и протоколов
    4.5. Выбор паттернов программирования
    5. Предварительные исследования
    5.1. Проверка гипотез, эксперименты
    5.2. Изучение особенностей технологий
    5.3. Прототипирование
    6. Задачи обеспечения надежности
    6.1. Планирование безопасности и защиты от несанкционированного доступа
    6.2. Планирование отказоустойчивости
    6.3. Планирование мер по обслуживанию системы в режиме эксплуатации
    6.4. Задачи высоких нагрузок, балансировки и масштабирования, если таковые предполагаются
    7. Организация процесса разработки
    7.1. Жизненный цикл программной системы
    7.2. Конвенции кода, соглашения и стандарты
    7.3. Оценка необходимых временных и финансовых ресурсов для разработки системы
    7.4. Календарный план
    7.5. Анализ и минимизация рисков, выявление слабых мест технологий и коллектива
    7.6. Закрепление принципов управления процессом разработки и корректировки задания в процессе
    8. Сборка технического задания из результатов всех предыдущих пунктов
    Ответ написан
    2 комментария
  • Как оптимизировать видео, вставляемое в качестве фона?

    Taraflex
    @Taraflex
    Ищу работу. Контакты в профиле.
    Уменьшите битрейт и разрешение видео.
    Переместите метаданные в начало mp4 контейнера
    Установите preload="metadata"
    htmlbook.ru/html/video/preload

    Чтобы пиксели в глаза не бросались наложите на видео сеточку из маленьких черных точек
    https://jsfiddle.net/soumyabg/wefLyrhp/
    css background dotted overlay
    Ответ написан
    5 комментариев
  • Паттерны проектирования?

    @vkdv
    Паттерны - это реальные инструменты, позволяющие добиться реализации концепции объектно-ориентированного проектирования и принципов SOLID

    Ссылка на SOLID

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

    Один из наиболее часто встречающихся мне примеров, это пример принципа "Принцип открытости/закрытости" , когда класс - описывающий некую сущность(например модель комментария) , описывает только свои базовые назначения( создание, удаление, редактирование), при этом такие механизмы, как модерация, прикрепление файлов, лайки , реализуется другими классами и "прикручиваются" к классу моделей через интерфейсы и наследование/ трейты / примеси

    При этом :
    1) Никак не изменяется код класса "Комментарий" (кроме подключения интерфейса) и в будущем мы добавляем поведения без изменения класса + стабильность системы, гибкость
    2) Каждый класс имеет свое четкое назначение + легкость модификации, порядок
    3) Комментарии наследуют некоторое поведение, путем подключения поведения, но также могут поступать любые другие классы - сущности (посты, блоги итп) , то есть интерфейс и реализация лайков универсальна, и весь функционал работы лайков находится только (строго!!!) в одном месте + легкость модификации, Универсальность, стабильность, интуитивная понятность

    Из википедии :

    Признаки плохого проекта
    Закрепощённость: система с трудом поддается изменениям, поскольку любое минимальное изменение вызывает эффект "снежного кома", затрагивающего другие компоненты системы.
    Неустойчивость: в результате осуществляемых изменений система разрушается в тех местах, которые не имеют прямого отношения к непосредственно изменяемому компоненту.
    Неподвижность: достаточно трудно разделить систему на компоненты, которые могли бы повторно использоваться в других системах.
    Вязкость: сделать что-то правильно намного сложнее, чем выполнить какие-либо некорректные действия.
    Неоправданная сложность: проект включает инфраструктуру, применение которой не влечёт непосредственной выгоды.
    Неопределенность: проект трудно читать и понимать. Недостаточно четко выражено содержимое проекта.

    Оттуда же про SOLID

    Избавиться от "признаков плохого проекта"[4] помогают следующие пять принципов SOLID:

    Принцип единственной ответственности (The Single Responsibility Principle)
    Существует лишь одна причина, приводящая к появлению класса.

    Принцип открытости/закрытости (The Open Closed Principle)
    «программные сущности … должны быть открыты для расширения, но закрыты для модификации.»

    Принцип подстановки Барбары Лисков (The Liskov Substitution Principle)
    «объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.»

    Принцип разделения интерфейса (The Interface Segregation Principle)
    «много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения.»

    Принцип инверсии зависимостей (The Dependency Inversion Principle)
    «Зависимость на Абстракциях. Нет зависимости на что-то конкретное.»
    Ответ написан
    2 комментария
  • Стоит ли переходить на React.PureComponent по-умолчанию?

    PQR
    @PQR
    React.PureComponent реализует метод shouldComponentUpdate таким образом, что он делает поверхностное сравнение props и state (не глубокое). Вот собственно код:
    https://github.com/facebook/react/blob/c8fbdac2271...
    shouldUpdate =
                !shallowEqual(prevProps, nextProps) ||
                !shallowEqual(inst.state, nextState);


    Что такое shallowEqual? Это по сути сравнение оператором === каждого элемента из prevProps с каждым элементом из nextProps. На всякий случай дам ссылку на реализацию для полного понимания: https://github.com/facebook/react/blob/6963ea4bfcd...

    В итоге всё зависит от структуры ваших props. Если в props вы передаёте объекты которые иногда мутируются, т.е. по ссылке они равны ===, но внутри какие-то данные поменялись (что само по себе выглядит странно в экосистеме redux + reselect, но вполне возможно технически), тогда использование PureComponent вам всё поломает, т.к. на экране какие-то компоненты перестанут перересовываться!

    Если же у вас всё по уму, данные которые передаются через props являются скалярными типами (string, int, float, bool) или immutable объектами, тогда смело используйте PureComponent - в некоторых случаях он поможет избавиться от лишних вызовов render.

    Важное замечание: PureComponent нужно использовать только для так называемых presentational components, т.е. для тех компонент, которые НЕ обёрнуты в вызов redux connect().

    Для container components (т.е. тех компонент, которые обёрнуты в redux connect()) нет смысла наследоваться от PureComponent, т.к. метод connect() оборачивает ваш компонент своей реализацией shouldComponentUpdate, которая также использует shallowEqual. Если вы по недосмотру унаследуете container component от PureComponent - ошибок не будет, но это не имеет никакого смыла, т.к. ваш код по сути будет дважды делать shallowEqual, а зачем делать лишнюю работу?

    Подводя итог, рецепт такой:
    - presentational components наследуем от React.PureComponent
    - container components (которые обёрнуты в redux connect()) наследуем от старого доброго React.Component
    Ответ написан
    1 комментарий
  • Есть ли книга по построению и проектированию бизнес приложений, банковских и т.д.?

    gMefesto
    @gMefesto
    учусь верстать сайты
    М. Фаулер – Архитектура корпоративных программных приложений
    Ответ написан
    Комментировать
  • Как развить навык проектирования приложения или как стать Senior?

    @OldCrazyCoder
    Писать код. Читать код. Например, популярные опенсорсные проекты на гитхабе. Если очень уж книгу хочется, то вот минимальный джентельменский набор:
    1. Совершенный код. С. Макконнелл
    2. Чистый код: создание, анализ и рефакторинг. Роберт Мартин
    3. Приёмы объектно-ориентированного проектирования. Паттерны проектирования. Банда четырех))
    4. PHP. Объекты, шаблоны и методики программирования. Мэт Зандстра
    5. Рефакторинг: улучшение существующего кода. Мартин Фаулер
    И т.д. Книг крайне много. И статей много. И простое их чтение мало что даст. Практика, много практики. Критичное отношение к своему коду, однако без перегибов - не стоит упираться в перфекционизм.
    Ответ написан
    Комментировать
  • Как развить навык проектирования приложения или как стать Senior?

    devspec
    @devspec
    Помогло? Отметь решением
    Вам помогут только время и большое количество реализованных проектов. Всё приходит с опытом.
    Я, например, каждые полгода делаю ревью собственного кода за предыдущие полгода и ужасаюсь - как я мог так писать? А ведь полгода назад я мнил себя профессионалом... и так каждые полгода ))
    Ответ написан
    2 комментария
  • Какой необходимый уровень знаний для junior React.js Разработчика?

    maxfarseer
    @maxfarseer
    https://maxpfrontend.ru, обучаю реакту и компании
    UPDATE: реальные тестовые задания и разборы здесь, ответы на все вопросы из поста в моем блоге об обучении react.

    не включая основы js

    Извините, но стандартная задача, про "напишите функуцию add, которая при вызове add(1)(2) вернет 3" - многих положила на лопатки =) Поэтому будьте готовы..

    React
    0) Какую проблему решает react ?
    1) Мгновенно ли срабатывает setState? Если нет, то как выполнить код, который 100% выполнится после того, как новый state будет установлен?
    2) Зачем многие постоянно пишут в constructor: this.FUNCTION_NAME = this.FUNCTION_NAME.bind(this) и отсюда вопрос вытекает чему равно this в разных местах вашего компонента...
    3) в каких методах жизненого цикла стоит выполнять xhr запросы? В каких стоит "обновлять state на основе props"?
    4) Что будет если вызвать this.setState в render методе компонента?
    5) зачем нужен componenWIllUnmount, приведите пример..
    6) Контролируемые, не контролируемые компоненты
    7) Как организовать роутинг в реакт приложении? (ответ: взять react-router - подходит, но было бы круто, если бы вы рассказали, как он примерно работает)*
    8) Зачем нужны propTypes? Что происходит с ними в production сборке?
    9) Как можно удобно "отлаживать" чужой код приложения, написанного на react (намек в сторону React devtools)
    ...

    Redux
    0) Какую проблему решает redux?
    1) Зачем многие создают типы действий NAME_REQUEST / NAME_SUCCESS ? А заодно, что такое "действие", а что такое "создатель действия"...
    2) Что такое редьюсер? Можете написать простой редьюсер без react/redux?*
    3) Для чего нужен redux-thunk? Как он работает? Напишите (можно псевдокод) асинхронный создатель действия (либо, если надоело говорить "терминами" - асинхронный aciton)
    4) Как компоненты приложения получают "пропсы" из "стора"?*
    5) Можно ли (и считается ли это нормальным) использовать state, если используется Redux?
    6) Почему в reducer'ax мы возвращаем новые объекты? Приведите пример, когда вы возвращаете новый объект, а когда тот же самый.
    6.5) А так же, "как в js вообще это работает?". Например:
    let obj1 { name: 'Test', age: 100 }
    let obj2 = obj1
    obj2.name = 'Test_new'

    Что будет в obj1, почему? В каких случаях объекты могут быть равны?
    7) Что возвращает функция connect (из react-redux)?
    ...

    Общее:
    0) package.json
    1) Webpack, gulp, etc...
    2) node.js
    3) promise

    Что-нибудь практическое:
    1) Как бы вы валидировали форму, если ошибки валидации приходят после submit'a ее на сервер..
    2) Почему не работает следующий код, сделайте чтобы работало
    ...
    На истину не претендую, но такие вопросы имели место быть на собеседованиях. В беседе можно многое разузнать дополнительными вопросами и так далее. Так же, если часть вопросов вам неизвестна - не беда, многие и на половину ответить не могут.

    p.s. возможно дополню...
    p.p.s. звездочкой отметил, на мой взгляд не самые необходимые для junior-собеседования вопросы.
    Ответ написан
    31 комментарий
  • Какие есть интересные сайты со статьями на тему Frontend?

    sfi0zy
    @sfi0zy
    Creative frontend developer
    русскоязычные ресурсы по теме веба? Желательно те, которые обновляются достаточно часто

    Проблема русскоязычных ресурсов в том, что 80-90% контента на них - это переводы. А переводы - это дело такое - их всегда меньше, чем оригинальных статей, и появляются они в большинстве своем с заметным опозданием. Так что не брезгуйте ходить на зарубежные сайты - например на smashingmagazine, css-tricks или uxplanet.
    Ответ написан
    Комментировать
  • Как правильно описать архитектуру проекта?

    @developer007
    Вот пару примеров из курса проектирования АСОИУ https://yadi.sk/i/KTRP6OeI38NmZZ

    погуглите ПРОЕКТИРОВАНИЕ АСОИУ - я не помню как нотации называются ....IDEF0 и прочие

    b5550277e5a143fab7d655283d10b9a1.png2b152ee490a94d2bb3d1b9805b592bde.png

    погуглите еще - " Диаграмма классов, Диаграмма развертывания

    для построения диаграмм я использовал enterprise architect
    или draw.io

    стили отличаются.
    Ответ написан
    1 комментарий
  • Как организовать самообучение языкам программирования?

    aRegius
    @aRegius
    Python Enthusiast
    1. Определяете минимум, который вам необходим для создания продукта-цели. Ну, то есть, самый минимум, minimum minimorum. Например: "Для создания моего продукта мне нужны HTML, CSS, JS и PHP. Без любого из них я свой продукт создать не смогу. Это мой необходимый минимум."

    2. Ищите по 1-му толковому материалу (чтобы не распылять усилия на 8 книг и 15 онлайн-курсов по JS, условно) для каждого инструмента. Более того, по трем из них я вам могу дать рекомендации: HTML5 + CSS3 + JS. PHP не мой "конек", возможно коллеги подскажут...

    3. Учите в том же порядке: HTML, потом CSS, потом JS/PHP (PHP/JS, тут уж сами смотрите).

    4. Открывайте соответствующий материал по предмету, ознакомьтесь со структурой подачи материала и определите для себя ключевые точки для разбития этого материала на блоки, каждый из которых вы будете стараться пройти "за один присест".
    Например: открываете книгу по HTML, смотрите содержание, и принимаете решение (исходя из имеющегося у вас времени, которое вы готовы в день уделять обучению), что будете в день работать над 2-мя главами материала.
    Или: открываете материал по JS, смотрите содержание, и принимаете решение, что будете в день работать над 1-ой темой (сегодня - "Основы JavaScript", завтра - "Качество кода" и т.п.)

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

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

    7. После реализации проекта можете выдохнуть, осмотреться, наметить очередные цели с учетом приобретенного опыта - и дальше в путь!

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

    P.S. Вам будет проще, если вы сконцентрируетесь, поставите себе минимально возможные сроки и "возьмете эту крепость блицкригом", ибо на скользкую горку проще всего забраться с разбегу :)
    Ответ написан
    4 комментария
  • Как правильно создать структуру приложения на ReactJS + Laravel 5.3?

    На бэкенде: делаете rest-api с помощью Laravel.
    На фронтенде: берете реакт + редакс и разрабатываете приложение, которое будет общаться бэком через АПИ.
    Ответ написан
    Комментировать
  • Существует ли "карта программиста"? Что и за чем учить?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Нет одинаково эффективного пути для всех и каждого.

    Я учился на конкретных задачах. Обучение практически всегда начиналось с состояния хочу сделать вот это (четко осознаваемый конечный результат), но вообще понятия не имею как это делать, и даже с какой стороны подойти и за что хвататься...

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

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

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

    Далее из модулей, как из кубиков лего пытаешься собрать функциональные блоки. Тут важно понимать, что чем более автономные модули и блоки у тебя получаются, тем лучше, особенно для целей тестирования. Если ты забиваешь болт на тестирование, то тебе нечего делать в разработке.

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

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

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

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

    Обрати внимание, самое главное качество во всем этом многабукафф - упорство на грани фантастики. Любой, кто не дойдет до конца, не треснет себя по лбу в соты раз с воплем, так вот же она где, эта запятая, пропущена - сломается в самый неподходящий момент на боевом проекте...

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

    Ах да, обложись справочниками по любому инструменту и научись быстро вникать и подхватывать необходимый минимум. Обычно достаточно на 20% владеть инструментом, чтобы решать 80% задач.

    В любом случае я за критерий истины держу платежеспособный спрос.
    Ответ написан
    3 комментария
  • Выучил базовые основы Python 3. Куда копать дальше?

    werevolff
    @werevolff
    Если для Web, то Django + Scrapy. На scrapy можно сразу начинать делать парсеры. Парсеры нужны очень часто, и можно сразу брать проект и делать. Для десктопа и кроссплатформенности - не знаю. Возможно, что Kivy.

    Да, чуть не забыл: Peewee. Можно и SQLAlchemy, но pewee выглядит очень изящно.
    Ответ написан
    5 комментариев
  • Какую версию Angular использовать?

    @artinnok
    бекенд-программист
    Angular 2.0 очень активно продвигается - но он очень молодой. Angular 1.X - данные версии используются на большинстве проектов, которые сейчас есть в вебе. Имеет смысл учить 1.X в том случае, если вы в дальнейшем собираетесь работать на других проектах, принимать участие в поддержке или масштабировании. Если выбираете 2.0 - то он имеет смысл в новых проектах, которые пишутся с нуля.

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

    Angular 2.0, думаю, будет хорошо учить через год-два, когда он получит большее распространение.
    Ответ написан
    Комментировать
  • Как уйти с распутья технологий?

    @0x131315
    Стратегию уже подсказали: найти любую работу, чтобы кушать, и тем самым выиграть время на изучение чего-то, что поможет зарабатывать больше, и тем самым выиграть еще больше времени, и в конце концов изучить то, благодаря чему будешь работать не на зарплату, а на удовлетворение.

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

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

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

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

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

    Также упрощает задачу стандартизация подходов к решению задач, парадигм - большинство из них уже формализованы, и описаны. Например всем известное ООП, модульное программирование, конечные автоматы, и т.п. Описано более двух десятков таких моделей, их следует по возможности освоить. И не стесняться комбинировать.

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

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

    Но все-равно, даже программисту нужен опыт. Не важно что он отвязан от языков - он все-таки привязан к одному языку, информации, и должен уметь с ней обращаться.
    Опыт экономит время и усилия - там, где сперва требовалось неделю гуглить и пробовать, потом, с опытом, все делаешь за час, просто уже понимая что, как, когда и зачем.

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

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

    Недоведение решений до конца - следствие неверного подхода: либо берешь задачи, к которым еще не готов, слишком сложные, либо не имеешь возможности работать - у тебя нет условий для решения задачи: времени, места и внимания. Либо просто тебе это реально не нужно - тебя и так все устраивает, и планов на будущее нет.

    С третьим - придешь, когда поймешь, что тебе это нужно. Из-под палки не учатся.

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

    С первым все просто: не можешь что-то решить - отложи, и спустись на ступеньку ниже по шкале сложности.
    Есть такой психологический феномен: от решенных задач ты получаешь удовлетворение, силы и мотивацию двигаться вперед, от нерешенных - негатив, апатию, потерю воли и мотивации.
    Причем мозг устроен так, что запоминается лишь негатив. Поэтому крайне важно решать задачи, и не допускать незавершенных задач. Отложи, но не забрасывай.
    Нерешенная задача - это как психологический запой, нечто вроде депрессии: одна нерешенная задача тянет за собой другую нерешенную задачу, и так быстро уходишь на дно, теряя мотивацию и веру в себя. Замкнутый круг. Ты находишься именно в нем.

    Разрывать такие круги можно лишь одним способом - рутиной: медленным, последовательным и целенаправленным натиском, движением в одну сторону. Грубо говоря перестаешь жить эмоциями и импульсами, вырабатываешь продуманную программу развития, и действуешь по ней, строго, как робот, до тех пор, пока не начнешь получать положительный отклик от работы, пока не придет желание двигаться дальше - это вернулись воля, мотивация и вера в себя.

    Чтобы вернуть веру в себя, нужно стать победителем. Победители всегда побеждают - в этом и суть. Необходимо начать побеждать, любой ценой: нужно брать такие задачи, которые точно сможешь решить, какими бы простыми они не были. Можешь вернуться к азам, началу, детскому уровню сложности, если потребуется - главное чтобы задачи начали решаться, не важно какие и как. Пока не уверен, что готов двигаться дальше - удерживаешь уровень, каким бы низким и зазорным он не был. Важно обмануть мозг, а не показать класс всему миру, иначе обратно утонешь.

    Сложность задачи не особо влияет на мотивацию, а вот факт решения/нерешения - влияет сильно. Не решил - значит не осилил, не осилил - значит не достоин, не достоин - значит иди ко дну и не рыпайся. Это как импотенция: импотент - значит не мужик, не мужик - значит никто, ничего не достоин и об тебя можно ноги вытирать. Подсознание портит всю малину, так что не следует давать ему шанса - лучше решить задачу попроще, чем не решить по сложнее.
    Ответ написан
    7 комментариев