Редактор Хабрахабра
2,0
рейтинг
8 марта 2015 в 20:06

Разработка → 9 фактов, которые знают программисты, и не знают все остальные перевод

image

Факт 1


Под капотом самых критичных программ, которые вы используете на ежедневной основе (Mac OS X или Facebook) содержится ужасное количество хаков и костылей, которые с трудом уживаются друг с другом. Это как если бы вы разобрали боинг 747 и увидели, что топливопровод держится вешалкой для одежды, а шасси смотаны изолентой.

Бен Черри

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

Факт 2


25% времени в программировании уходит на размышления о том, что пользователь может сделать не так.

Брайан Хьюмс

Занимает это на деле больше или меньше процентов времени, но каждый раз нам действительно необходимо подумать – а что пользователь может тут сломать. Куда нажмёт, что введёт, и как можно понять то, что мы пытаемся сделать, неправильно. Если бы мы рассчитывали только на себя, у программ было бы слишком много проблем – ведь мы знаем, как программа работает, а пользователь не знает.

Факт 3


Программист – это не специалист по ремонту компьютеров

Ритеш Кумар Гупта

Программист работает с алгоритмами и принципами разработки, а не чинит компьютеры. Мы можем понимать, как компьютер работает и как исполняется код. Но это не значит, что мы умеем чинить железо. Мы не знаем, какая проблема в Chrome роняет его на вашем компьютере, или почему ваш компьютер перегревается. Программисты программируют компьютеры, а не чинят их.

Факт 4


Программирование – это размышление, а не печатание

Кейси Патон

По большей части мы программируем, когда спим, гуляем, смотрим в окно, или делаем что-то ещё, что позволяет нам расслабиться и думать. Расслабление – один из важных аспектов программирования. Нельзя просто сесть и написать тысячу строк кода и вставить их в программу. Нам необходимо посидеть, походить, подумать. Придумать концепцию, исправить её недостатки, решить, как она будет работать… Расслабление – единственный способ, которым мы можем пользоваться для исправления проблем.

Факт 5


Отсчёт начинается с нуля


Это важно. Подсчёт идёт с нуля – ваш 1 это мой 0, ваш 10 это мой 9. Всё из-за необходимости делать вещи эффективно, когда даже небольшая прибавка к эффективности может в масштабе увеличить производительность.

Факт 6


Программировать лучше всего в потоке – в таком состоянии сознания, когда вы сфокусированы на задаче и всё кажется простым. Это состояние знакомо также атлетам и музыкантам.

Морган Йохансон

Программисты любят работать по ночам потому, что это позволяет нам входить поток, сфокусироваться на чём-то одном и не волноваться о том, что нас могут отвлечь. Все остальные просто спят. Это такое время дня, когда никого нет рядом, никто не звонит и не пытается с нами поговорить. Прекрасное время, чтобы думать и программировать.

Факт 7


Иногда полезно отложить проблему до утра


Иногда программистам действительно полезно, встретив сложную задачу, поспать «с ней». Множество раз я встречался с тем, что мне часами не удавалось решить что-то, но после всего лишь 20-минутного сна (или любого другого сна) по пробуждению решение приходило само.

Факт 8


«Родитель» может убить своих «детей», если их задача выполнена


Не та фраза, которую бы хотелось услышать от кого-либо. Но для программистов она звучит не так страшно. Программы часто имеют иерархическую структуру, где родительский процесс контролирует его дочерние процессы, запущенные на уровне ниже.
Когда родительскому процессу больше не нужен дочерний, он его убивает – когда программе больше ничего не надо делать, её выполнение заканчивают.

Факт 9


Вы не впечатляетесь тем, как много мы знаем о компьютерах. Мы не впечатляемся тем, как мало вы знаете о них.


