Я читав багато книг для різних мов програмування, Java, Python, C і т. Д. Я розумію і знаю всі основи мов і розумію алгоритми та структури даних. (Рівнозначно, наприклад, два роки занять з інформатики)

Але я все ще не можу зрозуміти, як написати програму, яка робить щось корисне.

Усі книги з програмування показують вам, як писати мову, але НЕ як її використовувати! Приклади програмування - дуже елементарні, наприклад, скласти каталог карт для бібліотеки або просту гру або використовувати алгоритми тощо. Вони не показують, як розробляти складні програми, які насправді роблять нічого корисного!

Я переглянув програми з відкритим кодом на SourceForge , але вони не мають для мене особливого сенсу. У кожній програмі сотні файлів і тисячі рядків коду. Але як я дізнаюся, як це зробити? Ні в одній книзі, яку я можу придбати на Amazon, не було б нічого, що дасть мені інструменти написати будь-яку з цих програм.

Як ви переходите від читання «Вступ до Java» або «Програмування Python», «Мова програмування на C» тощо), щоб насправді сказати, що я маю ідею для програми X? Чи так я розвиваюсь?

Здається, що в написанні програми набагато більше задіяно, ніж можна дізнатися з книги чи з класу. Я відчуваю, що щось є.

Як я можу бути поставлений на правильний шлях?

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

На цій сторінці вам може бути цікаво "Навчіть себе програмуванню на десять років" http://norvig.com/21-days.html

BTW: Запустити програму дуже важко. Письменник може назвати це "блоком письменників". Натомість я пропоную вам почати писати код і вдосконалити його. Не бійтеся видаляти великі розділи, які не роблять того, що вам потрібно. Почніть знову, цього разу ви напишете з кращим уявленням про те, що робите. Почніть знову, і ви виявите, що вам не потрібна половина того, що ви писали минулого разу. Коли автор пише оповідання, це потребує багато часу, багато написання та переписування тощо. Багато оглядів та відгуків, і його закінчено лише тоді, коли воно має бути опубліковано (випущено)

Мене завжди переймали дуже великі проекти, як і ті, які ви знайдете на SourceForge або GitHub. Мені було цікаво, як хтось, а то й команда, може зрозуміти, що відбувається через 10 чи 100 файлів із тисячами та тисячами рядків коду.

Ніхто не робить. Принаймні спочатку.

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

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

Приклад:

У випадку напіввеликого проекту він часто починається з малого. Msgstr "Я хочу створити кеш-сервер". Таким чином, ви проводите кілька днів злому, і доходите до того, що працює, але може бути значно покращено. Отже, ви додаєте концепцію нарізки.

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

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

Начебто все працює нормально, за винятком того, що користувачі починають скаржитися, що операції не є атомними, а дані пошкоджуються.

Таким чином, ви додаєте в класичні атомні операції, такі як збільшення та збереження. Це працює, і ваші користувачі раді. Але хтось відкриває квиток, запитуючи, чи можна робити операції зі списком.

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

Два квитки відкриті. Існує помилка в обробці списку, і є деякі рідкісні випадки, які виявляються тупиковими.

Ваш друг працює над помилкою, що обробляє список, і ви вирішуєте тупик. Ви розумієте, що має відбутися досить значна переписка на атомні операції.

... і так воно йде.

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

Моя порада:

Не перевантажуйтесь. Якщо у вас є ідея, реалізуйте фрагменти функціональності. Якщо після цього варто переслідувати, додайте потроху. Нехай ваш проект росте природним шляхом.

Навіть найбільша програма починається з ідеї і пишеться по одному рядку.

Найкращий (можливо, єдиний) спосіб навчитися писати програми в реальному світі - це почати робити це. Коли у вас виникають проблеми, ви шукаєте в Інтернеті або просите тут вирішити ці проблеми. Врешті-решт, ви отримаєте досвід і вам доведеться запитувати рідше.

Однак є деякі речі, про які слід пам’ятати з самого початку:

• Навряд чи будь-яка велика заявка написана повністю з нуля в ці дні. Ви можете зробити набагато більше за набагато коротший час, якщо використовувати наявні високоякісні бібліотеки та рамки. Початок роботи з цим часто відчуває себе досить засмучуючим і більше працювати, ніж робити це самостійно, але це майже ніколи не так.
• Ретельно обдумуючи, як ви структуруєте програму (як її розробити), дуже важливо, як тільки ваші програми стають масштабнішими. Витратьте трохи часу на це, і прочитайте кілька книг про дизайн (я особливо рекомендую «Чистий код») та інженерії програмного забезпечення, а також про технічні основи.

