Pull to refresh

Comments 86

Это скорее относится к философии, нежели к процессу написания кода. Такой подход стоит использовать для понимания (как — "… для того, чтобы лучше почувствовать — как это, написать великую книгу..."). Для написания кода, создания приложения такой способ врядли подойдет.
А для обучения? Не лучше ли так, чем просто ЧИТАЯ мануалы и туториалы?
По личному опыту, 70% (!) любого кода взятого из туториалов/учебников не работает. Потому что опущены мелкие детали как его заставить работать.
Опять же потому что обычно код пишется «чтобы работал», а не «чтобы его можно было вытащить и переиспользовать».
Эээ, не совсем понятно. Как код можно переиспользовать, но чтоб он не работал?
Элементарно, Watson. Достаточно не учесть какой-нибудь косвенный эффект, который создает этот код, или наоборот, используется этим кодом.
UFO just landed and posted this here
Чем больше отделов мозга задействовано при обучении, тем лучше запоминается.
Когда интернета еще не было, а код приходилось ручками набирать с книжек, то я тоже обнаружил этот странный эффект. Да, код понимаешь, вник в него, знаешь, как все работает. Но при наборе происходит что-то сродни с откровением. Как бы открываешь какие-то неведомые горизонты. Вам надо действительно попробовать, чтобы понять это. Невозможно словами передать.
Мне кажется, что это действительно связано с тем, что информация проходит через разные отделы мозга, в наборе участвует отдел мозга отвечающий за моторику. Следовательно информация получает больше связей.
Точно подмечено. Это, наверно, и к журналистике относится — раньше текст приходилось перебивать, переписывать, перефразировать.
К слову — подтверждаю. И работает не только для кода. Я до сих пор при подготовке/изучении чего-то сажусь и пишу (или набираю) аналог университетских «шпор». Удивительно, насколько потом лучше вспоминается написанное и сколько всего понимаешь во время написания.
UFO just landed and posted this here
Никто не говорит о бездумном перепечатывании. Даже когда я печатаю параметры, которые передаю в функцию, мое внимание лучом следит за этим кодом, я гораздо больше обращаю внимание на этот параметр, а если бы читал по диагонали код, то мог бы подумать «а, ну это понятно», хотя на самом деле мне могло бы показаться, что мне было понятно.
В двух словах — при печатании кода, его «покрытие вниманием» составляет 100%.
За тем, что через годы такой механический работы, закодить 5-6 строк кода не задумываясь в разы эффективнее и быстрее, чем гуглить чужие, не всегда эффективные, решения. Копипаста развивает способность копипастить, а не думать.
Иногда перепечатываю нужный мне код, чтобы лучше понять и потренировать пальцы, а то от копипасты вообще разучишься быстро печатать.
перепишите на днях библиотечку на 10к строк перед тем как заюзать
библиотечка, это одно, а создание проекта — другое.
Библиотеки, такие как jquery, специально создавались что бы ты их взял и использовал их функционал, а вот когда ты пишешь плагин/модуль/дополнение с использованием этот библиотеки, нужно не примеры из документации копипастить, а самому думать и набирать, иначе сам себе начинаешь задавать вопрос: «А как оно вообще работает? Оно же не должно работать :)»
У меня есть внутреннее ограничение на copy-paste: копируй не больше одного блока размером не более 10-20 строк, отрефактори его, интегрируй, а потом уже продолжай дальше.
Кстати, советую при копировании пересмотреть и, по возможности, переименовать все переменные под свой контекст. Тоже помогает в осмыслении, и при этом не нужно механически копировать.
Между прочим, плохим ученикам рекомендуют переписывать «Войну и Мир». Конечно, всю книжку вряд ли кто осилит таким способом. Но пока перепишешь пару глав, то научишься делать это быстро, что пригодится во всяких институтах и действительно запомнишь кое-что из русского языка.
Я в свое время переписывал книги на английском, что пригодилось во взрослой жизни, когда потребовалось писать быстро.
войну и мир? кое-что из русского? очень интересно…
Ещё помогает переписать какойнибудь движок на фреймворк)
Ну не надо утрировать, хорошо? :)
Лучше DSL на framework'е :-) Чтобы еще и фантазию развивать :-)
Я такое практиковал — помогает.
У меня был более интересный опыт — я учился писать готовое решение за 1 день. Фактически это выглядело так: определяю, что нужно сделать; сажусь за комп, начинаю писать код — и до вечера. Если не успел доделать планируемое — то полный shift+delete и на следующий день начинаю все с начала с самого нуля. Вот это реально помогает :)
Главное не ставить себе непосильных задач с такими опытами, а то ваш «день сурка» может растянутся.
Сам так делаю обычно :) Это как с конспектами — когда их пишешь, ты и запоминаешь лучше и в голове больше понимания, чем просто прочитав.
Это типа «шпаргалки писать можно и нужно, но пользоваться ими нельзя»? :)
Это даже лучше :) Часто пишешь немного по-другому, а иногда вообще совсем по-другому :) Т.е. основную идею понял, а в коде уже реализуешь это по своему, например более соответствующе стилю кодирования.
У меня — наоборот. Когда пишу конспекты еле поспевая за докладчиком, то ничего не понимаю, не запоминаю, только записываю.
Понимание приходит только при чтении конспектов. Или книги по теме. Или решении задач.
Как раз изучаю программирование, пришел у такому же выводу, хотел попробовать.
Так же было и с Linux. Чем просто вводить простыню из комманд, вводил их вручную. Помогло понять что к чему.
UFO just landed and posted this here
Обеими руками поддерживаю. Стараюсь тот же подход применять к найденным на просторах сети костылям и workaround-ам… иногда после такого, внезапно осознаешь что они не нужны. (навеяно сборкой тулчейна)
В более узлом варианте получим давно известное суждение: учись на чужих ошибках :-)
Я не буду говорить за других — скажу за себя.

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

