Это текст для тех, кто решил написать программу для людей — сервис, приложение или что-то подобное. То есть не просто «Хеллоу ворлд», а что-то полезное, функциональное и потенциально пользующееся спросом. Может быть, вы на этом даже планируете зарабатывать. Вот на что обратить внимание на старте: подводные камни, ошибки и нюансы.
Нужно ли это писать?
Вот простой способ понять, нужно ли писать эту программу. Задайте себе вопрос: «Делают ли сейчас вручную то, что я хочу зашить в программу?»
В этом вопросе сразу два компонента:
- Люди уже делают то, что будет улучшать ваша программа. То есть существует некоторый спрос на эту работу.
- Люди делают это руками, а значит, они хотели бы это автоматизировать.
Распространенная ошибка — делать программу для того, что люди сейчас не делают в принципе.
🤔 Например, вы придумали программу для ведения бюджета: туда нужно вводить данные о ваших покупках по категориям, а она бы складывала траты за месяц. Делают ли это люди? Вроде делают, но до поры. Обычно человек начинает вести бюджет, два месяца что-то пишет, а потом забрасывает, потому что денег от этого больше не становится. А еще есть приложения банков, которые сами считают статистику трат. Маловероятно, что очередной менеджер личного бюджета как-то изменит ситуацию.
✅ А вот что люди часто делают руками, так это регулярно оплачивают разные счета: за связь, интернет и коммуналку. И многие не любят настраивать автоплатежи, чтобы никто не смог с них списать ничего лишнего. Еще они регулярно подают сведения по коммуналке. И наверняка есть еще какие-то дела, которые они делают раз в месяц, раз в квартал или раз в год. Можно было бы поставить себе напоминание в календарь, но его легко проглядеть и забыть. Вот бы была напоминалка, которая ходит за тобой, пока ты не сделаешь дело, — был бы кайф.
Полезное ядро
Как часто делают: в голове рождается задумка программы, автор садится её писать и начинает буквально с начала — с экрана логина, первого интерфейса, первого экрана, в общем, чего-то первого. Необязательно на этом экране будет происходить основная работа программы. Просто по задумке этот экран должны увидеть первым.
Как лучше: понять, что будет полезным ядром программы, и сначала убедиться, что вы можете его реализовать. Потом завернуть это ядро в модуль или функцию и уже поверх него написать интерфейс, окна, экраны и всё что угодно.
✅ Например, в приложении для напоминаний полезное ядро — само напоминание, которое вываливается в нужный момент. Потом, может быть, нужно дать напоминанию статус «Я это уже сделал в этом месяце» или «Напомни мне через...» и опцию повторного срабатывания через какое-то время.
🤔 А вот интерфейс установки напоминания и инфраструктура для хранения напоминаний не так важны на первом этапе.
💡 Часто такое же полезное ядро уже реализовал кто-то другой в виде бесплатной библиотеки. Это большая удача: взяли, изучили, допилили — быстро выпустили свой продукт.
На каком языке?
Есть технологии и языки, которые совсем не подходят для вашей задачи: например, Python совсем не нужен для десктопных приложений. В остальном большинство популярных языков мало-мальски могут всё.
На старте обычно рекомендуют не гоняться за идеальным языком, а, наоборот, взять тот язык, которым вы уже владеете, и попробовать реализовать задумку на нём. И, если это точно не подходит, искать другие технологии.
Не подменяйте программирование поиском идеальной технологии.
Составьте схему или план
Когда у вас появится функциональное ядро, прикиньте на листочке, как будет устроен проект целиком:
- из каких модулей он будет состоять, включая всякие вспомогательные системы типа логина или восстановления пароля;
- как они могут влиять друг на друга;
- какие могут возникнуть ошибки;
- какие ещё технологии понадобятся для реализации — например, уведомлять можно с помощью пуша, а можно почтой, а можно в самом приложении.
Задача — собрать в голове всю функциональную картину приложения. Это поможет избежать ситуации, когда половина кода уже написана, но вдруг выясняется, что данные нужно всё время синхронизировать с сервером и придётся переписывать логику.
❌ Часто проекты делают так: рисуют полную схему с подробнейшими выкладками, а потом пытаются написать по ней код за один присест. К середине проекта приходит понимание, что всё как-то сложно. В итоге руки опускаются и проект ставится на паузу, чаще всего навсегда.
✅ Вместо этого можно использовать метод быстрых версий:
- Выбрать самое простое действие, которое можно сделать прямо сейчас. Например, вывести стартовую картинку или отправить на сервер строчку «Привет, это тестовый запрос!». Убедиться, что всё работает.
- Выбрать следующее действие, которое добавляем в проект, например отрисовку главной страницы или сохранение JSON-запроса в файл. Написать код и проверить, как всё работает.
- Если работает — перейти к следующему действию, если нет — исправить и потом всё равно перейти.
Так мелкими перебежками и небольшими итерациями можно сделать практически любой проект. Хитрость в том, что мы не замахиваемся на всё сразу, а делаем маленькими порциями, параллельно изучая новое и проверяя знания на практике.
Всё, за дело
- Убедитесь, что это кому-то нужно (даже если это только вы).
- Возьмите тот язык, которым владеете (а не идеальный).
- Реализуйте центральный модуль (хотя бы базово).
- Нарисуйте схему работы всего остального (не держите в голове).
- Прописывайте мелкие действия и тут же тестируйте (а не пишите сразу всю кодовую базу за один раз).
Этого хватит, чтобы собрать личный проект. А там и до совместного недалеко, но совместный — это немного более сложная история.