Те, про що ви говорите, - це більше інженерія програмного забезпечення, ніж програмування. Це трохи архітектури, трохи "кращих практик" та "моделей дизайну", трохи роботи з іншими. Хоча є книги, які можуть допомогти, більшість з них походить з досвіду. Ніхто не починає писати, скажімо, Microsoft Word.

Подумайте про велику, "справжню" програму, яку ви хотіли б написати. Тепер подумайте про різні деталі, які вам потрібно побудувати, щоб змусити його працювати так, як вам хочеться. Наприклад, у сучасній грі від першої особи вам знадобиться 3D-графічний двигун, AI, який не належить до гравців, музичний / звуковий модуль, фізичний двигун та модуль вищого рівня, який виконує правила гри (знає "карта", як взаємодіють різні символи тощо). А далі - художній твір та дизайн персонажів та музика, жодна з яких не є кодом, але необхідна для завершення гри.

Тепер: що з них ви побудуєте самі, а які ви отримаєте в іншому місці? Більшість великих програмних програм не запрограмовані з нуля. Можливо, ви будете використовувати позаштатний тривимірний двигун та музичний / звуковий модуль та програмувати лише те, що робить вашу гру унікальною. Гаразд, тому ви повинні розібратися, які сторонні модулі ви збираєтеся використовувати, які включатимуть такі фактори, як вартість, якими мовами вони працюють, якими функціями вони володіють, як розроблений їх API (тобто, наскільки повно його тобто, наскільки це добре відповідає вашому особистому стилю програмування тощо). Можливо, ви напишете "докази концепції" або тестові програми, використовуючи одного або двох кандидатів для різних сторонніх модулів, щоб переконатися, що вони виконають усі необхідні речі та прості у використанні.

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

Після того, як ви зрозуміли, які модулі ви хочете написати вдома, ви виконуєте той самий процес. З’ясуйте фрагменти кожного модуля, як вони повинні поєднуватися разом, і які ви самі напишете та які ви отримаєте в іншому місці. Продовжуйте розбивати речі, поки кожен твір не буде достатньо малим, щоб ви могли мати його в думці, щоб ви сказали: "Так, я можу це написати!" А потім зробіть так. У той же час ви зіткнетеся з непередбаченими перешкодами в тому, як різні частини вашої програми поєднуються між собою. Це буде неприємно, але вони дадуть вам можливість дізнатися більше про ваше ремесло, і на це слід дивитися.

Спочатку ви зможете утримувати у своїй свідомості лише невеликі шматочки програми - скажімо, окремих функцій, і тому вам доведеться багато розбити, перш ніж розпочати кодування. За міру набуття досвіду, ви будете думати , в функції , а не необхідності думати про функціях і почати думати про об'єктах. І тоді ви будете думати в об'єктах і думати про великих модулях. Нарешті, ви будете думати в модулях і думати про цілі, великі, реальні програми.

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

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

Якщо виявиться, що ви не хочете бути програмістом, який пише великі, реальні, настільні програми, існують інші види завдань програмування. Ви можете, наприклад, стати вбудованим програмістом. Існують певні цікаві завдання, пов'язані з написанням вбудованих програм, і ви робите корисну роботу, але зазвичай програми є значно меншими, ніж настільні програми. Або ви можете написати веб-додатки. В Інтернеті легко склеїти невеликі шматочки функціональності разом, щоб ви могли написати (наприклад) систему веб-коментарів, і це було б корисно, навіть якщо це не вся веб-програма. Покращити речі в Інтернеті також легко, тому ви можете почати з (скажімо) основного клієнта веб-пошти та з часом перетворити його на щось на зразок Gmail. (Але не робіть цього, оскільки тоді ви будете конкурувати з Gmail.)

Якщо ви взагалі не хочете бути програмістом, але все ще хочете працювати з комп’ютерами, можливо, ви можете зайнятися інформатикою чи іншою технічною сферою. У цих випадках дуже корисно знати програмування, як ви вже робите, тому що ваші однолітки можуть навіть не так багато. Або, знаєте, стати музикантом, якщо це сподобається, бо (як і більшість полів) у ньому сьогодні входять комп'ютери. Пишіть маленькі програми, які керують аудіо- чи MIDI-файлами різними розумними способами, тим самим роблячи вас кращим музикантом. Ви побачите, що будь-які навички програмування у вас можуть бути застосовані у багатьох сферах, щоб покращити свою роботу.