Я примерно так же учил Backbone.js — брал готовый код и перепечатывал. Потом адаптировал под свой проект и т.п.

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

Я так себя приучил в JSON писать не:
{
    name1: value1,
    indexMapIndustrialKavabunga: value2,
    x:y
}

а,

{
     name1                        : value1
,    indexMapIndustrialKavabunga  : value2
,    x                            : y
}

Ну в общем может поздно слишком и я не прав и вообще хвастаюсь: Р
Если IDE не поддерживает такое позиционирование автоматом — здравствуй, ужас, как только начнется рефакторинг…
Ну помещать запятую в начало следующей строки — это рационально, но в саму первую позицию, перед табуляциями…
Имхо, проблема с запятыми в JSON не стоит того, чтобы так уродовать код.
Мне кажется суть этого метода в том, что у многих людей не развито параллельное мышление вообще (а то вообще очень-очень медленное), а процесс написания кода так или иначе растягивает время и способствуют вниканию в код.
Отчасти да. При написании чего-либо (вообще любой физический труд) задействуется лобная часть головного мозга, которая отвечает за стратегию и планирование. Если просто вникать в код, то лобная часть мало участвует. Для наглядности, можно привести хороший пример. Одно дело думать о том, что надо перетащить пару ящиков, а другое дело начать их перетаскивать. Очень скоро вас посетит мысль: «А может использовать какой-нибудь механизм для погрузки ящиков?». И чтобы понять какой нужно использовать механизм, первым делом обратишь внимание на устройство ящиков.
Интересно… планирование лучше включается в процессе совершения физического труда?
Стараюсь перепечатывать или хотя бы сильно рефакторить, одна из причин: когда глазами код читаешь, многое может ускользнуть от понимания. Может этот код на так хорош для моей задачи, а пока я его перепечатываю, успеваю продумать, так оно или нет, будут ли какие граничные случаи — в общем как будто на ходу его придумываю. Ну и вникать все равно кажется дольше, чем перепечатывать и параллельно вникать.
Плюс скопированный код своим не ощущается, если баги оттуда полезут — будет сложнее разобраться (да и додуматься что они именно там, тоже сложнее — нет памяти о нем).
То, что я про рефакторинг написал, имеет смысл если кода уж очень много — тогда просто изменение его под себя уже делает более-менее своим, знакомым и понятным.
М.б. это полезно только определённой группе людей, которые пока не потрогают — не поверят/не поймут?

