Як перейти від вміння писати код до хорошого розробника?

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

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

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

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

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

Є кілька речей, які я навчився роками від інших та завдяки роботі над різними проектами, такими як:

• Зробіть все перевіреним, це полегшить ваше життя набагато простіше;
• Ви не можете розраховувати на ідеальний дизайн і мати змогу розробляти корпоративну програму / наступну найбільшу назву гри / вставляти більше тут, не маючи досвіду в цьому;
• Складно розробити гарне програмне забезпечення, якщо ви не мали досвіду цього і навчились інших;
• Ви ніколи не будете мати ідеальний дизайн вперше, навіть як досвідчений розробник - все змінюється і тому; ваш дизайн також може бути;
• Запишіть речі: Написання / малювання / дошка / малювання / що б там не було вам комфортно, це полегшує життя, якщо у вас є речі, записані. Такі, як дизайни графічного інтерфейсу, діаграми класів і т. Д. На мій досвід, просто "зламати щось разом" має потенційний збій катастрофічно;
• Не вигадуйте колесо, вам не доведеться. Якщо ви намагаєтеся реалізувати свій власний HashMap, то, ймовірно, ви робите щось не так. Дослідіть речі та подумайте, перш ніж писати код.

Сподіваюсь, що щось із цього допомагає.

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

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

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

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

Інша річ, яку я пропоную вам стати хорошим розробником / інженером програмного забезпечення - це внести свій внесок у програмне забезпечення з відкритим кодом. Багато хлопців заробляють непогану суму грошей (та досвіду, btw), допомагаючи розробляти програмне забезпечення з відкритим кодом та надаючи консультації після цього. Вони зробили собі ім’я своїм внеском у відкритий код.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перш за все, вам слід дотримуватися наукового методу, з деякими надмірностями.

1. У вас є проблема (використовуйте інструменти та методи, щоб допомогти визначити це)
2. Ви гіпотезуєте рішення (довідки щодо моделей та досвіду)
3. Гіпотеза тесту (тут ви навіть можете не мати коду)
4. Повторіть кроки 2 і 3 до тих пір, поки гіпотеза не буде виконана. Тепер у вас є теорія (робоча програма для вирішення проблеми)
5. Розробіть експеримент з теорією стресу, шукаючи дірки (тестові випадки!)
6. Якщо тестові справи мають місце, у вас є рішення! В іншому випадку промийте і повторіть

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

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