Ви не зрозумієте, як програмувати, якщо перед вами не постане справжнє завдання. Жодна теорія ніколи не замінить просте завдання в реальному світі. Перш ніж почати працювати над сценаріями rw, я наївно читав партії книг із усіма прикладами, але коли зіткнувся з реальною проблемою, я просто не зміг зібрати всі свої теоретичні знання для виконання завдання. Якщо ви починаєте, я рекомендую вам отримувати завдання з будь-якого місця. Не думайте, що вони марні, якщо ви їх не вирішили. В якості першого кроку спробуйте вирішити проблеми структури даних, такі як сортування зв'язаного списку, виконання DFS, BFS на деревах, графіках тощо. Це не тільки покращить ваші навички кодування, але що важливіше, це покращить ваші аналітичні та алго навички , які мені довіряють - цінне знання. Потім, коли ви дізнаєтесь, що ви можете гойдатися за допомогою покажчиків, рекурсії,

Нижня лінія. Вся справа в практиці. Просто продовжуйте копати і код, код, код.

Почніть з комп'ютерних ігор, як і всі інші. Хороша гра - це і завдання програмування, і проектування, потребує ретельного роздуму над внутрішньою структурою, і вона використовує системні бібліотеки способами, які багато чому вчать, але не прагнуть до ламання і не потребують "вагомих причин з хорошим результатом" як власне "корисне" програмне забезпечення.

Загальне правило полягає в тому, що після написання достатньої кількості матеріалів неминуче відбудеться якесь просвітлення.

Приємний момент для початку (якщо вам здається, що C) - http://gamedev.net/ , особливо http://nehe.gamedev.net/ . Є також багато інших хороших моментів для початку: D

Ви дивитесь на всю величезну програму, і це здається неможливим. Але вся справа складається з маленьких дурних програм на кшталт тих, які ви говорите: "не робіть нічого корисного".

Вам потрібно досвід розбиття величезних складних завдань на крихітні прості завдання. Це корінь усього програмування. Решта - це просто семантика.

Як і за кермом чи приготуванням їжі, програмування - це те, чого ви навчитеся робити. Практика незамінна.

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

Або, якщо ви маєте на увазі конкретну ідею, розбийте її на шматочки. Спочатку вирішіть невелику підмножину проблеми. Потім розгорніть. Коли інтеграція нового коду до вашого існуючого коду стає важкою, тоді ви все переробляєте.

Напишіть сценарій 200 рядків. Тоді починайте її вдосконалювати.

Featuritis дозволить вам отримати 100 вихідних файлів і кілька сотень KLOC за один раз :)

"Вони не показують вам, як розробляти складні програми, які насправді роблять щось корисне!"

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

Ми не знаємо, як ти провалюєшся, або що відбувається не так. Ми не можемо сказати, на якому треку ти йдеш.

Якось у тебе в голові поняття, що ти не спілкуєшся.

Програмне забезпечення - програмування - це все про те, щоб поняття з голови не перейшло на якусь мову (Python, Java, англійська мова та будь-яку іншу).

Важливим кроком у програмуванні (і заданні питань) є визначення ваших термінів. Що ви маєте на увазі під «робити щось корисне»? Будьте дуже чіткими, дуже повними та дуже точними.

Мені постійно задають це питання, наприклад, як розпочати роботу. Це справді просто. Ось крок за кроком.

1. Придумайте ідею. Схоже, у вас це вже є.
2. Спростіть свою ідею до її основної основи - чогось, на вашу думку, ви зможете вирішити
3. Розмістіть інтерфейс користувача на аркуші паперу або серветці, будь-що.
4. Спробуйте налаштувати інтерфейс користувача у вашому середовищі розробки.
5. Якщо у вас виникли труднощі, google, google, google, задайте питання про stackoverflow, використовуйте живі лайки з Інтернет-ресурсів, щоб отримати допомогу. Попросіть друзів та колег, які є програмістами, щоб допомогти вам у конкретних ситуаціях. Поверніться до кроку 4.
6. Почніть писати логіку вашої заявки. Якщо у вас виникли труднощі, перейдіть до попереднього кроку та повторіть спробу.
7. Незабаром у вас незабаром щось буде працювати.

