Чи постійно шукає приклади коду ознака поганого розробника? [зачинено]

Я студент CS з декількома роками досвіду роботи на C та C ++, і останні кілька років постійно працюю з Java / Objective C, роблячи розробку додатків, і тепер перейшов на веб-розробку і в основному зосереджений на рубіні rails, і я зрозумів, що (як і в розробці додатків, справді) я занадто багато посилаюся на інший код. Я постійно функціоную в Google для багатьох речей, я думаю, що я маю змогу зробити з нуля, і це справді трохи зламало мою впевненість.

Основні основи не є проблемою, я ненавиджу використовувати це як приклад, але я можу пробігатись через javabat в обох java / python у спринті - очевидно, це не є досягненням, але, що я маю на увазі сказати, у мене є сильна основа для основ Я думаю?

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

Чи є людина поганим розробником, постійно шукаючи приклади коду для помірних і складних завдань?

Скопіюйте та вставте наосліп: погано.

Перегляньте документацію, прочитайте приклади коду, щоб краще зрозуміти: добре.

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

Якщо ви кодуєте свої рішення рентабельним способом і насправді ПІДТВИТИ те, що ви копіюєте / вставляєте / модифікуєте, тоді проблем немає.

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

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

... Тут я говорю про вільне володіння. Про те, щоб бути не просто здатним на щось, але вільно володіти.

Чи знаєте ви, що це бути вільним? Це коли для когось, хто дивиться на вас, здається, що ви кодуєте під час введення ...

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

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

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

Існує теорія навчання, яка називається циклом Колба (за людиною, яка її описала). Записи цього циклу:

Concrete experience -> Reflective observation
    ^                        |
    |                        v
Active experimentation <- Abstract conceptualisation

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

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

Повне розкриття інформації - я старенька людина, яка пройшла підготовку в іншому до Інтернету, доступному в епоху роботи. Я спостерігав, як навички молодих розробників постійно погіршуються, в основному через те, що вони не зберігають інформацію та не розуміють рішення, яке вони захопили з Інтернету. Я зауважував, що рівень компетентності, який людина мав після 1-2 років досвіду, 20 років тому, зараз це рівень компетентності, який хтось має після 5-7 років досвіду. (Так, це особисте спостереження, але я багато працював, я не маю статистичних даних щодо цього питання, і так, я інколи старий і хитрий, візьміть це твердження із зерном солі. І тримайтеся поза моїм подвір’ям. )

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вам не потрібно бути таким хорошим, чи кращим, ніж будь-хто інший. Ви повинні задовольнятися тим, що вам завжди буде дещо бракувати, і що ви постійно навчаєтесь. Якщо ви не можете бути щасливими бути неповноцінним розробником, ви НІКОЛИ не будете щасливі.

І ще одне: ваш страх відмови від людей, які ви вважаєте «вищими» - це саме те, що заважає вам труїти плечі кращим розробникам та вчитися у них. Тож ваш страх заважає вам рости, що підтримує ваш страх. Що заважає вам рости. Бачите цикл? Ви повинні десь порушити цикл.

Я думаю, що багато чого залежить від того, як працює ваш розум. Моя пам’ять смердить, тож я б швидше захопив код, максимально наближений до того, що я хочу, і переробити його, щоб він зробив нову роботу. Він слугує прикладом і нагадуванням про всі речі, що я маю робити. Наприклад, я використовував простий SQL протягом 20 років, але я ніколи не можу запам'ятати макет оператора SELECT або UPDATE. (Я думаю, що потрібні круглі дужки, але я не можу пригадати, які.) З іншого боку, я можу запам'ятати кілька речей; Я можу об'єднати реалізацію Java Iterator із закритими очима.

Більшість кодів, які я копіюю, - це власний, але я, безумовно, копіюю інші, коли я дізнаюся щось нове.

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

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

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

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

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

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

Чи є людина поганим розробником, постійно шукаючи приклади коду для помірних і складних завдань?

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

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

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

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

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

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

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

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

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

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

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

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

Якщо ви придумуєте рішення A, а хтось інший придумує рішення B, коли кожен з вас поділиться своїми рішеннями, ви можете реалізувати рішення C, яке може бути навіть краще, ніж A або B.

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

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

Сьогодні для цього завдання потрібно знати мову, знати систему, знати парадигму, модель програмування та принаймні один набір API, який є рухомими цілями.

Отже, людина з певним рівнем базових знань, яка запитує навколо, не є гарним видом програміста. Він є найкращим програмістом, враховуючи сучасне середовище та незацікавлені фірми, як Microsoft, насправді застосовують будь-яку суворість до власної документації щодо основ. Більшість їхніх матеріалів - це довідкові матеріали, які є самими довідниками, а також дуже поганий зразок коду. (У мене виникли два випадки: "Установник Windows" та API для створення відеофайлів WMV.)

Оскільки Microsoft, Google і, в меншій мірі, Apple, всі покладаються на "громаду", щоб усунути цей справжній недолік, запитання навколо не просто важливо, це життєво важливо. І бути людиною, яку можна запитати і яка може дати ґрунтовні відповіді та відгуки в сьогоднішньому середовищі так само важливо. Ось чому такі веб-сайти, як stackexchange.com, такі ж корисні, як і вони.

