Я прочитал много книг для различных языков программирования, Java, Python, C и т. Д. Я понимаю и знаю все основы языков, и я понимаю алгоритмы и структуры данных. (Эквивалентно скажем, два года занятий по информатике)

НО я до сих пор не могу понять, как написать программу, которая делает что-нибудь полезное.

Все книги по программированию показывают, как писать язык, а НЕ как его использовать! Все примеры программирования являются очень простыми, например, создание карточного каталога для библиотеки или простой игры или использование алгоритмов и т. Д. Они не показывают, как разрабатывать сложные программы, которые действительно делают что-то полезное!

Я смотрел на программы с открытым исходным кодом на SourceForge , но они не имеют особого смысла для меня. В каждой программе сотни файлов и тысячи строк кода. Но как мне научиться это делать? Ни в одной книге, которую я могу купить на Amazon, нет ничего, что дало бы мне инструменты для написания любой из этих программ.

Как вы начинаете читать «Введение в Java» или «Программирование на Python», «Язык программирования C» и т. Д., И на самом деле можете сказать, что у меня есть идея для X-программы? Это то, как я продолжаю развивать это?

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

Как я могу встать на правильный путь?

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

Вы можете найти эту страницу интересной "Научитесь программировать за десять лет" http://norvig.com/21-days.html

Кстати: очень сложно запустить программу. Писатель может назвать это «писательским блоком». Вместо этого я предлагаю вам начать писать код и улучшать его. Не бойтесь удалять большие разделы, которые не делают то, что вам нужно. Начните снова, на этот раз вы напишете с лучшим представлением о том, что вы делаете. Начните снова, и вы обнаружите, что вам не нужна половина материала, который вы написали в прошлый раз. Когда автор пишет историю, это занимает много времени, много написания, переписывания и т. Д. Много рецензий и отзывов, и он заканчивается только тогда, когда он должен быть опубликован (выпущен).

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

Никто не делает. По крайней мере, изначально.

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

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

Пример:

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

Затем вы сталкиваетесь с проблемами параллелизма из-за этого потока. Таким образом, вы исправляете, переходя на параллельные структуры данных.

Теперь процесс замедлился. Таким образом, вы изменяете параллельные структуры данных на обычные, но предоставляете механизмы блокировки для синхронизации.

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

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

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

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

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

... и так далее.

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

Мой совет:

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

Даже самая большая программа начинается с идеи и пишется по одной строке за раз.

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

Тем не менее, есть некоторые вещи, о которых вы должны знать с самого начала:

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

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

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

Теперь: что из этого вы создадите сами, а что получите в другом месте? Большинство крупных программных проектов не программируются с нуля. Возможно, вы будете использовать стандартный 3D-движок и музыкальный / звуковой модуль и программировать только то, что делает вашу игру уникальной. Итак, вам нужно выяснить, какие сторонние модули вы собираетесь использовать, что будет включать такие факторы, как стоимость, с какими языками они работают, какими функциями они обладают, как разработан их API (то есть, насколько он завершен) насколько это соответствует вашему личному стилю программирования и т. д.). Возможно, вы напишете «доказательства концепции» или протестируете программы, используя одного или двух кандидатов на различные сторонние модули, чтобы убедиться, что они будут выполнять все необходимые вам действия и просты в использовании.

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

После того, как вы выяснили, какие модули вы хотите написать самостоятельно, вы выполняете тот же процесс. Выясните части каждого модуля, как они должны сочетаться друг с другом, и что вы напишите сами, и что вы получите в другом месте. Продолжайте разбирать вещи до тех пор, пока каждый кусок не станет достаточно маленьким, чтобы вы могли держать его в уме, чтобы вы сказали: «Да, я мог бы написать это!» А потом сделай так. При этом вы столкнетесь с непредвиденными препятствиями в том, как различные части вашей программы сочетаются друг с другом. Это будет неприятно, но они дают вам возможность узнать больше о вашем ремесле, и их следует рассматривать именно так.

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

И тогда вы обнаружите, что у вас еще есть чему поучиться ... но так оно и есть. Если, как программист, вы когда-нибудь перестанете учиться, вы устареете и будете заменены более новой моделью.

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

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

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

