01.02.17. Возможно, вы хорошо знаете о проблемах, которые есть в вашем коде. Возможно, у вас уже даже сложилось представление о том, что нужно или не нужно делать в будущем, чтобы стать хорошим программистом. «Нет ничего страшного в том, что вы плохой или средненький программист, — пишет Стив Макконнелл в книге Code Complete. — Вопрос заключается лишь в том, как долго программист может быть плохим или средненьким, не осознавая при этом, что можно делать лучше». Почему же зачастую так сложно перейти к этапу определения проблем и нахождения способов их устранения?
Основные причины того, что мы находим неправильные способы решения проблем, лежат в плоскости наших человеческих качеств. На первом месте в этом случае стоит консерватизм. Сначала не так уж просто противостоять сильному желанию делать все так же, как и раньше. Мозг должен экономно распределять свои ресурсы и поэтому функционирует таким образом, чтобы не отвергать приемлемое решение проблемы при виде туманной альтернативы на горизонте. А изучение всех актуальных трендов в новых технологиях, языках, методах и фреймворках — слишком затратное по времени мероприятие, которое может заставить позабыть о веселой жизни.
В то время как дети и подростки большую часть времени узнают что-то новое, взрослые часто не совершенствуют полученные знания в течение длительного периода. «Ну да, но ведь всегда же так было», — скажет плохой программист, у которого нет никакого желания даже представить себе, как сделать мир лучше и не тратить целый день на изменение всех строчных букв в тексте на прописные да еще к тому же расставить точки над «Ё». Он это делает не только потому, что хочет использовать проверенное решение проблемы, он еще хочет по вполне объяснимым причинам затратить на размышления над проблемой как можно меньше времени. Если делать что-то, не думая об этом, к цели придется идти довольно долго, хотя с каждым шагом достигаются видимые результаты. Если же сначала думать над проблемой, то ее можно в конце концов решить довольно быстро, но в первые часы, дни, недели размышлений не стоит ожидать видимого результата. Такое нежелание вкладывать собственные ресурсы в самообразование становится постоянным, хотя при этом результаты самым парадоксальным образом оказываются итогом усердной работы. В то же время программист, который долго думает над проблемой, напоминает человека, постоянно сидящего на балконе и устремившего вдумчивый взгляд на облака или целый день листающего вебстраницы.
Вот неполный список команд PHP, которые я по незнанию написала сама:
Катрин
Однако неумелые программисты не пользуются имеющимися решениями не только по неопытности или незнанию. Даже если поставленная задача вызывает у программиста робкое подозрение о том, что кто-то уже мог ранее с ней столкнуться и найти решение, далеко не всегда делается следующий логичный шаг: найду-ка я это решение. Многие воспринимают программирование как интересное и увлекательное занятие, поэтому гораздо охотнее пишут код, чем ищут уже написанный. Кроме того, люди склонны переоценивать собственные способности, а также недооценивать сложность стоящей перед ними задачи. Как раз те задачи, которые кажутся вполне обозримыми, оборачиваются проблемами, хотя неопытный программист, ознакомившись с задачей, почти сразу полагает, что нашел если не решение, то путь к нему.
Внимательные читатели распознают в этих проблемах оборотную сторону важных программерских добродетелей, перечисленных Ларри Уоллсом (о них мы говорили в главе 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
Основные причины того, что мы находим неправильные способы решения проблем, лежат в плоскости наших человеческих качеств. На первом месте в этом случае стоит консерватизм. Сначала не так уж просто противостоять сильному желанию делать все так же, как и раньше. Мозг должен экономно распределять свои ресурсы и поэтому функционирует таким образом, чтобы не отвергать приемлемое решение проблемы при виде туманной альтернативы на горизонте. А изучение всех актуальных трендов в новых технологиях, языках, методах и фреймворках — слишком затратное по времени мероприятие, которое может заставить позабыть о веселой жизни.
В то время как дети и подростки большую часть времени узнают что-то новое, взрослые часто не совершенствуют полученные знания в течение длительного периода. «Ну да, но ведь всегда же так было», — скажет плохой программист, у которого нет никакого желания даже представить себе, как сделать мир лучше и не тратить целый день на изменение всех строчных букв в тексте на прописные да еще к тому же расставить точки над «Ё». Он это делает не только потому, что хочет использовать проверенное решение проблемы, он еще хочет по вполне объяснимым причинам затратить на размышления над проблемой как можно меньше времени. Если делать что-то, не думая об этом, к цели придется идти довольно долго, хотя с каждым шагом достигаются видимые результаты. Если же сначала думать над проблемой, то ее можно в конце концов решить довольно быстро, но в первые часы, дни, недели размышлений не стоит ожидать видимого результата. Такое нежелание вкладывать собственные ресурсы в самообразование становится постоянным, хотя при этом результаты самым парадоксальным образом оказываются итогом усердной работы. В то же время программист, который долго думает над проблемой, напоминает человека, постоянно сидящего на балконе и устремившего вдумчивый взгляд на облака или целый день листающего вебстраницы.
Глава 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
Смотри также:
- 100 НОВЫХ главных принципов дизайна. http://fetisovvs.blogspot.com/2016/07/100.html
- Безопасная Халяв@ в Интернете. http://fetisovvs.blogspot.com/2016/12/blog-post_33.html
Комментариев нет:
Отправить комментарий