Створіть щось невелике. Не зауважте, що ваша програма буде 1000-ю, що робить це.

Деякі ідеї:

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

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

Добре, почнемо з вашої ідеї для програми X, яка робить щось корисне, і давайте розбимо її:

• Використовуйте програмне забезпечення для паперу, уявлення чи діаграми для планування логічних потоків / потоків програми.

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

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

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

Як говориться - Gnome не будували за день :-)

(відповіли вище в коментарях. Пропонувалося подати це як відповідь після повторного відкриття питання.)

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

Тоді ви працюєте над наступною підпроблемою. Працюючи над кожною проблемою, ви можете писати невеликі тестові випадки і насправді бачити, як ви прогресуєте, що вдається. Завжди завжди будуть виникати виклики, але в жодному разі це не буде розглядатись як щось занадто колосальне, щоб навіть підходити (з чим, здається, зараз йдеться). Це стосується програмування та багатьох життєвих проблем. Головне - це розбити.

Щодо того, що робити - ідея. Ви можете спробувати винайти щось нове, але ви також можете взяти щось, до чого ви могли б захопити і вже існує, але просто зробити це кращим або навіть просто іншим. Зараз у вільний час пишу програму гітарного тюнера для Android. Я знаю, що вже існує багато інших програм гітарного тюнера, але я подумав, що це буде цікавий та складний проект, тому я взяв його на себе. Спочатку це здавалося майже неможливим, але після того, як я розбив проблему на менші кроки, вона насправді гарно зібралася. Розділіть і підкоріть і будьте наполегливі своїм цілям.

Одна з найскладніших речей, коли ти починаєш, це встановлення реалістичних цілей того, що вправа "як я можу покращити" повинна містити на поточному рівні.

Тому я б запропонував вам вибрати практику розв’язування невеликих, заданих вправ, адже вміння закінчувати програму відповідно до заданих специфікацій - дуже цінна річ для всіх, хто програмує на життя.

Я б запропонував вам детальніше ознайомитись з http://projecteuler.net/, який має багато вправ та автоматизовану систему "перевірити відповідь", що дозволяє вам працювати у власному темпі. Вправи добре сформульовані, але можуть зажадати вас подумати. Деякі можуть навіть вимагати від вас багато думати, але навіть не в змозі їх вирішити, ви навчите чогось корисного.

Повна редакція проблеми 1:

Якщо перерахувати всі натуральні числа нижче 10, кратні 3 або 5, отримаємо 3, 5, 6 і 9. Сума цих кратних дорівнює 23.

Знайдіть суму всіх кратних 3 або 5 нижче 1000.

Як ви думаєте, ви могли це вирішити? Тоді зробіть це!

Вам потрібен реальний світовий досвід !! . Жодна книга не може вас цього навчити!

Ви повинні навчитися читати код інших, як його підтримувати, як ненавидіти їх (і код, і кодер), як його вдосконалити, як подумати, що ви можете це зробити краще, і через кілька місяців кричати вголос я ' Уб'ю когось, хто коли-небудь писав цей шматок коду !!! Тільки щоб дізнатись у контролі версії джерела це були ви!

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

Тому я б запропонував вам знайти якусь роботу з програмування. За потреби подайте заявку на найосновніший рівень вступу. Напевно, ви не заробляєте стільки, скільки вважаєте, що заслуговуєте, але скористайтеся кількома місяцями, щоб дізнатися, як розробляється програмне забезпечення в реальному світі (і це не завжди так ідеально і з усіма цими прекрасними найкращими практиками, які ми читаємо в Інтернеті , багато разів якість коду дуже низька, залежно від місця роботи, але це частина досвіду)

Продовжуйте читати свої книги, ви дізнаєтесь, щороку ви розумієте трохи більше (або по-різному) одну і ту ж тему, адже ви можете це бачити, знаючи зі склянкою досвіду.

Якщо вам вдасться влаштуватися на роботу з талановитими розробниками, набагато краще. Навчіться у них, не бійтеся робити помилки.

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

:)

Спробуйте проект з відкритим кодом, подивіться, чи можете ви приєднатись. Почніть із завантаження джерела та дізнайтеся, чи можете ви забрати якісь квитки

Коли я хочу вивчити нову мову, я зазвичай намагаюся реалізувати якийсь фрактальний графік. Таким чином ви отримаєте негайний відгук про те, якщо це працює, і це дуже корисно. І існує безліч способів поліпшити фрактал. Наївна реалізація мандельброта повільна, як пекло.

