Пользователь
0,0
рейтинг
22 января 2015 в 16:11

Разработка → 7 золотых правил одного программиста

Это статья про семь простых правил, которые я сформулировал для себя за годы работы программистом. Семь правил, которые подняли мою эффективность. Сделали меня лучше. Это мои правила и они работают для меня. Я не пытаюсь навязать их вам, я хочу поделиться с вами, и, возможно, узнать о том, каких правил и принципов придерживаетесь вы.

Компьютер всегда прав


Самая раздражающая ситуация в программировании — когда код верный, но не работает. “Да тут три строчки, блин, просто негде ошибиться! Наверное баг! Пойду потрачу три дня на изучение баг-репортов компилятора/интерпретатора/фреймворка...”. Возникает чувство, будто компьютер над вами издевается!

Тут главное помнить, что в этих трех строчках есть ошибка. Если код работает не верно — значит код написан не верно. Точка. Виноваты только вы. Универсальный совет — идите спать! Ну или хотя бы отвлекитесь на чашку чая. Когда, через некоторое время, вы вернетесь к коду, наверняка станет ясно, что тут лишний оператор отрицания, или перепутаны две переменные с похожими именами, или еще какая-нибудь мелочь, в которой мы никогда никому не признаемся.

Успокойся и все получится


Эмоции — наш злейший враг. Лично я, как вы уже догадались по количеству восклицательных знаков, человек эмоциональный. И мне, порой, бывает сложно сконцентрироваться на коде, особенно если этот код писал не я, и код не самого лучшего качества. Мозг как-то сам собой переключается на разработку особо изощренных методов пыток для автора кода.
Нужно заставить себя успокоиться. Нужно принять задачу не как издевательство над вашим мозгом, а как вызов. Да плохой код, да отсутствует документация, да сложно, но я программист, это часть моей работы и я справлюсь.

Самое сложное — начать


Бывает смотришь на задачу, и не знаешь как к ней подступиться. С какой стороны начать? И вообще, что-то лень сегодня. «Посижу 10 минут во Вконтактике, потом начну. Ну, после кофе. Ну вот, старый код надо порефакторить, и потом начну. А это что-за таск с низким приоритетом? Выполню его и точно начну…».
Просто начните. Начните с любого конца. Разбейте задачу на мелкие части и начните выполнять их. Перестаньте откладывать, отбросьте посторонние мысли, сконцентрируйтесь на задаче, и начните работу. Дальше пойдет как по маслу.

Читай книги


Читайте книги. Я еще раз напишу: Читайте книги!
Почему-то многие программисты совершенно игнорируют книги. “Я и на работе отлично просвещаюсь”, “У меня нет времени”, “Я читаю статьи в интернете”. Это все здорово, но лично я считаю, что лучший источник знаний — это все еще книги. Я стабильно покупаю по одной-две книги в месяц, плюс время от времени перечитываю что-то старое. Не буду врать, у меня на полке скопилась внушительная стопка того, что я купил, но пока не читал (как с играми в стиме), но я дойду, обязательно дойду.

Знай свои инструменты


Не поленитесь выделить время на подробное изучение инструментов и технологий с которыми вы работаете. Это многократно окупится. Досконально изучите все возможности языка на котором вы программируйте. Просто возьмите, и прочтите официальную документацию от корки до корки. Не используйте IDE только в качестве редактора кода, в любой современной среде есть куча инструментов для повышения качества кода и вашей продуктивности. Не используйте фреймворк только как скелет архитектуры. Изучите его и он сэкономит вам уйму времени. Разберитесь в тонкостях системы контроля версий. Чем лучше вы знаете свои инструменты, тем больше работы они делают за вас.

Не будь перфекционистом


Выше я писал, что самое трудное — это начать. Так вот, закончить — тоже не всегда легко. Отлаживать и рефакторить код можно бесконечно. “Что-за длинный метод?”, “Может это в отдельный класс?”, “Было бы удобнее если бы...”, “А вдруг потом понадобится...”, “А вдруг...”. В программировании нельзя быть перфекционистом. Проблема в том, что достаточно почитать Роберта Мартина или Банду четырёх, как тут же возникает желание переписать нафиг весь свой код. Нужно понимать, что идеального кода нет. Я придерживаюсь правила: “Код должен работать без багов, быть тестируемым и читаемым”. Все. Пока код метода отвечает этому требованию, я его не трогаю. Даже если в нем два цикла, три условных оператора и четыре параметра.

Умей отдыхать