По мне как-то обычно вполне понятно что делает тот или иной кусок кода. Если кусок тебе не понятен, то смысл его печатать?

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

А если глянуть цифры?
Для того, чтобы понять таким образом хотя бы один фреймворк (пусь будет зенд форм пхп), нам потребуется буквально шесть с половиной веков — там ведь всего чуть больше двух миллионов строк.

см. www.ohloh.net/p/zend_framework

Афтар, пеши ищо :)
300 символов в секунду
допустим в строке в среднем 30 символов
10 строк в минуту
итого 138 полных дня или ~год если считать только по 8 часов.

Дело не в понимании чужого кода при перепечатывании. Дело в понимании применяемого чужого кода у себя.

Сам вообще никогда не копипасчу не то что чужой, но и свой собственный код между проектами практически никогда. Исключения есть, но они относительно редки. Не советую сие правда тем, кто не надр**чился печатать код быстрее чем обычный литературный текст) У меня в порывах вообще иногда 400+ символов в минуту полючается (включая знаки).

Не думал, что кто-то делает так же как я, ибо вокруг меня кто работает — все сначала удивлялись моему подходу, но эффект заметили тоже и теперь молчат =).
Довольно странный совет.
Это равносильно изобретению велосипеда. Зачем терять время на набор уже готового плагина? Лучше потратить его на другую подзадачу.
Книга «Learn Python the Hard Way» на этом основана. Отличный подход, мне кажется, хоть и довольно муторный поначалу.
UFO just landed and posted this here
Вот я т дожил до того момента как софт. инженеры с серьезным видом обсуждают что у них отсутсвуют навыки набора кода… не думал что буду этому свидетелем.
UFO just landed and posted this here
Мой комментарий не об этом, а о том что стало намного проще скопировать и поправить код только обладая поверхностным пониманием и это глобальная тенденция в индустрии, эта проблема когда то была маленькой:
«зачем мне понимать как работает железо, есть же работающая абстракция»,
потом была подростком:
«зачем мне понимать как работает внутри API, моя кнопка работает»
и вот теперь зрелость:
«посмотрю исходный код этой страницы и скопирую с мин. правкой, не стоит забивать голову анализом»
Страшно от того какова эта проблема будет в старости.
Сказали — при звонке нажми красную кнопку, так и сделаю, нафиг мне разбираться, что потом будет.
Примерно так.
Энергетически очень выгодное поведение, думать очень дорого с точки зрения калорий :-) Сколько раз наблюдал — если в группе людей есть хоть один активный и сообразительный то остальные члены группы моментально мыслительные и процессы принятия решений делегируют ему/ей, а сами пребывают очень расслабленными экономя драгоценную энергию.

«Экономя» таким образом можно запросто стать простой шестеренкой.
Быть шестеренкой это плохо?
Намного хуже когда «начальниками» хотят стать ради статуса не обладая нужными качествами, Юнец еще собой не научился управлять, а уже хочет управлять другими :-)
Общество больно когда успех измеряется кол-вом людей в подчинении, толковый инженер никогда не станет профессионалом так как «выбьется» в начальники и руководитель скорее всего из него будет посредственный в силу возраста, гармонов и дури в голове. В результате развал на всех уровнях индустрии, вирусные идеи убивают общество эффективней атомной бомбы.
Как-то я сдавал перепечатанную своим «почерком» курсовую. Алгоритм стал понятен, а теория — не особо. Но преподаватель в моём коде не узнал списанной работы, похвалил меня за самостоятельность, задал пару простых вопросов и всё зачёл.
Думать больше надо.
1) Ставишь цель (в процессе изучения она всегда должна быть выше твоих возможностей)
2) Думаешь как этого достичь
3) Ищешь информацию, читаешь мануалы и.т.п
4) Вновь думаешь
5) Пишешь код
6) Удаляешь это месиво
7) Снова думаешь
8) Пишешь
9) При необходимости возвращаемся к п.7
10) И ты понимаешь, почему именно так. Цель достигнута
11)…
12) Пьем чай с печеньками, можно запускать по новой
UFO just landed and posted this here
метод хороший,
чужой код никогда не подходит asis, всегда надо адаптировать под проект,
а значит разобрать по винтикам и собрать обратно выкинув ненужное и добавив нужное — самый быстрый способ принять на поддержку чужое поделие
альтернатива — править незнамо как работающий код по-живому
Ну так да. Сам же перепечатывал HSL, HSV, XYZ, Lab когда-то.