Вы не поймете, как программировать, если не столкнетесь с реальной задачей. Никакая теория никогда не заменит простую реальную задачу. Прежде чем приступить к работе над сценариями rw, я наивно читал множество книг со всеми примерами, но когда столкнулся с реальной проблемой, я просто не мог собрать все свои теоретические знания, чтобы выполнить задачу. Если вы начинающий, я бы порекомендовал вам получать задания где угодно. Не думайте, что они бесполезны, если вы не решили их. В качестве первого шага попробуйте решить проблемы со структурой данных, такие как сортировка связанного списка, выполнение DFS, BFS на деревьях, графиках и т. Д. Это не только улучшит ваши навыки кодирования, но, что более важно, улучшит ваши аналитические и альго-навыки Доверяй мне это ценное знание. Затем, когда вы узнаете, что вы можете качаться с указателями, рекурсия,

Нижняя линия. Это все о практике. Просто продолжайте копать и код, код, код.

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

Общее правило заключается в том, что после написания достаточного количества материала неизбежно произойдет какое-то просветление.

Хорошая точка для начала (если вы чувствуете себя как C) - это http://gamedev.net/ , особенно http://nehe.gamedev.net/ . Есть также много других хороших моментов для начала: D

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

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

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

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

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

Напишите скрипт на 200 строк. Тогда начните улучшать это.

Благодаря Featuritis вы получите 100 исходных файлов и несколько сотен KLOC в кратчайшие сроки :)

«Они не показывают вам, как разрабатывать сложные программы, которые действительно делают что-нибудь полезное!»

Без определения «полезного» мы действительно мало что сможем сделать, чтобы вы оказались на «правильном» пути.

Мы не знаем, как вы терпите неудачу или что не так. Мы не можем сказать, на каком треке вы находитесь.

Почему-то у вас в голове возникает мысль, что вы не общаетесь.

Программное обеспечение - программирование - это все о том, чтобы вывести из головы представление о каком-то языке (Python, Java, English и т. Д.).

Одним из важных шагов в программировании (и задании вопросов) является определение ваших терминов. Что вы подразумеваете под «делать что-нибудь полезное»? Будьте очень ясны, очень полны и очень точны.

Мне постоянно задают этот вопрос, например, как начать. Это действительно просто. Вот шаг за шагом.

1. Придумай идею. Похоже, у вас уже есть это.
2. Упростите свою идею до ее основного ядра - то, что, как вы думаете, вы сможете решить
3. Разместите пользовательский интерфейс на листе бумаги или салфетке, что угодно.
4. Попробуйте макет интерфейса в вашей среде разработки.
5. Если вы столкнулись с трудностями, google, google, google, задавайте вопросы по stackoverflow, воспользуйтесь живым дерьмом из интернет-ресурсов, чтобы получить помощь. Попросите друзей и коллег, программистов, помочь вам в определенных ситуациях. Вернитесь к шагу 4.
6. Начните писать логику вашего приложения. Если вы столкнулись с трудностями, перейдите к предыдущему шагу и попробуйте снова.
7. Достаточно скоро у вас будет что-то работать в ближайшее время.

Создать что-то маленькое. Не возражайте, что ваша программа будет 1000-й, делающей это.

Некоторые идеи:

• часы (сначала цифровые, затем аналоговые),
• автоматический лабиринт создатель,
• отображение структуры каталогов,
• лист альбома mp3,
• и т.п.

Выбирая платформу, инструменты являются частью задачи.

Хорошо, давайте начнем с вашей идеи для программы X, которая делает что-то полезное, и давайте разберем это:

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

• Поскольку вы только начинаете, выберите ОДИН из этих предметов (желательно в начале) и разбейте его еще дальше.

• Сначала напишите свой код для этого и используйте его для

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

Как говорится, гном не был построен за один день :-)

(ответил выше в комментариях уже. Было предложено представить это как ответ после того, как вопрос был вновь открыт.)

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

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

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

Когда вы новичок, вам труднее всего ставить реалистичные цели относительно того, что «как я могу улучшить» - упражнение должно содержать на вашем текущем уровне.

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

Я бы посоветовал вам поближе взглянуть на http://projecteuler.net/, где есть множество упражнений и автоматизированная система «проверьте ответ», что позволяет вам работать в своем собственном темпе. Упражнения хорошо сформулированы, но могут потребовать, чтобы вы думали. Некоторые могут даже потребовать от вас много думать, но даже если вы не решите их, научите вас чему-то полезному.

