Чи підходить фраза «ніколи не винаходити колесо» для студентів?

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

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

Чи погано «винаходити колесо»? Може, я помиляюсь? Можливо, є спосіб, яким я можу уникнути винахідництва колеса і одночасно багато чому навчитися?

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

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

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

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

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

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

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

Будучи викладачем або програмуванням, я постійно борюся з протилежною стороною проблеми: коли я прошу учнів винаходити колесо?

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

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

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

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

Щоб відповісти на запитання більш прямо, дві пропозиції:

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

Практика Я сумніваюся, що перші 1000 рядків коду, хто пише, дуже унікальні.

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

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

Абсолютів мало .

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

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

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

Якщо ви отримаєте щітку "Використовувати бібліотеку X / Framework Y" на SO, передмовте своє запитання "Я сам пишу X, щоб дізнатися більше про нього"

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

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

З шумерських часів багато речей змінилося:

• Матеріал, який використовується для побудови коліс: з каменю, дерева, металу, вуглецю, ...
• розмір предметів, що потребують коліс - розміром нанометрів для медичних інструментів та коліс для заробітку бурого вугілля, розміром 100 м
• виробниче середовище - ручне виробництво, або промислове виробництво
• точність коліс, які потрібні
• Правильна ситуація навколо вашого колеса. Можливо, є ідеальне колесо для вашої роботи, але воно може бути запатентоване.
• Блиск і полірування для вашого колеса. Cadillac може заслужити інше колесо, ніж VW Golf.
• Оптимальне колесо для дитячої коляски залежить від багатьох параметрів: Розмір і вага коляски (плюс дитячі / ~ і), кліматичні обставини, ціни на ресурси на олію або натуральний каучук, машини для виготовлення коліс і майстри, доступні для виробництва. Коротко кажучи: світова економіка.

Як це переходить у світ програмного забезпечення? Ну,

• може бути веб-сервер, але, на жаль, це написано на PHP. Ви вважаєте за краще мати його мовою, якою ви добре володієте
• алгоритм сортування може бути великим для 10 елементів, але не масштабує до 1T елементів
• вам може знадобитися рішення, яке генерується самою другою програмою
• точність - це найчастіше цифрове запитання в області програмного забезпечення, якщо алгоритм сортує список, він сортується - не в основному сортується. Але крім продуктивності, розмір коду, використання пам'яті або інші обмеження можуть статися
• Думаю, патенти не потребують додаткових пояснень.
• Зовнішній вигляд - це постійна причина для чогось винаходити - подумайте dropDownList (ComboBox).
• Світова економічна ситуація може вплинути на ваше програмне забезпечення: чи це буде хмарне колесо, колесо з відкритим кодом, колесо браузера або колесо додатка?
• І звичайно найвідоміша причина побудувати власне колесо: ти любиш це вчитися.

Я новоосвічений студент. У школі ми «навчалися» asp.net та C #; ті 2 роки навчання проходили, ми ніколи не намагалися створити власну систему електронної пошти, систему входу чи CMS. .

Ми почали 102 учня, 23 закінчили. 4 людини мають роботу. Причина ?: Ці 4 людини (включаючи мене) знали, як програмувати, перш ніж ми насправді розпочали навчання.

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

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

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

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

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

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

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

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

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

1. Ви або розумієте, чому все так, як вони є.
2. Ви можете оптимізувати його та покращити його
3. Ви можете зкрутити це і навчитися не робити цього.

Для мене студент не повинен винаходити колесо, а намагатися змінити його інженер і зрозуміти наслідки.

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

Склади, купи, пов'язані списки, дерева тощо, безумовно, варті вкладень вчасно, щоб реалізувати один раз; потім після використання тих, що передбачені рамкою. Кожен, хто використовує плагін jQuery, повинен написати хоча б один, але вам не потрібно писати будь-який інший тип, який ви коли-небудь використовуватимете. Я б сказав, що корисно, але не обов’язково написати невеликий планувальник процесів або міні-ОС, щоб ви могли зрозуміти, що відбувається під кришкою на комп'ютері. Вам НЕ потрібно розуміти, як працюють процеси, потоки тощо.

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

Відповідь залежить від того, чи бажаєте ви вчитися чи творити.

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

Але якщо мета створення складного продукту, то "винахід колеса" може бути трудомісткою практикою і мало допоможе створити продукт.

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

Щодо цього є два аспекти.

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

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

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

Я зіткнувся з тією ж ситуацією. Це через різницю у сприйнятті в галузі та вчених.

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

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

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

Hacker Жаргон Lexikon має дуже хороший коментар на винаходити колесо :

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

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

Відповідь A: Винайдіть колесо. Це поглиблює ваше розуміння структур даних та алгоритмів і робить НІЧОГО більш імовірним, що ви будете писати хороші речі. Я впевнений, що коли Гвідо ван Россум стартував на Python, люди казали йому не винаходити колесо. Мов уже було багато. Навіщо писати в Google, коли вже був Yahoo! Як щодо кланг? Дізнайтеся все це. Будь велетнем. Не дозволяйте маленьким людям обмежувати вас. Відповідь B: Якщо інструктор підкаже вам, що робити, дайте йому те, що він хоче, або просто трохи більше, навіть якщо це здасться дурним. Якщо ви хочете ТАКОЖ зійти з розуму, прийнявши дивовижне рішення і дайте йому посилання на це, продовжуйте. По-перше, виконайте вимоги, викладені так, як вони задані таким чином, він задоволений.

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

Робіть те, що просить вас зробити завдання / питання / іспит.

Роки тому я був ТА для класу програмування на С. Екзаменаційне запитання було "Написати програму для копіювання файлу". Кілька студентів задавали один і той же тип запитання - чи можуть вони породити процес і запустити команду OS cp?

Ми відповіли їм: "Чи буде ваша програма копіювати файл?"

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

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

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