Комментарии 88
Отсчёт начинается с нуляВы пропустили факт 0.
Вот об этом состоянии «потока» говорю сразу всем близким и тем, кто бывает рядом. Думаю, меня все понимают, какое это захватывающее чувство :)
Но при этом многие товарищи, в том числе тот же Макконнел, Роберт Мартин советуют не «увлекаться потоковым программированием». Причина этому проста — в состоянии потока как и в любой эйфории есть отвлечение от реальности, когда мы можем упустить самые базовые вещи по причине того что они нам кажутся слишком очевидными.
По-моему, все программирование и есть отвлечение от реальности в абстракции, причем в пограничной к психиатрии границе. Иначе, выражение 2×a превращается в «вот из одного яблока выросло два».
Дело не столько в том, что мы можем что-то упустить, сколько в том, что код будет написан человеком, который держит в голове огромное количество контекста, которого не будет у того, кто будет потом читать код. А если в состояние потока не входить, то контекст придётся сохранять в понятной структуре кода и именах переменных.
В любом случае, у того, кто читает код, есть гигантское преимущество перед тем, кто этот код пишет — он видит сам написанный код. А это снижает необходимый для понимания объём контекста на несколько порядков: посмотреть, что делает этот метод, гораздо проще, чем вспомнить, какой метод это делает, а при необходимости написать его.
Если код написан понятно, то так и есть. Но код, написанный в потоке зачастую не разбит на методы, потому что пишущему это кажется ненужным — ведь ему и так всё понятно. А названия тех методов, которые в код всё-таки попали могут что-то сказать только тому, кто этот код писал. Да и то, если с момента написания прошло не больше суток.
Он не разбит на методы не потому, что это кажется ненужным, а потому, что это дополнительная работа: точно определить границы метода, решить, как в него передавать данные и как принимать результаты, да ещё и имя придумать. Держать в голове взаимосвязи и варианты, нужные для реализации алгоритма, и так трудно — а тут ещё отвлекайся из-за того, что в методе получается много строчек? Весь замок разрушится. Вопрос не «нужно — ненужно», а «удастся реализовать или нет».
А насчёт «не больше суток» — всё равно не понимаю, откуда это берётся. Если уметь читать код, то он срока давности не имеет.
А насчёт «не больше суток» — всё равно не понимаю, откуда это берётся. Если уметь читать код, то он срока давности не имеет.
Тут возникает вопрос. Считаете ли вы, что код бывает хорошим и плохим? Что код лучше писать так, чтобы его было удобно читать?
Я вот придерживаюсь именно этой точки зрения. И, соответственно, думаю, что чем лучше код, тем больше срок его давности. А в состоянии потока код обычно получается хорошо понятным только тому, кто его написал и только пока он в этом состоянии потока пребывает.
Я вот придерживаюсь именно этой точки зрения. И, соответственно, думаю, что чем лучше код, тем больше срок его давности. А в состоянии потока код обычно получается хорошо понятным только тому, кто его написал и только пока он в этом состоянии потока пребывает.
Да, бывает лучше или хуже, понятнее или нет. Не уверен, впрочем, что «понятность» — объективное понятие: кому-то удобнее читать код, активно разбавленный комментариями и пустыми строками, кому-то — более плотный. Но приводить код в читаемое состояние имеет смысл уже после выхода из потока (или отдельным сеансом) — когда какой-то код уже написан. А потом ещё потребуется отдельный проход, чтобы задокументировать полученный алгоритм :)
Всё так, но есть 2 момента.
Во-первых если не входить в поток, то более понятный код придётся писать с самого начала. Иначе можно в нём банально запутаться.
А во-вторых то, чем занимается большинство программистов сложно назвать написанием алгоритма. Зачастую это какая-нибудь бизнес логика.
Во-первых если не входить в поток, то более понятный код придётся писать с самого начала. Иначе можно в нём банально запутаться.
А во-вторых то, чем занимается большинство программистов сложно назвать написанием алгоритма. Зачастую это какая-нибудь бизнес логика.
«Понятность» можно сделать объективным если измерять ещё разработчиком со стороны, который не имеет отношение к написанному коду. Для форматирования кода есть свои стандарты, которые можно требовать от участников процесса. И т.д. и т.п.
А касательно времени жизни структуры проекта это уже другой вопрос. Есть люди которые помнят свой код достаточно долго (у меня напарник на работе достал код 3-х годичной давности и смог его поправить, т.к. помнил даже название методов которые делали нужную ему работу). Поэтому это сложный момент, что считать «плохой архитектурой».
Также касательно «сеансов», лучше их избегать вовсе на этапе разработки рабочего кода, в следствии того что разрабатывать будет команда со средним опытом, а не одиночки, как бывает у прототипа. Отсюда следует то что «сеансам» самое место на прототипировании проекта, при проверки смелых идей и новых мыслей.
А касательно времени жизни структуры проекта это уже другой вопрос. Есть люди которые помнят свой код достаточно долго (у меня напарник на работе достал код 3-х годичной давности и смог его поправить, т.к. помнил даже название методов которые делали нужную ему работу). Поэтому это сложный момент, что считать «плохой архитектурой».
Также касательно «сеансов», лучше их избегать вовсе на этапе разработки рабочего кода, в следствии того что разрабатывать будет команда со средним опытом, а не одиночки, как бывает у прототипа. Отсюда следует то что «сеансам» самое место на прототипировании проекта, при проверки смелых идей и новых мыслей.
Я уж не знаю, может сейчас меня тут помидорами закидают, но я давно считаю что лучший код тот который работает. Притом который работает прямо сейчас, а не тот который будет работать всегда. Завтра вообще могут условия изменится на столько что вы половину функционала перелапатите, а написание мегауниверсального каркаса в какой-то момент просто сравнимо с написанием фреймворка. И пока ты будешь все это глобально проектировать, китайцы сделают миллион мутантов на костылях в любой вариации
А разве писать код в одном методе не означает что программист не мыслит на уровне ООП?
Но код, написанный в потоке зачастую не разбит на методы, потому что пишущему это кажется ненужным — ведь ему и так всё понятно
А я люблю в потоке разбивать код на методы и структурировать его.
Очень правильное замечание. Надо потом просматривать, что же напрограммировал в потоке. Иногда удивительные ошибки всплывают.
Есть сильное подозрение, что в психиатрии такое состояние называется гипомания
НЛО прилетело и опубликовало эту надпись здесь
Крик души)
Под капотом самых критичных программ, которые вы используете на ежедневной основе (Mac OS X или Facebook) содержится ужасное количество хаков и костылей, которые с трудом уживаются друг с другом.
За фесбук ничего сказать не могу, а что касается osx, там все вполне ок. По крайней мере в опенсурсной части.
вы так уверены на Mac OS X — последние обновления X-code и выход лопаток (iPhone 6, 6+) явно дает и новых осей явно дает факт что таки костыли и велосипеды…
Че? Там чуть менее, чем полностью GPL библиотеки, которые apple пропатчили под себя, а лицензия не позволяет изменить и спрятать.
Вы яно не владеете вопросом. Там не только утилиты, но и все ядро чуть более чем полностью.
LLVM и вебкит значит тоже пропатчили? :)
LLVM и вебкит значит тоже пропатчили? :)
НЛО прилетело и опубликовало эту надпись здесь
Факт 0.1. Называть Facebook программой весьма спорно
Вы удивитесь, но это все таки программа
>Факт 4
Плюсую. Недавно пришлось столкнуться с задачей вроде «сделай то не знаю что». Большую часть времени на выходных, думал как же это сделать, сам же кодинг занял не так много времени.
Плюсую. Недавно пришлось столкнуться с задачей вроде «сделай то не знаю что». Большую часть времени на выходных, думал как же это сделать, сам же кодинг занял не так много времени.
Ваши слова, да юзерам в уши
25% времени в программировании уходит на размышления о том, что пользователь может сделать не так.по-моему мнению цифра сильно занижена. програмирование — это описание обработки ошибок процентов так на 70-80, а то и больше.
кто сможет объяснить, что хотел сказать афтор этим «отсчет начинается с нуля»?
и главное нахрена это знать юзверю?
И главное, при чем тут производительность?
При том, что если два состояния хранить в одной переменной булевого типа, то на хранение уйдет 1 бит, а если хранить как «1» и «2» — то 2 бита — т.е. увеличение объема обрабатываемых данных в два раза. КМК, автор именно это сказать хотел.
Думаю, что «производительность» относится к старым процессорам, где ещё не было режима адресации вроде [edi+ebx-4]. Тогда для вычисления адреса элемента массива при индексации от 1 требуется на одну команду больше. А на 16-битных процессорах это могло быть существенно, особенно, когда обращений к массиву много.
Простите а тип булево разве не подразумевает два состояния 1 и 0 ??
В статье нигде не сказано, что «эти факты надо знать юзверю»
Да, крайне странный список. Подошел бы скорее какому-нибудь журналу для домохозяек.
"… это не значит, что мы умеем чинить железо" — печален тот программист, который не может починить свою рабочую машину, хотя бы на уровне поиска и замены неисправных компонентов. Так же как и печален, например, врач-онколог, который не умеет оказывать первую помощь. Но это, разумеется, не значит, что он должен бесплатно консультировать всех своих родственников и знакомых и назначать им таблетки от кашля. Собственно, как и программист.
"… это не значит, что мы умеем чинить железо" — печален тот программист, который не может починить свою рабочую машину, хотя бы на уровне поиска и замены неисправных компонентов. Так же как и печален, например, врач-онколог, который не умеет оказывать первую помощь. Но это, разумеется, не значит, что он должен бесплатно консультировать всех своих родственников и знакомых и назначать им таблетки от кашля. Собственно, как и программист.
А я вот не могу починить рабочую машину (Macbook), но легко могу — домашнюю (обычный PC). Слишком уж сложно маки внутри устроены, чтоб лезть своими кривыми руками…
1. А чем мак отличается от PC в плане обычной починки (протереть от пыли, смазать кулер)?
2. На работе за рабочими машинками должен и обязан следить IT отдел, которому за это платят деньги, а вам платят за другое. Был бы у вас домашний макбук, такое как почистить внутри от пыли, думаю научились бы.
P.S. В большинстве сервисов по ремонту, ничего никто не паяет, просто меняют комплектующие. Для мака это должно быть еще проще — спецификация известна, конкретная деталь только одна и все, разве что купить ее гдеугодно нельзя.
Или я неправ? Никогда не менял комплектующие в маке… если кто знает, скажите.
2. На работе за рабочими машинками должен и обязан следить IT отдел, которому за это платят деньги, а вам платят за другое. Был бы у вас домашний макбук, такое как почистить внутри от пыли, думаю научились бы.
P.S. В большинстве сервисов по ремонту, ничего никто не паяет, просто меняют комплектующие. Для мака это должно быть еще проще — спецификация известна, конкретная деталь только одна и все, разве что купить ее гдеугодно нельзя.
Или я неправ? Никогда не менял комплектующие в маке… если кто знает, скажите.
Патамушта — book.
Ровно то же самое произойдёт с любым другим буком, за исключением тех ситуаций, что чипы менять на PC буках проще, хотя бы в силу распространённости, да и схемы найти легче (хоть и не всегда).
Ровно то же самое произойдёт с любым другим буком, за исключением тех ситуаций, что чипы менять на PC буках проще, хотя бы в силу распространённости, да и схемы найти легче (хоть и не всегда).
Для макбуков, выпущенных ранее 12 года, все очень просто, если есть мануал (а их полно в сети, например на ifixit.com). А так все те же запчасти на него идут, и память, и накопители. Но после ретины начался кошмар: батарея, залитая эпоксидкой, память, припаянная к материнке… Никаких тебе апгрейдов своими руками. Такие вот дела. Мне почему-то кажется, что подобное вымогательство плохо кончится для самих вымогателей.
Возможно, это сделано в погоне за толщиной? Хотя, честно признаться, не понимаю зачем приклеивать к матери память…
За толщиной вашего бумажника, вы имеете в виду? Тогда, наверное, да. Приклеивают затем, чтобы вы купили эту память у них, по их цене. И если купленная конфигурация оказалась слабовата, чтобы не экономили на апгрейдах, а шли к ним же за новой машиной. Очень все прозрачно.
Кроме финансовой составляющей есть ещё и практическая: склеенный корпус крепче скрученного винтами, распаянная память весит и занимает места меньше вставленной в разъём.
Пользователям же подавай полегче и потоньше, но и чтобы корпус не скручивался и не скрипел.
Пользователям же подавай полегче и потоньше, но и чтобы корпус не скручивался и не скрипел.
У этих макбуков корпус точно такой же дюралевый скрученный винтами, как и в моделях 2008—2011 года (только головки винтов другие). Пустого места в их корпусе даже сейчас достаточно, чтобы там уместились и модули памяти, и еще много чего. Насчет «весит легче» – это вы всерьез говорите о 10 граммах, которые весит разъем и два кусочка текстолита без микросхем? Но тот компаунд, которым они залили батарею, весит в несколько раз больше, можно было бы на нем сэкономить, если бы речь шла о практической пользе. Потом, та же запаянная память стоит в современных MacMini, а уж там выгадывать 10 граммов веса совсм бессмысленно.
Ему не надо туда лезть. Это непродуктивно. Зачем тратить время узкого специалиста на то, что может решить хелпдеск?
Отсчёт начинается с нуля
Э-э-э, простите, а почему ваши факты в этой статье начинаются с 1?
Какой-то нелепый набор фактов и заблуждений, собранный домохозяйкой. Зачем это здесь?
Факт 7.
По-русски всё-таки о задаче говорят «переспать с ней».
По-русски всё-таки о задаче говорят «переспать с ней».
Весна…
Почему сразу весна? Это довольно старый и устойчивый фразеологизм, а «поспать» мне до сих пор не доводилось слышать. Кроме того, с понятием я столкнулся намного раньше, чем услышал слово: бывает, если долго возишься с какой-то неподдающейся проблемой, основательно загрузишься ей, то есть шанс, что с утра осенит внезапной идеей, которая может сработать. Причем это не обязательно связано с программированием, чаще с математикой. У меня впервые это случилось в детстве с нестандартной шахматной задачей, я тогда очень удивился.
Утро вечера мудренее.
Иногда полезно отложить проблему до утра
но после всего лишь 20-минутного снаДа, очень часто до утра остаётся 20 минут…
Последний пункт просто прекрасен! И он касается не только программирования. Оказывается не я один такой…
Дам прочесть родителям!
Отсчёт начинается с нуля
Можно такой «отсчёт» назвать сдвигом и жизнь чуточку упростится.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
9 фактов, которые знают программисты, и не знают все остальные