Полная формулировка задачи 1:

Если мы перечислим все натуральные числа ниже 10, кратные 3 или 5, мы получим 3, 5, 6 и 9. Сумма этих кратных равна 23.

Найти сумму всех кратных 3 или 5 ниже 1000.

Как вы думаете, вы могли бы решить это? Затем сделать его!

Вам нужен опыт реального мира! , Ни одна книга не научит вас этому!

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

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

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

Продолжайте читать свои книги, вы обнаружите, что каждый год вы понимаете немного (или по-разному) одну и ту же тему, потому что вы можете видеть это со стаканом опыта.

Если вам удастся устроиться на работу с талантливыми разработчиками, гораздо лучше. Учитесь у них, не бойтесь делать ошибки.

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

:)

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

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

Это не очень полезно, но ты многому учишься и на это приятно смотреть.

Программирование - это решение проблем и общение, а не написание большого количества кода. Код это просто необходимость, вы должны стараться писать меньше кода, а не больше.

Если вы не знаете с чего начать, возможно, у вас просто нет проблем!

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

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

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

Разделяй и властвуй.

Это так просто или сложно, как это.

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

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

Кроме того, вы можете начать с чего-то, например, с игрового автомата (вам не нужны анимации или даже картинки. Просто используйте A = яблоко, L = лимон, S = старт, P = слива и т. Д.).

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

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

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

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

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

В колледже был класс, называемый практическим занятием по программированию, который в основном преподавал эту рампу. Раньше вы получали пользовательский интерфейс для базового приложения для покупок, и вам приходилось кодировать бэкэнд, в прошлом месяце был Tetris с нуля. Я думаю, что около 50% новых учеников (без повторного обучения в классе) потерпели неудачу, потому что переход от малого к большому невероятно труден.

Я бы предложил одно или несколько из следующего:

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

• Просто создайте свой конечный проект на бумаге со стрелками для зависимостей. Если вы делаете змею, у вас может быть голова змеи, хвост змеи, еда, пустое пространство, стена, доска, текущее направление и т. Д. Может помочь вам понять, что ваш проект намного больше, чем вы думаете.

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

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

Наконец, что бы вы ни делали, вам, вероятно, следует использовать базовый шаблон проектирования MVC (Model, View, Controller). Не вдаваясь в подробности, поместите ваше представление (UI) в классы 1+, контроллер (Input, output и т. Д.) В классы 1+, а модель (Logic, Data, в основном все остальное) в несколько классов. Это простой способ получить базовую организацию.

Помните, этот шаг труден. Это правда, что некоторые люди просто не могут программировать, но вы, вероятно, просто застряли на этом этапе. Удачи!

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

• Записаться на студенческие проекты. Я связался с (CSUA) группой студентов-единомышленников, чтобы создать игру для карнавальной будки моего старшего года. Если вы продолжаете получать от этого удовольствие и думаете, что хотите расширить свое участие, по-настоящему воспользуйтесь ресурсами. Узнайте о проектах, поговорите с одноклассниками, профессорами и получите стажировку.

• Сядьте с опытным программистом. В моей истории было три раза, когда я смотрел другую личную программу, которая была действительно вдохновляющей. Для них они просто писали код и думали вслух. Без преувеличения, я чувствовал, что слушаю их больше, чем годами сам по себе. Если вы встретите больше, вы будете намного богаче. Нам повезло, что мы можем смотреть видео, просматривать полные исходные репозитории и мгновенно искать в огромном онлайн-магазине знаний. Это не замена личного опыта, но в отсутствие наставника это значительное улучшение по сравнению с традиционным материалом. Однако сам по себе просмотр необработанного кода другими людьми может ни к чему не привести. Вам нужно что-то иметь в виду и хороший отладчик, чтобы войти в логику. Одним из моих самых любимых моментов было создание мода для Quake, и не в самом моде было что-то запоминающееся. Он видел внутриигровую логику Кармака. Мод был просто поводом для меня, чтобы погрузиться в.

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

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