Це не дуже корисно, але ти багато чого вчишся і на це красиво дивитися.

Програмування - це вирішення проблем та спілкування, а не написання великої кількості коду. Код - це просто необхідність, зазвичай слід намагатися писати менше коду, а не більше.

Якщо ви не знаєте, з чого почати, можливо, у вас просто немає проблем!

Подивіться на Linux та інші системи, схожі на Unix: всі вони складаються з безлічі невеликих додатків, які роблять лише одне, але роблять це добре .

Коли мені знадобився сценарій, щоб знайти 10 найбільших файлів у папці на своєму комп’ютері, я не читав книги. Я просто гуглив і використав одне з існуючих рішень. Я написав якийсь код? - Ні. Чи вирішена проблема? - Так. Чи корисна ця однолінійна програма? - Чорт так.

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

Розділяй і володарюй.

Це так просто, або важко.

Коли я почав програмувати, я любив комп’ютерні ігри. Тому я почав писати власні ігри, як тільки мав під рукою будь-які інструменти.

Цілком природно, що моя перша гра була текстовою пригодою. Точно так само ви можете почати з вікторини чи чогось, або якихось ігор для відгадок.

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

Це навчить вас основ керування деяким введенням користувача, підтримання стану гри та відповідного отримання результатів.

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

Я думаю, що ігри справді чудові для вивчення програмування. Навіть маючи невеликий досвід, ви можете створювати невеликі речі, які дарують вам маленькі миті гордості. Тому що ти щось створюєш, це весело. Створювати фактичні додатки досить безглуздо, тому що для створення чогось, що насправді корисно, потрібно багато роботи, тоді як створити невелику гру, яка виявляється захоплюючою, напрочуд просто.

Можливо, ви хочете насправді використовувати навчальну мову (в моєму випадку це було ПАСКАЛЬНО, і в ретроспективі, я думаю, це виявилося досить вдалим вибором). Дуже багато з них спеціально спрямовані на створення ігор і подібних.

Створення програм - це більше, ніж просто створення алгоритмів. Вам потрібно розробити функції, вам потрібно впорядкувати та структурувати свій код у різних шарах та модулях. На відміну від досить "атомних" проблем, які вам задаються в університеті, програми іноді найкраще розробляти поступово. Ви починаєте з чогось і додаєте речі поверх цього. Таким чином, вже маючи з чого почати (як це було б у деяких мовах, перелічених у статті вікіпедії), ви заощаджуєте себе багато розчарувань і починаєте щось створювати відразу. (Моя колега розпочала програмування, написавши мод-2 модів). В якийсь момент ви знайдете обмеження цих простих у використанні інструментів, але до цього часу у вас буде набагато більше розуміння та розуміння. Напевно, достатньо,

У коледжі існував клас під назвою практикум програмування, який в основному викладав цю рампу. На початку вам надали інтерфейс користувача для основної програми для покупок, і довелося кодувати бекенд, останній місяць був Tetris з нуля. Я думаю, що близько 50% нових студентів (не перебираючи клас) не вдалося, тому що перейти з малого на велике неймовірно складно.

Я б запропонував одне або кілька із наступного:

• Завантажте проект із відкритим кодом та додайте щось. Це не повинно бути корисним чи хорошим, але вам доведеться подивитися на структуру, яка дасть вам відчуття того, як будується великий проект.

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

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

• Якщо ви знаєте когось із досвідчених, скажіть їм свою ідею для проекту та дозвольте їм написати свої заняття + деякі важливі методи, ймовірно, це займе годину чи близько того. Таким чином ви можете просто заповнити методи і завжди знати, що вам потрібно зробити далі.

Нарешті, що б ви не робили, ви, ймовірно, повинні використовувати базовий шаблон дизайну MVC (Model, View, Controller). Не вдаючись до деталей, розмістіть свій погляд (UI) на класи 1+, ваш контролер (Введення, виведення тощо) на класи 1+, а Ваша модель (Логіка, Дані, в основному все інше) на кілька класів. Це простий спосіб отримати базову організацію.

Пам'ятайте, цей крок важкий. Це правда, що деякі люди просто не можуть програмувати, але ви, мабуть, просто застрягли на цьому етапі. Удачі!