Серьёзно. Хватит уже. Нам неважно, как вы горды тем, что не желаете обучаться новым вещам. Понятно, если вы говорите «я мало знаю о компьютерах» или «мне не интересно программировать» — но когда вы хвалитесь тем, как много вы об этом не знаете, это просто раздражает.
Перевод: Macleod Sawyer
Вячеслав Голованов @SLY_G
карма
248,2
рейтинг 2,0
Редактор Хабрахабра
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (85)

  • +303
    Отсчёт начинается с нуля
    Вы пропустили факт 0.
    • 0
      Спасибо, не пришлось проверять самому.
    • +85
      Факт 0
      Эта статья должна быть на Гик, мать его, Таймс.

      Кто-то должен был это сказать.
      • +26
        На мегамозге. Ну или на пикабу.
        • +19
          на kolyan.net, блин.
          • +3
            В паблике в VK картинками и с подписью «Омар Хайям»
    • НЛО прилетело и опубликовало эту надпись здесь
  • +8
    Вот об этом состоянии «потока» говорю сразу всем близким и тем, кто бывает рядом. Думаю, меня все понимают, какое это захватывающее чувство :)
    • +11
      Но при этом многие товарищи, в том числе тот же Макконнел, Роберт Мартин советуют не «увлекаться потоковым программированием». Причина этому проста — в состоянии потока как и в любой эйфории есть отвлечение от реальности, когда мы можем упустить самые базовые вещи по причине того что они нам кажутся слишком очевидными.
      • +9
        По-моему, все программирование и есть отвлечение от реальности в абстракции, причем в пограничной к психиатрии границе. Иначе, выражение 2×a превращается в «вот из одного яблока выросло два».
        • 0
          Конечно, т.к. достаточно почитать Буча — там таких примеров навалом. Главное не забывать что реально, а что нет. Т.к ход мыслей бывает сложно остановить. Вообще это черта любой профессии в которой есть творческий контекст и требуется абстракция над текущим процессом.
      • +9
        Дело не столько в том, что мы можем что-то упустить, сколько в том, что код будет написан человеком, который держит в голове огромное количество контекста, которого не будет у того, кто будет потом читать код. А если в состояние потока не входить, то контекст придётся сохранять в понятной структуре кода и именах переменных.
        • +1
          В любом случае, у того, кто читает код, есть гигантское преимущество перед тем, кто этот код пишет — он видит сам написанный код. А это снижает необходимый для понимания объём контекста на несколько порядков: посмотреть, что делает этот метод, гораздо проще, чем вспомнить, какой метод это делает, а при необходимости написать его.
          • +1
            Если код написан понятно, то так и есть. Но код, написанный в потоке зачастую не разбит на методы, потому что пишущему это кажется ненужным — ведь ему и так всё понятно. А названия тех методов, которые в код всё-таки попали могут что-то сказать только тому, кто этот код писал. Да и то, если с момента написания прошло не больше суток.
            • 0
              Он не разбит на методы не потому, что это кажется ненужным, а потому, что это дополнительная работа: точно определить границы метода, решить, как в него передавать данные и как принимать результаты, да ещё и имя придумать. Держать в голове взаимосвязи и варианты, нужные для реализации алгоритма, и так трудно — а тут ещё отвлекайся из-за того, что в методе получается много строчек? Весь замок разрушится. Вопрос не «нужно — ненужно», а «удастся реализовать или нет».
              А насчёт «не больше суток» — всё равно не понимаю, откуда это берётся. Если уметь читать код, то он срока давности не имеет.
              • +2
                Тут возникает вопрос. Считаете ли вы, что код бывает хорошим и плохим? Что код лучше писать так, чтобы его было удобно читать?
                Я вот придерживаюсь именно этой точки зрения. И, соответственно, думаю, что чем лучше код, тем больше срок его давности. А в состоянии потока код обычно получается хорошо понятным только тому, кто его написал и только пока он в этом состоянии потока пребывает.
                • 0
                  Да, бывает лучше или хуже, понятнее или нет. Не уверен, впрочем, что «понятность» — объективное понятие: кому-то удобнее читать код, активно разбавленный комментариями и пустыми строками, кому-то — более плотный. Но приводить код в читаемое состояние имеет смысл уже после выхода из потока (или отдельным сеансом) — когда какой-то код уже написан. А потом ещё потребуется отдельный проход, чтобы задокументировать полученный алгоритм :)
                  • –2
                    Всё так, но есть 2 момента.
                    Во-первых если не входить в поток, то более понятный код придётся писать с самого начала. Иначе можно в нём банально запутаться.
                    А во-вторых то, чем занимается большинство программистов сложно назвать написанием алгоритма. Зачастую это какая-нибудь бизнес логика.
                    • 0
                      Зачастую это алгоритмизация бизнес-логики
                  • +1
                    «Понятность» можно сделать объективным если измерять ещё разработчиком со стороны, который не имеет отношение к написанному коду. Для форматирования кода есть свои стандарты, которые можно требовать от участников процесса. И т.д. и т.п.

                    А касательно времени жизни структуры проекта это уже другой вопрос. Есть люди которые помнят свой код достаточно долго (у меня напарник на работе достал код 3-х годичной давности и смог его поправить, т.к. помнил даже название методов которые делали нужную ему работу). Поэтому это сложный момент, что считать «плохой архитектурой».

                    Также касательно «сеансов», лучше их избегать вовсе на этапе разработки рабочего кода, в следствии того что разрабатывать будет команда со средним опытом, а не одиночки, как бывает у прототипа. Отсюда следует то что «сеансам» самое место на прототипировании проекта, при проверки смелых идей и новых мыслей.
            • +1
              Но код, написанный в потоке зачастую не разбит на методы, потому что пишущему это кажется ненужным — ведь ему и так всё понятно

              А я люблю в потоке разбивать код на методы и структурировать его.
              • +1
                Наверное, это отдельный поток — работа над уже написанным кодом. Тоже приятное занятие.
      • +2
        Очень правильное замечание. Надо потом просматривать, что же напрограммировал в потоке. Иногда удивительные ошибки всплывают.
        • 0
          особенно если этот поток возник ночью и вместе с ним приходило ощущение гениальности.
    • +19
      • 0
        Не будите программиста — он работает!
    • 0
      Есть сильное подозрение, что в психиатрии такое состояние называется гипомания
  • –31
    Факт 10 (для примера)
    Не каждый программист (веб-разработчик) знает, что можно сделать скриншот всей страницы в браузере Firefox с помощью Панели разработки (SHIFT+F2) и вписав туда: screenshot --fullpage --clipboard (или screenshot… c:/screen.png).
    • 0
      Правильнее
      screenshot --fullpage K:\screen2.png
      На системный раздел почему-то не создается…
      • +11
        Не создается потому что в корне C:\ нужны права администратора.
        • –10
          в последней винде, которую я использовал такого не было!
          • +22
            Обновляйтесь, чикага уже немного устарела.
    • +10
      Ну и зря заминусовали — этот комментарий полезнее всей статьи, однако :)
    • –2
      Круто! Не знал, спасибо большое! Раньше с графическими редакторами мучился
  • –3
    Крик души)
  • –19
    Под капотом самых критичных программ, которые вы используете на ежедневной основе (Mac OS X или Facebook) содержится ужасное количество хаков и костылей, которые с трудом уживаются друг с другом.

    За фесбук ничего сказать не могу, а что касается osx, там все вполне ок. По крайней мере в опенсурсной части.
    • 0
      вы так уверены на Mac OS X — последние обновления X-code и выход лопаток (iPhone 6, 6+) явно дает и новых осей явно дает факт что таки костыли и велосипеды…
    • 0
      Че? Там чуть менее, чем полностью GPL библиотеки, которые apple пропатчили под себя, а лицензия не позволяет изменить и спрятать.
      • +3
        Вы яно не владеете вопросом. Там не только утилиты, но и все ядро чуть более чем полностью.

        LLVM и вебкит значит тоже пропатчили? :)
        • +2
          Ну что вы, ведь все знают, что вебкит сделал гугл!
          • 0
            Ну что вы, ведь все знают, что вебкит сделал Ларс Нолл!
            • 0
              Ну если быть уж совсем точным, то KHTML != Webkit. Это как считать, что Netscape Navigator работал на Gecko.
              • 0
                Я согласен, у меня вроде ирония была.
        • 0
          Webkit сделан на основе khtml, так что в каком-то роде да, просто «пропатчили».
          • +2
            «просто». Это как Half-Life — «просто пропатченный» Quake.
            • НЛО прилетело и опубликовало эту надпись здесь
            • +1
              Ага =) А windows98 — «слегка пропатченный DOS».
  • +13
    Факт 0: OS X и Facebook не являются самыми критичными программами.
    • +1
      Факт 0.1. Называть Facebook программой весьма спорно
  • +1
    >Факт 4
    Плюсую. Недавно пришлось столкнуться с задачей вроде «сделай то не знаю что». Большую часть времени на выходных, думал как же это сделать, сам же кодинг занял не так много времени.
  • +1
    Ваши слова, да юзерам в уши
  • 0
    25% времени в программировании уходит на размышления о том, что пользователь может сделать не так.
    по-моему мнению цифра сильно занижена. програмирование — это описание обработки ошибок процентов так на 70-80, а то и больше.
    • 0
      Забыли про поиск ошибок в коде)
  • +5
    кто сможет объяснить, что хотел сказать афтор этим «отсчет начинается с нуля»?
    • +5
      и главное нахрена это знать юзверю?
      • +12
        И главное, при чем тут производительность?
        • –1
          При том, что если два состояния хранить в одной переменной булевого типа, то на хранение уйдет 1 бит, а если хранить как «1» и «2» — то 2 бита — т.е. увеличение объема обрабатываемых данных в два раза. КМК, автор именно это сказать хотел.
          • 0
            Думаю, что «производительность» относится к старым процессорам, где ещё не было режима адресации вроде [edi+ebx-4]. Тогда для вычисления адреса элемента массива при индексации от 1 требуется на одну команду больше. А на 16-битных процессорах это могло быть существенно, особенно, когда обращений к массиву много.
          • 0
            Простите а тип булево разве не подразумевает два состояния 1 и 0 ??
            • 0
              тру и фолс, а как их представлять в памяти — зависит от реализации
      • 0
        В статье нигде не сказано, что «эти факты надо знать юзверю»
  • +10
    Да, крайне странный список. Подошел бы скорее какому-нибудь журналу для домохозяек.
    "… это не значит, что мы умеем чинить железо" — печален тот программист, который не может починить свою рабочую машину, хотя бы на уровне поиска и замены неисправных компонентов. Так же как и печален, например, врач-онколог, который не умеет оказывать первую помощь. Но это, разумеется, не значит, что он должен бесплатно консультировать всех своих родственников и знакомых и назначать им таблетки от кашля. Собственно, как и программист.
    • +3
      А я вот не могу починить рабочую машину (Macbook), но легко могу — домашнюю (обычный PC). Слишком уж сложно маки внутри устроены, чтоб лезть своими кривыми руками…
      • –4
        1. А чем мак отличается от PC в плане обычной починки (протереть от пыли, смазать кулер)?
        2. На работе за рабочими машинками должен и обязан следить IT отдел, которому за это платят деньги, а вам платят за другое. Был бы у вас домашний макбук, такое как почистить внутри от пыли, думаю научились бы.

        P.S. В большинстве сервисов по ремонту, ничего никто не паяет, просто меняют комплектующие. Для мака это должно быть еще проще — спецификация известна, конкретная деталь только одна и все, разве что купить ее гдеугодно нельзя.
        Или я неправ? Никогда не менял комплектующие в маке… если кто знает, скажите.
        • +2
          Кулеры маков, кстати, смазывать нельзя. У них нет механической оси — они висят на магнитной подушке и смазка просто испортит кулер.
      • +1
        Патамушта — book.
        Ровно то же самое произойдёт с любым другим буком, за исключением тех ситуаций, что чипы менять на PC буках проще, хотя бы в силу распространённости, да и схемы найти легче (хоть и не всегда).
      • +1
        Для макбуков, выпущенных ранее 12 года, все очень просто, если есть мануал (а их полно в сети, например на ifixit.com). А так все те же запчасти на него идут, и память, и накопители. Но после ретины начался кошмар: батарея, залитая эпоксидкой, память, припаянная к материнке… Никаких тебе апгрейдов своими руками. Такие вот дела. Мне почему-то кажется, что подобное вымогательство плохо кончится для самих вымогателей.
        • 0
          Возможно, это сделано в погоне за толщиной? Хотя, честно признаться, не понимаю зачем приклеивать к матери память…
          • 0
            За толщиной вашего бумажника, вы имеете в виду? Тогда, наверное, да. Приклеивают затем, чтобы вы купили эту память у них, по их цене. И если купленная конфигурация оказалась слабовата, чтобы не экономили на апгрейдах, а шли к ним же за новой машиной. Очень все прозрачно.
            • 0
              Кроме финансовой составляющей есть ещё и практическая: склеенный корпус крепче скрученного винтами, распаянная память весит и занимает места меньше вставленной в разъём.
              Пользователям же подавай полегче и потоньше, но и чтобы корпус не скручивался и не скрипел.
              • 0
                У этих макбуков корпус точно такой же дюралевый скрученный винтами, как и в моделях 2008—2011 года (только головки винтов другие). Пустого места в их корпусе даже сейчас достаточно, чтобы там уместились и модули памяти, и еще много чего. Насчет «весит легче» – это вы всерьез говорите о 10 граммах, которые весит разъем и два кусочка текстолита без микросхем? Но тот компаунд, которым они залили батарею, весит в несколько раз больше, можно было бы на нем сэкономить, если бы речь шла о практической пользе. Потом, та же запаянная память стоит в современных MacMini, а уж там выгадывать 10 граммов веса совсм бессмысленно.
    • +1
      Ему не надо туда лезть. Это непродуктивно. Зачем тратить время узкого специалиста на то, что может решить хелпдеск?
  • 0
    Отсчёт начинается с нуля

    Э-э-э, простите, а почему ваши факты в этой статье начинаются с 1?
  • +25
    Какой-то нелепый набор фактов и заблуждений, собранный домохозяйкой. Зачем это здесь?
    • +1
      +1 при прочтении показалось, что писал обиженный на свет ребенок, и при чем сам не понимает на что обижается. Такая ересь
  • 0
    Факт 7.
    По-русски всё-таки о задаче говорят «переспать с ней».
    • 0
      Весна…
      • +2
        Почему сразу весна? Это довольно старый и устойчивый фразеологизм, а «поспать» мне до сих пор не доводилось слышать. Кроме того, с понятием я столкнулся намного раньше, чем услышал слово: бывает, если долго возишься с какой-то неподдающейся проблемой, основательно загрузишься ей, то есть шанс, что с утра осенит внезапной идеей, которая может сработать. Причем это не обязательно связано с программированием, чаще с математикой. У меня впервые это случилось в детстве с нестандартной шахматной задачей, я тогда очень удивился.
      • +1
        Утро вечера мудренее.
  • +10
    Иногда полезно отложить проблему до утра
    но после всего лишь 20-минутного сна
    Да, очень часто до утра остаётся 20 минут…
    • 0
      Или после таких откладываний наступает дедлайн!
  • 0
    Последний пункт просто прекрасен! И он касается не только программирования. Оказывается не я один такой…
  • 0
    Дам прочесть родителям!
  • 0
    Отсчёт начинается с нуля

    Можно такой «отсчёт» назвать сдвигом и жизнь чуточку упростится.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.