Вам не нужно иметь отличную идею, чтобы начать программировать что-то. Я бы начал с легкой части. Мол, программа, которую вы уже используете. Попробуйте сделать то, что вы уже знаете, как это работает. Лицом к лицу с вашими проблемами, так что вы узнаете это быстрее. Когда у вас будет больше опыта, у вас появятся хорошие идеи о программах, которые облегчат вашу жизнь во время программирования, или просто хорошая программа, которая сделает то, о чем вы раньше никогда не думали. Я программирую на Java почти год, а другие языки - пару лет. Потребовалось время, чтобы начать делать то, что я действительно хотел сделать. Я только начал заниматься своими делами. Благодаря StackOverflow. Я не знал об этом раньше.

Так что есть тонна ответов, так что прости меня, если я повторю многое из того, что уже было сказано, но вот мои 2 цента.

Сначала выберите идею. Любая идея будет хорошо, что-то простое, вероятно, будет лучше, чем большое Проекты имеют тенденцию очень быстро расти в своих масштабах (некоторые называют это ползучестью).

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

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

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

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

Теперь выберите другую функцию и повторите и повторите и повторите.

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

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

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

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

Это дает вам относительно простую проблему с довольно известным решением, которому просто нужен уровень автоматизации. Имейте в виду, что это не обязательно следующий MS Word / WordPad / NotePad; просто то, что решает вашу (простую) проблему.

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

Я думаю, что часть проблемы в том, что когда вы читаете книги по программированию, они просто учат вас языку. Они не упоминают, что для того, чтобы программировать практически все, вам нужен доступ к программированию БИБЛИОТЕК, SDKS и т. Д. Просто зная язык, к сожалению, недостаточно.

Я полагаю, что ваша проблема проистекает из: 1. конфликта между теорией и практикой, а также из того, что ... 2. ... вы должны понимать, что ваш код будет выполняться кодом другого. 3. Вы не можете что-то кодировать, если не знаете, что можете сделать. 4. Вы знаете половину трудности

1. Знание языка по теории не означает, что вы «говорите» на нем: это различие между чтением английского и разговором на нем. Кроме того, большое количество различных инструментов, доступных для компиляции, ссылки, редактирования исходного кода, заставит вас раскрутиться.

2. при обучении программированию чаще всего используется время, когда терминал используется для ввода / вывода текста, потому что это самый простой способ иметь дело с программированием. На самом деле, программисты используют библиотеки (например, Qt), фреймворки (я думаю, django) и другие сочетания клавиш для повышения производительности. Конечно, если вы чувствуете, что можете написать свое собственное колесо, не изобретайте его и не читайте книги о дизайне компилятора и дизайне ядра: у них есть чему поучиться: возможно, вы чувствуете, что глупо делать приложения, которые не требуют много техничности.

3. Придумай что-нибудь! Конечно, вы можете сделать текстовый редактор, игру и т. Д. Дело в том, что вы не будете делать это, если не видите причин для этого: эта программа будет бесполезна для вас, если все, о чем вы думаете, уже сделано , Персонал Я все еще мечтаю, чтобы иметь возможность кодировать децентрализованный протокол P2P, подобный Facebook, с помощью чата, автономных сообщений и т. Д., Все в одном, чтобы его можно было использовать со встроенными беспроводными устройствами. Интернет дает много возможностей, не забудьте подумать об этом.

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

Может быть, вы могли бы выбрать язык сценариев для начала. Я начал программировать на языке Си. По моему мнению, с языком C легко начать, но требуется гораздо больше времени, чтобы узнать алгоритм и кое-что об операционной системе. И каждый раз, когда я тренируюсь просто с графическим интерфейсом DOS, я впадаю в депрессию.

А позже я выбрал язык сценариев с именем ActionScript для запуска. Язык сценариев является объектно-ориентированным языком и может управлять поведением Flash-фильма. Язык сценариев прост для выполнения некоторой работы, близкой к проблемной области , как trace("HelloWorld")в ActionScript для вывода строки. И у него есть мощная IDE, позволяющая вам проверить, хорошо ли работает ваша программа.

Одним словом, если вы хотите начать программирование быстро , язык сценариев может быть хорошим выбором :-)

Напишите спецификацию. Что вы хотите, чтобы ваша программа делала? Экраны (если это программа на основе пользовательского интерфейса), логика, ввод / вывод и т. Д. Ограничьте область действия тем, что вы можете делать в разумные сроки (от одной недели до одного месяца?).

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

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

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