По-перше, ви вже робите передумови, займаючись заняттями, читаючи довідкові матеріали, переглядаючи проекти з відкритим кодом та залишаючись цікавим із запитаннями. Я наголошую на цьому, тому що я особисто стикався з подібними питаннями, перш ніж людина зробила будь-яку роботу з ногами зі свого боку (зокрема, люди, які обходять заняття та сподіваються на скорочення). Тепер я думаю, коли ми працювали в лабораторіях про машини Тьюрінга, і як я відчував, що це не справжнє програмування. Це досвід, який ви будете тримати, що кожен, хто робить скорочення, пропускає.

• Підписка на студентські проекти. Я взяв участь (CSUA) з групою однодумців, щоб створити гру для карнавальної будки мого старшого курсу. Якщо ви продовжуєте насолоджуватися цим і думаєте, що хочете розширити свою участь, дійсно скористайтеся ресурсами. Дізнайтеся про проекти, поговоріть зі своїми однокласниками, професорами та влаштуйтеся на стажування.

• Сядьте з досвідченим програмістом. У моїй історії було близько трьох разів, коли я дивився програму іншої людини, яка була справді натхненною. Вони просто писали код і думали вголос. Не перебільшуючи, я відчував, що я більше поглинувся від прослуховування їх, ніж я б пройшов років самостійно. Якщо ви стикаєтеся з більшою, ви набагато багатші. Нам пощастило потрапити в епоху, коли ми можемо дивитись відео, перевіряти повні сховища джерел та миттєво шукати величезний інтернет-магазин знань. Це не замінює особистого досвіду, але за відсутності наставника - це кардинальне поліпшення порівняно з традиційним матеріалом. Дивлячись на інший вихідний код сам по собі може ні до чого не призвести. Вам захочеться мати щось на увазі і хороший налагоджувач, щоб вступити в логіку. Одним з моїх найприємніших моментів було створення мода Quake, і саме мод не мав нічого запам’ятовуваного. Це було бачення ігрової логіки Кармака. Мод був просто причиною для мене зануритися.

• Тренуйтеся пояснювати та відповідати на питання, поставлені вашим партнером у лабораторії. Волонтер, щоб допомогти навчити. Можливо, сформуйте навчальну групу і вимагайте від кожного члена стати експертом з класної теми. Тоді обсмажте цю людину та дайте їм на грилі. Коли ви змушені відповідати на запитання, ви зобов’язані самі дізнатися відповіді. Коли ви можете чітко пояснити поняття іншим, ви збагатили власне розуміння до того моменту, коли зможете передати це поза книгою та своїми думками.

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

Вам не потрібно мати ідеї, щоб почати щось програмувати. Я б почав з легкої частини. Мовляв, програма, якою ви вже користуєтесь. Спробуйте зробити щось, що ви вже знаєте, як це працює. Зіштовхується зі своїми проблемами, тому ви швидше навчитеся цьому. Як тільки у вас буде більше досвіду, ви почнете мати хороші ідеї програм, які полегшать вам життя під час програмування, або просто хороша програма, щоб зробити щось, про що ви раніше про це не думали. Я майже рік програмував Java, а інші мови - пару років. Потрібен час, щоб почати робити те, що я дуже хотів зробити. Я тільки почав займатися своїми справами. Завдяки StackOverflow. Я про це раніше не знав.

Тож є багато відповідей, тож пробачте мене, якщо я повторюю багато з того, що вже було сказано, але ось мої 2 копійки.

Спочатку виберіть ідею. Будь-яка ідея буде добре, щось просте, мабуть, було б краще, ніж велике. Проекти мають тенденцію до зростання своїх масштабів дуже швидко (деякі називають це повзання).

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

Збережіть скелет у своєму ДКС (виберіть отруту за допомогою цієї і тримайте, коли це призведе до святої війни). Після того, як ви почали використовувати VCS, постійне використання його для невеликих змін стає другою природою, але обов’язково почніть.

Тепер виберіть невелику, але важливу функцію для системи та зробіть її. Не переживайте за те, щоб переконатися, що у вас все ідеально капсульоване, і що він має "найкращий" дизайн (який буде розвиватися разом із системою). Просто дістаньте щось, що спрацює. Також отримання тестів на одиницю допоможе вам зрозуміти, що сталося, коли щось зламається, якщо ви запускаєте тести регулярно.

Створіть свою систему. Це також вдалий час для автоматизованої системи побудови та постійної інтеграції. Якщо ви не знаєте, що вони є, то або вивчіть це і спробуйте, або просто продовжуйте на свій страх і ризик; будь-який спосіб продовжувати працювати.