Ещё круче — это взять работающий код, посмотреть что он делает и написать аналог. Я когда-то написал аналог jQuery (с блекджеком и классами), изредка подсматривая в код самого jQuery, Mootools и Prototype.
По-моему, тогда я и вышел из стадии новичка.
Часто пользуюсь этим методом когда учу новый зык программирования или постигаю новые «приемы».
Бывает страшно скопипастить чужой фрагмент. При постепенном пропускании через себя сразу же вникаю, для меня это проще чем глядеть сразу на готовый кусок.
Опыта аж 500 дней. А скольких еще чудных открытиях упомянете…
У меня опыта больше. Иногда возникает вопрос — почему я должен их читать? Только потому, что они иностранцы и пишут по-английски, а я принадлежу к «некошерной» и «отсталой», по ихним меркам, нации? Троллинг какой-то получается…
5 лет назад хотел научиться писать игры на flash. Будучи мало знакомым с серьёзными языками, заставлял себя вручную переписывать туториалы и учебные игрушки на action script.
Удивительно, но как сильно это спустя пару лет, помогло читать и править чужой java код!
— Мои собственные стихи такие скверные, — волнуясь, произнесла она. — Вот я и переписываю ее сочинения, чтобы научиться.
— Переписываете кого? — сорвалось у меня.
— Превосходный способ учиться.
— Правда, в самом деле? — Она пристально поглядела на Чарли, проверяя, не шутит ли он. — Ваши слова для меня очень много значат, мистер Диккенс. — Она зарделась. — Я прочла все ваши книги.
— Все? — Он попятился.
— Все те, — поспешно продолжала она, — которые вы до сих пор издали, сэр.
Да действительно, перепечатывать код найденного рабочего решения нужно и это очень помогает, повторюсь еще раз — рабочего решения! Если начать перепечатывать каждый первый попавшийся костыль с размером даже пускай — пару/сотню строк, который потом окажется нерабочим — это очень обидно. И кпд от таких действий нулевой.
Давным-давно был у меня компьютер 286-ой, но электричества было не очень… 2 часа в день. То есть у меня было ровно два часа, чтобы набрать код и запустить, и он должен быть безупречным, поэтому все остальное время, я писал код на бумажке, в голове прогонял его и дебажил, потом брал клавиатуру и тренировался быстро вводить текст.
Суровые времена, конечно, но наверное это было полезно
У меня был спектрум в котором невероятно грелся блок питания, и его нужно было отключать регулярно. А чтоб попрограммировать подольше я замараживал в морозилке металические такие болванки которые клал на трансформатор блока питания. Атас времена были, зато я мог еще посидеть перед чб телеком и пописать чтото.
У нас в те самые времена все было с точностью до наоборот:
Когда включали электричество, мы клали в электрическую духовку кирпичи и врубали ее на полную. Перед сном берешь теплый кирпич, обматываешь его полотенцем, обнимаешь его и заныриваешь под одеало. В спальне было минус 15 градусов, так как ни отопления ни газа не было, и без кирпича вообще не вариант :)
В спальне минус 15? А в ней в окнах стёкла вообще были? Сколько же на улице тогда было?..
Для эффективного использования данного метода необходимо два монитора. (с)
Очень хорошо работает способ — сначала copy & paste, а затем пройтись по коду и откомментировать его до полного понимания.
Лучше писать так, чтобы отпала необходимость в комментариях :-)
В 99% случаев это возможно.
Писать руками очень важно. Когда то я очень увлекался 3D графикой, покупал книги, там примеры, читал и делал по примерам, «нажмите там, ввидите 35 — рендер» и потом у меня стало чтото получаться в финале но я нифига не понимал как именно. И я перестал читать такие книги, потому что они не учили тебя, а говорили как сделать.