Самая большая проблема программистов в том, что мы любим свою работу. У меня в отпуске начинается ломка, неделя без программирования — и мне снится сон о том как я продумываю архитектуру нового приложения. Плюс программисту не сложно найти заказы на стороне, которыми можно заниматься по ночам. Плюс свои проекты. А сколько раз вы не могли уснуть, потому что мозг отказывался переключаться с задачи, которой вы занимались весь день?
Все это ведет к переутомлению, и, как правило, к снижению продуктивности. Отдохнувший программист — эффективный программист. Высыпайтесь. Найдите себе хобби, которое никак не связанно с мозговой деятельностью и посвящайте ему пару часов в день. Это позволит отвлечь мозг от работы, перезагрузить его. Самые интересные идеи и самые верные решения в последнее время приходят мне в голову в спорт-зале.
Владимир Болиев @voff
карма
107,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

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

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

  • +7
    Вообще хорошая статья, но где найти одну-две хорошие книги в месяц? Я вот навскидку не смогу вспомнить больше 10-15.
    Мне кажется что из книг надо читать только совсем основополагающие вещи, не зависящие от языка программирования. Например — труды по алгоритмике или управлению проектами. А ЯП и конкретные технологии меняются слишком часто и лучше пользоваться Интернетом.
    • 0
      Время от времени, проскакивают интересные книги в ответах на Тостере. Плюс к этому, при покупке, Озон мне часто предлагает что-то интересное. Ну и часто захаживаю в книжные, посмотреть что есть нового.
    • +22
      Выучить английский. Brave new world awaiting you.
      • +1
        <grammar-nazi>is awaiting же!</grammar-nazi>
        • +2
          Всё норм: это не sentence, это utterance. Для выразительности.
        • +2
          Ушёл читать про то, надо ли использовать for вместе с awaiting и про разницу с waiting, и позорно опозорился. Посыпаю голову пеплом жертв печей граммарнаци.
        • +2
          Или просто «awaits».
        • +1
          Вы сказали фразу с другим смыслом
      • +3
        спасибо! Теперь я знаю, что показывать людям, что бы они поняли, что жизнь коротка.
      • 0
        Gödel, Escher, Bach by Douglas Hofstadter?
        Alice in Wonderland by Lewis Carol??
        The Alchemist by Paulo Coelho???

        Ну, их я, допустим, читал (хотя последнюю в переводе)
        А это что и к чему?
        Zen and the Art of Motorcycle Maintenance by Robert M. Pirsig
        • 0
          • 0
            Эта страничка у меня уже была открыта…

            when the Narrator and his friends came into Miles City, Montana he notices that the «engine idle is loping a little,» a possible indication that the fuel/air mixture is too rich. The next day he is thinking of this as he is going through his ritual to adjust the valves on his cycle's engine. During the adjustment, he notes that both spark plugs are black, confirming a rich mixture. He recognizes that the feel-good-higher-altitude-mountain-air is causing the engine to run rich. New jets are purchased, and installed, and with the valves adjusted, the engine runs well again.


            И что?
            • 0
              Это очень годный типично американский роуд-стори, только ну очень сдобренный рассуждениями о «жизни, вселенной и вообще». И нет, ответ там не 42.
              • +2
                Это понятно. Но при чём здесь программисты? И странно, что в списке нет ни «Гамлета», ни «Пигмалиона».
                • +1
                  Зато есть Алхимик за авторством Пауло Коэльо. Жаль вопрос уже закрыт. Я думаю после алхимика в списке очень органично смотрелся бы один из шедевров Дарьи Донцовой. Каждый программист должен прочитать!

                  А вот про мотоциклы — Роберт Мартин советовал. Он авторитет.
                • 0
                  Ну хз, вполне себе годные книги. Ну а то что к программингу прямого отношения не имеют — то это как с головоломками. Мозги в тонусе держать. Ибо этот инструмент важнейший для программиста.
                  А б в тот список еще накидал «7 кругов ада», «Собачье сердце», «Мастер и маргарита».
                  На полном серьезе.
                  Ну а про мотоциклы уже в который раз вижу эту книгу в различного рода топах «маст рид» — видимо там не все так просто, придется прочитать.
    • +2
      Так ведь есть и «смежные» категории и фундаментальные книжки, помимо посвященных определенной технологии\ЯП.
    • 0
      Один из вариантов — идти на EAP у издательств, и смотреть книги, которые в процессе написания.

      Например, я люблю скалу и кложу, у меня на данный момент 9 книг в MEAP от Manning — и про reactive programming, и новые издания уже имеющихся книг — и с каждым апдейтом (новой главой) я могу выделить вечер-другой, чтоб прочитать и попробовать, что там написано.

      С другой стороны, есть книги, которые в принципе нужно читать не сильно связанные с программированием, например, тот же Concrete Math Грэма/Кнута/Паташника. Опять же — сесть и прочитать полностью — слишком долго, читать по главе и делать упражнения очень помогает в качестве зарядки для мозга.
      • 0
        С другой стороны, есть книги, которые в принципе нужно читать не сильно связанные с программированием,

        Это я и имел в виду под «совсем основополагающие вещи».
  • +3
    Проблема в том, что достаточно почитать Роберта Мартина или Банду четырёх, как тут же возникает желание переписать нафиг весь свой код. Нужно понимать, что идеального кода нет. Я придерживаюсь правила: “Код должен работать без багов, быть тестируемым и читаемым”.

    Проблема в том, что ровно этими же аргументами пользуются всякие говнякеры. «Фича работает, а я лучше пива пойду попью».
    • +1
      А перечитав Уоррена сразу лезешь в ассемблерный листинг и оптимизируешь деление на константу, подсчёт количества нулей и т.д.
    • +13
      Надо сказать что между «фича работает» и «тестируется и читается» довольно существенная разница.
      • +1
        Согласен, но читабельность дело относительное («я могу прочесть, что я написал, а тебе чо, больше всех надо? лучше пива попить с друзьями»), а тесты пишут не все.
        • +3
          Если нет сомнений в том, что код работает правильно, читается средним программистом и на 100% покрыт тестами — можно идти пить пиво. Проблема ленивых программистов часто сводится к невыполнению одного из этих условий.
          • 0
            В такой формулировке согласен.
  • +9
    Правило «компьютер всегда прав» не следует воспринимать как абсолют. Он иногда-таки неправ, и это следует иметь в виду. Мне довелось, например, столкнуться со случаем, когда VS2005 в определённых обстоятельствах выдавала this, отличающийся на 4 байта от того, что следует. Эффекты были довольно-таки… интересные. А ситуации в духе «с -O2 работает, с -O3 нет» встречаются сплошь и рядом.
    • –2
      Да, это так. На stackoverflow есть отличное обсуждение Strangest language feature, но это все скорее исключения, подтверждающие правило.
      • +4
        «Компьютер всегда прав» — это странное обобщение. «Всегда» — это понятие из абстрактной математики, а мы имеем дело с реальным миром. Надо знать хотя бы приблизительно какова вероятность ошибки в разных ситуациях. Можно ли доверять данным прочитанным из сети? Можно ли доверять данным прочитанным с жесткого диска или с флешки/дискеты/ленты/перфокарты? Если да — то откуда тогда берутся битые архивы? И зачем в протоколах реализуют контрольные суммы и коррекцию ошибок?

        Ошибки проявляются часто. Очень часто. Если вы с ними не сталкивались — вам крупно повезло. Ошибки операционных систем иногда даже впоследствии не исправляют, а документируют как фичи. Ошибки в железе тоже встречаются. Неужели уже забыли как Интел все свои пентиум-процессоры проданные менял забесплатно?

        Если программа работает в «стерильной среде» — это одно. А если на борту межпланетного зонда, где фиг знает какая температура, давление, радиация и перегрузки — это другое. Когда я читаю, что в каком-то межпланетном зонде автотесты выявили проблему в отдельной ячейке памяти, но перепрошивкой программы удалось исключить эту ячейку из использования — вот это высший пилотаж! По сути дела — написать программу с новой ошибкой, которая нейтрализует существующую ошибку.
        • +1
          Безусловно, в конкретных задачах (как ваш пример про межпланетный зонд) есть своя специфика. Например кто-нибудь из того-же Вконтакта мог сказать «Читаемость — фигня, главное оптимизация под Highload». Я не пытался написать гайд по программированию, тем более для людей запускающих шатлы, и пару раз написал в статье, что эти правила подходят лично мне.
    • +1
      В xcode целый день убил не мог понять в чем дело. Ниче не помогало… Оказалось мак как-то старый код закешировал, а все что я нового писал не воспринимал. После перезагрузки компьютера все мои изменения пропали и все заработало как надо. Перезагрузка просто xcode не помогала, только ребут.
      • 0
        На последнюю версию xcode очень многие плюются
      • 0
        В VS 2013 всё время нарываюсь на то, что иногда она путается во взаимосвязях проектов и не компилирует последние изменения — вместо Build надо нажимать Rebuild All. Если не удаётся вовремя об этом вспомнить, то можно несколько часов потратить на поиск несуществующей ошибки. Хорошо, что дебаггер может предупредить, что «код не тот» — но отладка чаще идёт по log-файлам, а не в дебаггере.
        • 0
          Код уже не тот. Хорошо звучит.
      • 0
        В IDE от JetBrains есть волшебное Files > Invalidate Caches / Restart..., в xcode нет ничего подобного?
    • 0
      Все так. Кроме того, современные прикладные программисты во многом зависят от стороннего и возможно некачественного кода всякого рода фреймворков, оберток, библиотек и утилит. И если от проверенного временем кода стандартной библиотеки и стабильных версий популярных прикладных библиотек в большинстве случаев действительно не стоит ждать подвоха, то менее известные утилиты постоянно несут в себе скрытую угрозу. Особенно их самые новые и самые старые версии.
    • +1
      Если код работает не верно — значит код написан не верно

      Компьютер в вашем случае был прав, в отличие от неверно написанного кода VS2005 :)
      • 0
        Нет уж, позвольте-позвольте.
        С точки зрения программиста — всё, что лежит «уровнем ниже» его кода — это как раз «компьютер»
        Это и железо, и операционная система, и фреймворк, и компилятор, и библиотека, и байткод-машина.
        Для программиста уже неважно где там в потрохах ошибка.
        Ну вот пример из сравнительно недавнего моего прошлого: на определенных телефонах LG (еще java/midp) жава-машина работает так, что неправильно выполняется функция String.intern ( )
        Ну вот неправильно и всё тут. Дает какие-то абстрактные результаты.
        Всё. Алес. Сушите вёсла. Эту функцию нельзя реализовать с помощью других правильно работающих функций.
        Можно лишь переделать логику программы, чтобы эту функцию не использовать.
        • –1
          Программист был неправ, что использовал функцию String.intern() на телефонах LG.
          • 0
            А я оказался неправ, использовав неподдерживаемую функцию «irony».
    • 0
      Или, например, вспомнить frontend и разработку на js. В одном браузере работает, в другом нет, а в третьем вроде все правильно, но все-таки немного по другому. И это очень часто. Не говоря уже о бесконечном количестве js-библиотек, которые появляются, как грибы после дождя, которыми уже пользуются тысячи программистов, но у которых под 300-500 issues на github.
      Поэтому умение быстро найти в багтрекире то, с чем сам столкнулся, для программиста необходимо. И не нужно этого бояться. Это нормальный рабочий процесс.
  • +2
    Насчет «Просто начните» — очень дельный совет, бывает, что все отвлекает, мелочи всякие, чаты, но как только начнешь, то сидишь до ночи (что нарушает правило отдыха =\ ) крайне увлеченным)
  • НЛО прилетело и опубликовало эту надпись здесь
  • +7
    > Если код работает не верно — значит код написан не верно.
    Не работает в случае с программированием микроконтроллеров. Можно долго отлаживать софт, когда криво работает железо. Но это больше придирка, статья хорошая.
    • 0
      Да, в errata можно много интересного прочитать…
    • 0
      Да и такая же беда с языками, браузерами и шимами/полифиллами (реализациями спек), API, ОС…
  • +1
    Мозг как-то сам собой переключается на разработку особо изощренных методов пыток для автора кода.

    Уж это тооочно) Зато когда наоборот, когда мой код читают другие программисты, думаешь, что они восхищаются и говорят «Ах, да этот программист гений, ге-ний!».
    • +1
      А они тебя — шлёп мордой в говнокод.

      Очень в этом плане отрезвляет практика code-review. Кстати некоторые программисты с каким-то садистским удовольствием проводят review чужого кода, неоднократно замечал.
      • 0
        А некоторые с садомазохистким, если этот код в «твоем» проекте и намекает с первых строк на огромный потенциал баготворства(
  • +1
    Все это работает в любой сфере деятельности, особенно если заменить слово компьютер на начальник/заказчик/клиент/мама (ненужное зачеркните).
  • +5
    «Если код работает не верно — значит код написан не верно» не работает для jruby, раз в месяц по багу нахожу :)
  • +2
    > Если код работает не верно — значит код написан не верно. Точка. Виноваты только вы.
    Годится только для элементарных программ из одного оператора, да и то может не повезти (в GCC 4.5.? была ошибка, когда он при некотором стечении обстоятельств пытался подсунуть 64битный регистр в 32битный код).
    За последние 4 года я наступил примерно на 5 багов в GCC, примерно на 10 в Intel C++ и на два в MS VC++. Разве что мне везло, и только один баг в VC++2010 я не нашел в интернете, но обходной путь для него оказался элементарным, а MS старые баги все равно не исправляет.

    По остальным пунктам по существу согласен.
    • 0
      deleted
    • 0
      Поддерживаю этого смутьяна. Сегфолт программы скомпилированной свежей версией GCC флагом -O2 дело не частое, но даже я, веб-программист, на него нарвался.
      • +5
        Если у вас программа c -O2 падает, а с -O0 работает, то почти наверняка у вас там проблема с неинициализированными указателями. Иногда смотришь в такой код и не понимаешь, почему он вообще работал.
        • +1
          Ещё одна ситуация, когда программа падает буквально на ровном месте и совершенно не там, где кроется настоящая ошибка — выход за пределы массива/списка.
          Допустим, у нас в списке всего 10 элементов, но как-то так получилось, что мы пытаемся обработать 150-й элемент. И он даже «обрабатывается», и всё работает дальше… чтобы потом упасть где-то в совершенно произвольном месте. Причём перестановка местами кусков кода или изменение флагов компилятора приводит к тому, что программа уже начинает падать в другом месте или даже начинает работать без падений.
  • +2
    Бывает смотришь на задачу, и не знаешь как к ней подступиться. С какой стороны начать? И вообще, что-то лень сегодня. «Посижу 10 минут во Вконтактике, потом начну. Ну, после кофе. Ну вот, старый код надо порефакторить, и потом начну. А это что-за таск с низким приоритетом? Выполню его и точно начну…».

    У меня как-то получается наоборот.
    Начать? Легко. Открыл VS, нашёл нужное место, создал нужный метод… Что теперь создать, массив, список или словарь? В каком порядке начать писать обработку? Нужна такая функция — она уже есть где-то в Solution или нет, если нет — в каком проекте её лучше написать? Ладно, пока отложим. Вон и список задач есть — что-то с низким приоритетом, что-то со свежими вопросами пользователей… Нет, ну их к чёрту, ещё отвлекут от основной задачи. Лучше новости почитаю… А, тут ещё и комментарии к ним? Вкусно… Что, куда три часа делись? Опять с собаками гулять. Но ничего, вот вернусь — точно всё напишу.
  • +4
    «Если код работает не верно — значит код написан не верно»
    Тут привели много исключений из этого правила, все они имеют право на жизнь, но на практике в подавляющем большинстве случаев правило верное. Особенно оно проявляется на простых, банальных участках кода, где он набирается машинально, а мозг в это время строит воздушные замки где-то в другом месте.
    Вот, буквально час назад сидел тупил: объявил две переменных-указателя (нужна была одна), инициализировал одну, использовал другую. При чём тупил в код в полной уверенности, «да что, блин, тут такого?»

    И такие ситуации, опечатки, невнимательность, очень часты. Так что взял за правило искать косяки в своём коде и вокруг него, а не грешить на фреймворки и компиляторы. Хотя ошибки в последних тоже попадались.
    • 0
      Компиляторы тоже люди пишут.
  • 0
    Название статьи в стиле «Этого программиста звали Альберт Эйнштейн».
  • +3
    Если код работает не верно — значит код написан не верно

    И еще — если вы уже 2 часа не можете найти, почему свеженаписанный код не работает, хотя проверили все уже 3 раза, то ошибка в том самом месте, где все настолько просто, что ошибиться никак нельзя.
  • +1
    Компьютер всегда прав
    Самая раздражающая ситуация в программировании — когда код верный, но не работает.

    Вот этот пункт спорный, я например периодически натыкаюсь на баги в используемых рантайме и библиотеках, несколько раз ловил баги компиляторов в msvs и clang, баги и неоднозначные/недокументированные моменты в api операционной системы тоже встречаются. Написанный мной код при этом был вполне верный, относительно документации.
  • 0
    Я как-то раскопал реальный баг в фреймворке Windows Phone и мой солюшн по обходу до сих пор получает плюсики на stackoverflow.
  • 0
    хочется просто сказать «спасибо»
    Согласна со всеми пунктами.
  • 0
    Успокойся и все получится

    Не раз такое было! Битый час сидишь и думаешь почему оно не работает. Пошел прогулялся/поспал/поиграл/любая другая деятельность. Пришёл посмотрел и за 5 минут всё исправил.

    Самое сложное — начать

    Иногда это бывает чревато, я не раз попадался на том что вот просто так взял и начал, а потом понял что уже 4 утра и скоро зазвенит будильник! =)

    Знай свои инструменты

    Полчаса на изучение хоткеев sublimetext с экономило тучу времени.

    Не будь перфекционистом

    Интересное правило надо попробовать себя убедить останавливаться так же.
  • +1
    Один вопрос: как трудоголику научиться отдыхать?))

    Сколько раз ловил себя, лазя по поиску с таким запросом, отлаживающим тот или иной баг в каком-либо проекте)))
    • +1
      Один вопрос: как трудоголику научиться отдыхать?))

      Само придёт. Лет через 20. Потом возникнет вопрос, как научиться возвращаться в прежний режим.
      • 0
        Вижу вы знаете ответ на первый вопрос.
        И может подскажете ответ на второй? )
        • 0
          Похоже, что никак. Даже вариант «воспитать нового трудоголика в своём коллективе» не работает.
    • +1
      Отдохнете, когда станете старым. В молодости нужно все сделать по максимому.
      • 0
        Здесь с Вами не соглашусь. Уже сейчас, будучи молодым, уже ощущаю как перегорает тело и разум, а это плохо скажется в более старшем возрасте, ибо буду не отдыхать, а по поликлиникам бегать из-за того, что в молодости, как раз, так и не научился отдыхать…
        • 0
          Мозг лучше знает, что ему сейчас важнее. И если есть возможность, лучше ему не мешать. Если он хочет работать — наверное, это правильно.
          Но может помочь какое-нибудь гиковское увлечение, требующее физической нагрузки. Хорошим вариантом может быть, например, геокешинг — хорошее сочетание техники, азарта, планирования и путешествий. Мне ещё понравилась инфракрасная фотография — интересно, но, сидя дома, ничего не добьёшься. И мозг хорошо обманывается — он-то думает, что это такая же работа, как и программирование.
        • 0
          От работы нужно отдыхать с помощью смены деятельности. Т.е. ездить куда-то, заниматься спортом (сноуборд, велосипед).
          • 0
            Смена умственного труда физическим… Хм… В этом есть смысл)
            Осталось победить "лень"… Но так лень )))))
    • +1
      Проблемы трудоголиков яйца выеденного не стоят по сравнению с проблемами лентяев. Трудоголик любит работать и проблема отдыха у него стоит только в связи с физическим здоровьем.

      А теперь представьте себе, как дела обстоят у нормального человека лентяя. Работать ему тяжело, он любит отдыхать и ищет этого отдыха прямо в процессе работы. В результате отдыхать он толком не отдыхает, а работа у него не сделана потому, что он толком и не работает.

      Физическое здоровье лентяя убито вконтактиком, компьютерными играм и пивом не менее эффективно, чем здоровье трудоголика работой, но трудоголику есть чем похвастаться девкам потенциальному работодателю и чем оплатить массаж, а у лентяя есть только горы несделанной работы и непроработанного учебного материала.

      Мне бы ваши проблемы — говорит лентяй трудоголикам, и смеётся неврным смехом человека у которого нет перспектив, нет надежд и нет денег.
  • 0
    Все-таки бывают и в компиляторе ошибки. Однажды два дня провел обыскивая довольно большой кусок программы и так и не нашел в чем проблема, пока не отключил оптимизацию в компиляторе.
    • +8
      ну судя по описанию обычное UB
  • 0
    Всё правда )). Некоторые этапы сейчас у меня в процесе преодаления. Самый сложный «Читайте книги» — отвлекаюсь постоянно на всякое постороннее…
  • +1
    «Компьютер всегда прав» — не совсем верная формулировка, я чаще ее встречал в виде «компьютер делает только то, что ему сказали сделать». В таком виде можно убрать споры про баги компилятора.
    • 0
      Угу, оставив баги аппаратной части :)
  • 0
    Коротко:«хватит въебывать время, пойди и сделай работу в 5 раз быстрее» — для меня работает идеал но. Плюс планирование каждой задачи.
  • +1
    Не буду врать, у меня на полке скопилась внушительная стопка того, что я купил, но пока не читал
    Как знакомо. Я специально купила «Совершенный код», чтобы точно прочитать. И всё не могу её осилить, даже стыдно, ведь некоторые перечитывают её каждый год! «Я ежегодно перечитываю ее на протяжении вот уже девяти лет и все еще узнаю много нового!» (с) Джон Роббинс

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