Тепер виберіть іншу функцію і повторіть, повторіть і повторіть.

Як тільки ви думаєте, що це працює добре, покажіть це другові. Друг не повинен знати, як програмувати або навіть знати, що робить програма. Той, кому ви будете почувати себе добре, показуючи комусь та двом, це допоможе вам точно знати, що робить система.

Якщо ви доберетеся до того, що ви дуже впевнені в тому, що ви зробили, випустіть його в Інтернеті і спробуйте отримати зворотній зв'язок. Центр сховища або програміст підредітт можуть надати вам певну конструктивну критику. Спробуйте знайти професора CS / SE і попросіть його / її подивитися. Можливо, запитайте у професійного програміста. Просто отримайте іншу думку програмістів.

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

Щось, що може допомогти, - це думати просту проблему, з якою у вас є день у день, коли щось, що ви можете зробити олівцем і папером, можна замінити програмою.

Це створює порівняно просту проблему з досить відомим рішенням, яке просто потребує рівня автоматизації. Майте на увазі, що це не обов'язково має бути наступним MS Word / WordPad / NotePad; просто щось, що вирішує вашу (просту) проблему.

Наприклад, проблема, яку я продовжую повторно виконувати, працюючи з новою мовою, - це простий додаток хронометражу. Додаток використовується для відстеження оплачуваних годин на різні проекти протягом дня. Досить проста програма з безліччю маленьких діток, як, наприклад, як ви обробляєте перезавантаження в середині дня або як додавати / видаляти елементи зі свого списку.

Я думаю, що проблема полягає в тому, що коли ти читаєш книги з програмування, вони просто навчають тебе мові. Вони не згадують, що для програмування майже нічого вам потрібен доступ до програмування БІБЛІОТЕКИ та SDKS тощо. Просто знання мови, на жаль, недостатньо.

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

1. Знання мови теоретично не означає, що ви "розмовляєте" нею: це різниця між читанням англійської мови та її розмовою. Також велика кількість різних інструментів для компіляції, посилання та редагування вихідного коду зробить вашу голову круткою.

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

3. Придумайте щось! Звичайно, ви можете зробити текстовий редактор, гру тощо. Справа в тому, що ви цього не зробите, якщо не бачите причин: ця програма буде для вас марною, якщо все, про що ви думаєте, вже зроблено . Персоналі я все ще мрію мати можливість кодувати facebook-подібний децентралізований протокол p2p з чатом, офлайн-повідомленнями тощо. Інтернет дає багато можливостей, не забудьте подумати про це.

4. Насправді теорію потрібно практикувати, але це ще не все: алгоритми та техніка не є частиною теорії програмування, є багато парадигм та інших "стандартних" способів зробити ваш код: шаблони дизайну, пов'язані списки, тощо.

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

А пізніше я для початку вибрав мову сценаріїв з назвою ActionScript. Мова сценаріїв - це об'єктно-орієнтована мова, і вона може керувати поведінкою фільму Flash. Мова сценаріїв легко виконати певну роботу, близьку до проблемної області , як і trace("HelloWorld")в ActionScript для виведення рядка. І він має потужний IDE, який дозволяє вам перевірити, чи добре працює ваша програма.

Одним словом, якщо ви хочете , щоб почати програмування в швидкий спосіб, мова сценаріїв може бути хорошим вибором :-)

Напишіть специфікацію. Що ви хочете, щоб ваша програма займалася? Екрани (якщо це програма, що базується на користувальницькому інтерфейсі), логіка, введення / виведення і т. Д. Тримайте область обмеження тим, що ви можете зробити за розумну кількість часу (тиждень? Один місяць?).

Потім будуйте його. Дотримуйтесь специфікації, змушуйте її працювати відповідно до того, що специфікація потрібна. Впевнені, що ви зіткнетесь з відволіканням, впевненим, що вам доведеться провести деякі дослідження, тому що ви ніколи раніше не стикалися з певною проблемою, але ви побудуєте щось, що хотіли побудувати. Це відрізняється від того, щоб будувати щось, що ви просто «можете» побудувати.

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

Пам'ятайте, більшість комерційних програм вирішують потребу. Дуже важливо визначити потребу та рішення для заповнення, яке потрібно, перш ніж реально вирішити проблему. І коли потреба зростає та збільшується, з часом ваше програмне забезпечення також зростатиме!