Тому задайте питання (запитайте розумно!) Щодо зразків та поважайте людей, які надають відповіді, і це не буде сприйматися як ознака "поганого розробника".

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

І, будь ласка, не знущайтеся над тими, хто просить.

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

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

Мій досвід програмування був подібний. Я думаю, що ключі:

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

Ці принципи, здається, застосовуються під час вивчення будь-якої мови! Дивіться, наприклад, як запам'ятати нові слова . Метод Пімслера також працює так.

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

З вашої історії, ось деякі конкретні камені спотикання, я думаю, ви можете зіткнутися.

1. Якщо ви боретеся з синтаксисом, можливо, ви не отримуєте достатньої практики. Це особливо актуально, якщо ви копіюєте та вставляєте прямо у свій код, а не розробляєте повторення і - чи можу я сказати? - м’язова пам’ять, яка допоможе вам вийти справді добре. Щоб протистояти цьому, просто розробляйте вправи та дисципліну, орієнтуючись на повторення та час, які покращать ваш заклад у потрібних для вас місцях. Пропозиції:
   • Пишіть просту програму однією і тією ж мовою раз на день, щодня.
   • Введіть приклади замість їх копіювання та вставлення.
2. Якщо ви боретеся зі створенням рішень для проблем середнього розміру, можливо, ви не отримаєте достатнього досвіду з будівництвом. Спробуйте такі:
   • Почніть проект середнього розміру в тій чи іншій технології або мові, якою ви хочете отримати хороший результат. Або спробуйте свої функції на чубчик у проекті з відкритим кодом, який вас цікавить. Змагайте на це трохи щодня. (Пам'ятайте, коли ви збираєтеся робити ці великі проекти: ходіть на них цеглини цеглини. Не намагайтеся одразу ж будувати все!)
   • Використовуйте ту саму нову функцію чотири дні поспіль у чотирьох різних контекстах.
   • Киньте виклик, щоб кодувати щось із вимкненим веб-браузером!
   • Насправді робіть нотатки про речі, які ви вивчаєте. Синтезуйте те, що ви дізнаєтесь, і запишіть свої спостереження. (Насправді записувати речі і змушувати себе висловлювати щось власними словами, мені дуже допомагає.)
   • Напишіть відповіді та перевірте їх на питання StackOverflow щодо технології, яку ви поглинаєте. (Це часто має додаткову перевагу - заробити вам трохи репутації під час навчання. :-))
3. Ви можете занадто тонко поширювати свою практику. Ви, здається, працюєте багатьма різними мовами. Це має масу переваг, але це має недолік розбавити ваш досвід. Якщо ви витрачаєте час, працюючи на п'яти різних мовах, ви запам’ятаєте менше, ніж якщо будете проводити один і той же час однією мовою. Гірше, що між різними мовами є багато не зовсім схожих коньяків (це було б інше, якщо, elsif, або elif ??), щоб подолати вас. Щоб протистояти цьому, посиліть свою увагу. Виберіть одне, щоб навчитися, і навчіться це холодно. Потім переходимо до наступного.

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

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

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

Візуалізуйте це, бажаючи переглянути речі в Інтернеті.

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

Не бійтеся ставити запитання, займайтеся дослідженнями в Google, намагайтеся і не вдається. Це все є частиною цього.

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

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

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

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

Отже, що робити? Можливо, вам знадобилося лише кілька сотень погладжувань по спині, які ви щойно отримали, і тепер можете впевнено кодувати. Але якщо це не справило роботу, пропоную розібратися в автоматизованому тестуванні та тестовій розробці. Ніщо не говорить про "молодець", як "Усі тести пройшли" з набору тестів: Коли ви туди потрапите, ви знаєте, що все зробили правильно.

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

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

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

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

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

Я ніколи не мав шансу вступити до університету, коли я був на вулиці в 16 років. Якось у 24 роки я був у змозі вчитися через заочне училище та робити сертифікати продавців як SCJP, SCJD, SCBCD та SCWCD. Я мушу визнати, що часом я боровся і доводилося звертатись до Інтернету для прикладів. Невідомо, хоча в цей час у мене зростала пухлина мозку в голові (до 2010 року вона була розміром з апельсина). Після моїх 5 операцій на мозку, 6 тижнів поєднував хіміо / променеву терапію та 10 місяців хіміотерапії, я все ще програмую написані вручну кодовані сайти, які можна побачити з мого профілю.

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

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

Однак з цього виходять хороші речі: Ви) НАВЧАЙТЕ так багато під час тестування на помилки (також сильно плачте) Б) Знайте, щоб ніколи більше не кодувати таке, і навчитися кращій практиці кодування. Крім того, на хакатонах ви зустрінете людей, які можуть навчити вас стільки нового, про що ви ніколи не знали, і ви будете робити те, чого ніколи не збираєтеся робити у школі.

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

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

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

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

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

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

Я часто жартую, що я знаю все можливі та комп’ютерні мови комп'ютера, ніж мою рідну англійську мову. Хто задає питання; "Ви поясніть мені це в Java plz?"

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

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