Книга «Программирование без дураков»

    image Возможно, вы хорошо знаете о проблемах, которые есть в вашем коде. Возможно, у вас уже даже сложилось представление о том, что нужно или не нужно делать в будущем, чтобы стать хорошим программистом. «Нет ничего страшного в том, что вы плохой или средненький программист, — пишет Стив Макконнелл в книге Code Complete. — Вопрос заключается лишь в том, как долго программист может быть плохим или средненьким, не осознавая при этом, что можно делать лучше». Почему же зачастую так сложно перейти к этапу определения проблем и нахождения способов их устранения?

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

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

    Глава 19 Не делай сам


    Неопытные программисты тратят много времени, заново изобретая функции, которые уже имеются в используемом ими языке или его стандартных библиотеках. Разумеется, на первых порах невозможно получить представление обо всех функциях конкретного языка программирования. Никто не будет начинать изучение языка, запоминая все его команды в алфавитном порядке1. Тем не менее как же без особых усилий определить, где целесообразно корпеть над задачей и программировать самому, а где вы всего лишь заново изобретаете велосипед (с треугольными колесами)?

    Вот неполный список команд PHP, которые я по незнанию написала сама:

    array_rand, disk_free_space, file_get_contents, file_put_contents, filter_var,
    htmlspecialchars, import_request_variables, localeconv, number_format, parse_
    url, strip_tags, wordwrap

    Катрин

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

    Внимательные читатели распознают в этих проблемах оборотную сторону важных программерских добродетелей, перечисленных Ларри Уоллсом (о них мы говорили в главе 2): лени, нетерпения и переоценки собственных сил. Эти качества программиста превращаются в достоинства лишь тогда, когда специалист начинает использовать их к месту. Тот, кто самостоятельно пишет все свои инструменты, не озаботившись предварительным исследованием, упускает время, которое можно было бы потратить на создание чего-то действительно полезного, еще не существующего. Ведь первая рабочая версия собственной функции расчета даты, движка для блога или инструмента для учета рабочего времени пишется на удивление быстро, но стоит только начать ею пользоваться, как поразительно быстро всплывают какие-то частные случаи, баги, пожелания по расширению… А когда с кодом начинают работать другие люди, его поддержка может отнять у вас огромнейший кусок жизни. Согласно известному эмпирическому правилу опытный программист с учетом обдумывания, тестирования, отладки, оптимизации и документирования пишет примерно десять строк отточенного кода в день (кстати, у писателей схожая ситуация). Неопытный разработчик, вероятно, успеет не больше.

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

    Применять готовые решения целесообразно и потому, что самодельные инструменты не обрадуют тех, кому в будущем придется работать с вашим кодом и читать его. Возможно, эти специалисты захотят повысить производительность приложения или найти в нем ошибки. Если же в нем вместо вызова проверенных стандартных функций всплывет ваше собственное решение, то незнакомый код вызовет справедливое недоверие. Читателю кода придется самостоятельно разбираться с деталями странной функции сортировки, чтобы убедиться, что она не содержит ошибок и действительно эффективно решает задачу. Напротив, если бы в коде была использована стандартная функция, то опытный читатель мог бы всем этим не заниматься, поскольку реализация стандартной функции проверена уже столько раз, что можно не сомневаться: ошибок в ней нет и работает она эффективно.

    Что делать


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

    - Читаешь документацию по языку, используемому в данной предметной области. Может быть, удастся найти перекрестные ссылки на нужное решение.

    - Смотришь список всех функций или функций из определенной тематической области и надеешься, что нужная функция будет иметь говорящее название. Так, функция array_rand из приведенного ранее примера легко отыскивается в документации по языку PHP на сайте php.net в разделе «Функции массивов».

    - Сверяешься с книгой, в которой перечисляются стандартные решения. Для этого хорошо подходят сборники рецептов от издательства O’Reilly (в оригинале такие книги называются Cookbook). В них формулируются типичные вопросы, возникающие при программировании, ответы на которые даются в форме рецептов.

    - Забиваешь проблему в поисковик и ищешь решение на таких сервисах, как stackoverflow.com, где сразу множество пользователей предлагают решения одно элегантнее другого. Например, я наткнулся на функцию array_rand, задав запрос «how to» «random element» array php.

    - Заходишь на сайты github.com или sourceforge.net и ищешь в описаниях свободных проектов написанный на интересующем вас языке. Существует огромная вероятность того, что ваша проблема уже решалась. Затем выясняешь, как авторы проекта справились с задачей.

    - Когда накопишь некоторый опыт, то и в сравнительно новом языке представляешь, какие функции есть в распоряжении. Остается уточнить их названия и технические детали. Уже не придется формулировать в поисковике какой-нибудь тяжеловесный запрос вроде «how to» «random element» array php. Вместо этого достаточно спросить: array_rand in python, чтобы найти питонский эквивалент уже знакомой команды PHP.

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

    » Более подробно с книгой можно ознакомиться на сайте издательства
    » Оглавление
    » Отрывок

    Для Хаброжителей скидка 25% по купону — Comp
    Поделиться публикацией
    Похожие публикации
    Комментарии 12
    • +1
      Прочитал доступный бесплатно отрывок, складывается впечатление, что вся книга будет написана в духе «Вы не умеете программировать, а если считаете, что умеете, то идите дальше пишите драйвера в ядре Linux». Что вообще в ней есть, кроме очевидных фактов о том, как трезво оценивать собственный код?
      • –1
        Книга написана в духе «не повторяйте чужих ошибок. Лучше сделайте вот так: проверено — это работает».
      • 0
        навеяло:
        — Белка!
        — Гав!
        — Нажми красную кнопку.
        — Стрелка!
        — Гав!
        — Нажми синюю кнопку.
        — Василикэ!
        — Гав!
        — Не гавкай. Покорми собак и ничего не трогай!
        • +1
          А то!

          Однажды Тиль Уленшпигель успешно выучил осла выговаривать звуки «И» и «А»
        • 0
          > Ларри Уоллсом

          Так в книге?!
          • +1

            Только вот написание велосипедов прокачивает, а npm install --save leftpad – нет. Как обычно, успех где-то посередине: в умении оценить свои способности и внешние требования, и принять решение о самостоятельной разработке, или использовании готового. Вариант "выясняешь, как авторы проекта справились с задачей" не подходит: все равно без практики ничего не запомнишь и не поймешь.


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

            • 0
              поскольку реализация стандартной функции проверена уже столько раз, что можно не сомневаться: ошибок в ней нет и работает она эффективно.

              Я столько раз натыкался на проблемы в стандартных функциях и системных API, что эта строчка смотрится для меня просто нелепо.
              • +1
                Читаешь документацию… смотришь список всех функций… сверяешься с книгой… забиваешь проблему в поисковик… заходишь на github.com...
                Лишь окончательно убедившись, что нигде нет готового кода, которым можно было бы воспользоваться, стоит приступать к программированию самому.
                Приступаешь к программированию и с ужасом обнаруживаешь, что сам не можешь написать ни строчки. Как же так? Я же это… всё знаю, всё понимаю, всё выучил, во всём разобрался, научился находить ответы на самые каверзные вопросы. Почему не могу написать даже элементарной ерунды? Даже, прости господи, сортировку пузырьком?

                Для того, чтобы уметь ходить, нужно ходить. Знать на латыне названия всех костей, мышц и сухожилий — это хорошо, но опционально. Быть в курсе самых модных «best practices» в этом деле — тоже может быть полезно и познавательно, но тоже опционально. Магистерская степень по теоретической механике — безусловно круто, но ни в коем случае не заменит глупого, неуклюжего и неэффективного самостоятельного хождения своими собственными ногами по грешной земле.

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

                В сухом остатке: читать доки / книжки / статьи / github — безусловно нужно и полезно, не точно никак не «вместо». Вместе — пожалуйста, но вместо — не надо.
                Ну и что, что изобретёшь очередной велосипед? Разве это повод для переживаний? Велосипедостроение, в конце концов, существует до тех пор, пока люди не перестают изобретать велосипеды.
                • 0
                  OFF
                  А вот эту книгу планируете выпускать и если планируете то когда?
                  https://www.bignerdranch.com/blog/whats-new-in-android-programming-the-big-nerd-ranch-guide/

                  Заранее спасибо за ответ.
                  • 0
                    Эммм…
                    Дороговато быть нынче дураком. Дороже, чем идеальным разработчиком, примерно в два раза, судя по цифрам в ценах по разделу.

                    Серьёзно? 1140?
                    • 0
                      Интересно будет её сравнить с уже прочитанным, посвященным данной тематике, 400 страниц все таки не 860+.
                      • 0
                        Совершенно бесполезная книга.

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

                        Самое читаемое