Так само когда я отрекся от графики в пользу программирования я чуть не книги переписывал. У меня была книга по MySQL на 350 страниц, я перечитал ее от корки до корки два раза и ничего не понял. В голове у меня просто закипало, и тогда прям поверх листинга я начинал писать карандашом «Выбрать все, из таблицы такой то, где Имя = Вася», и именно это начало давать мне понимание происходящих процессов. Сейчас конечно это все очень примитивно кажется, но тогда для меня это стало прорывом. Так-же я помню мой первый разбор исходников кода одного редактора. Я глядел на это и понимал что никогда не пойму что думал тот кто написал это. Но после не только понял его и переписал все с нуля.
Кто-то должен был вспомнить это:
В отчаянии и меланхолии я понес какую-то околесицу насчет самообучающихся машин. Он слушал, раскрыв рот, и впитывал каждый звук – по-моему, он запоминал эту околесицу дословно. Затем меня осенило. Как опытный провокатор, я спросил, достаточно ли сложной машиной является его агрегат. Он немедленно и страстно заверил меня, что агрегат невообразимо сложен, что иногда он, Эдельвейс, даже сам не понимает, что там где и к чему. Прекрасно, сказал я. Хорошо известно, что всякая достаточно сложная электронная машина обладает способностью к самообучению и самовоспроизводству. Самовоспроизводство нам сейчас пока не нужно, а вот обучить эвристический агрегат Бабкина… тьфу… Машкина печатать тексты самостоятельно, без человека-посредника, мы обязаны в самые короткие сроки. Как это сделать? Мы применим хорошо известный и многократно испытанный метод длительной тренировки.

Преимущество этого метода в простоте. Берется достаточно обширный текст, скажем, «Жизнь животных» Брема в пяти томах. Машкин садится за свой агрегат и начинает печатать слово за словом, строчку за строчкой, страницу за страницей. При этом анализатор агрегата будет анализировать, думатель… – у ей внутре ведь есть, кажется, думатель? –… думатель будет думать, и таким образом агрегат станет у вас обучаться. Вы и ахнуть не успеете, как он у вас начнет сам печатать. Вот вам рубль подъемных, и ступайте в библиотеку за Бремом...
Перепечатывание — хорошо. А можно ещё брать и реализовывать старые задачи заново.
Тут отсутствует нудный момент перепечатывания. Зато открываются новые пути в реализации.
Кто нибудь помнит школьную пропись? Зачем писать одну и ту же буковку 100 раз? А для того чтобы потом на «реализацию» это буковки ушло в 10 раз меньше времени и конечный «интерфейс» был более дружелюбным =)
По первости прочитал заголовок как «не надо копирастить чужой код....».
Есть аналогичное упражнение для писателей. Брать какого-то известного автора и перепечатывать две-три страницы его текста. Следующим этапом, начинаешь писать свой текст (можно прямо на ходу выдумывать), но подражая тому же стилю, который только что перепечатывал. Так нарабатываются навыки писать в разном стиле.
Дело в том, что когда читаешь, легко пропускать целые куски текста. А когда перепечатываешь, приходится обращать внимание на каждое слово и знак препинания — успеваешь подумать, почему написано так, а не иначе, подмечаешь приёмы, словесные обороты, которые при чтении просто игнорируются, преобразуясь в голове в привычную структуру, в которой нет места новым подходам.
Sign up to leave a comment.

Articles