Оптимизация временных затрат на написание PHP кода

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

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

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

На самом деле, все банально просто. Как и многие, я не только начинал свой путь с изучения PHP, но и по сей день использую этот язык как основной. Да, время от времени я пишу на Java. Также использую JavaScript и Python. Но последние, особенно JavaScript, как и PHP, используются мною для создания веб-приложений, следовательно, выступают в качестве скриптовых языков, что подразумевает практически однотипную модель разработки.

Что делает PHP программист во время работы?




Выполняются примерно следующие операции:

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

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

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

Как избавиться от этой дурной привычки? Ответ лежит в самой причине ее возникновения. Java или C++ разработчики, например, не страдают от такой проблемы, так как у них перезапуск приложения связан с достаточно небыстрым процессом предварительной компиляции. Грубо говоря, постоянно нажимать «F5» совершенно невозможно. У веб-разработчиков такой проблемы нет. Обновил страницу и получил результат. В итоге, со временем, приобретаешь совершенно идиотскую и вредную зависимость.

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

Для себя я нашел решение проблемы в разработке мобильных приложений на Java для Android. Если вы вам хоть раз доводилось запускать приложение на эмуляторе Android, то вы без лишних комментариев поймете, насколько быстро я научился не перекомпилировать проект постоянно :)

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

  1. Вы путаете понятие итерации с понятием шага. Итерация — это обход всех шагов в цикле за один повтор.
    А решение проблемы есть простое. Ведь F5 + print_r начинающие PHP разработчики используют да и только, не зная, что кроме этого есть отладчики. А сишники по сути отладчиками за частую и пользуются, нежели смотреть на откомпилированную программу с догадками, что там не так.

    • Да, вы правы. В моем примере, в рамках всего цикла разработки, итерацией будет совокупность описанных операций.

      Что касается отладчика, то не совсем согласен. В заметке речь идет не о процессе отладки, а о процессе разработки без учета временных затрат на поиск и устранение ошибок. То есть, я нажимаю F5 не для того, чтобы увидеть вывод расставленных по коду print_r или var_dump, а просто для того, чтобы видеть результат работы дополненного кода. Равно как С программист компилирует приложение. Он ведь делает это не для поиска проблем. Это уже потом, если проблемы возникли, в дело вступает отладка.

      P.S: заметку подправил

  2. Антон

    С явой Вы не правы. Ява компилируется инкрементально и потому часто даже не заметно. Почти все jvm поддерживают hotswap, что делает перезапуск (веб)сервера/контейнера часто не нужный. Молчу о OSGi и об использовании (веб)серверов/контейнеров а ля нетти, которые позволяют березапускать приложение за менее, чем пол секунды. Естественно, что для редактирования шаблона, почти во всех фреймворках, перезапуск не нужен вообще.

    Так же Вы не правы про шаги. Хороший разработчик сразу думает, потом пишет/правит/запускает тест, а потом уже делает всё остальное. Такой подход часто избавляет от F5 и прочих перезапусков.

    • Вы писали на Java под Anroid? Попробуйте, а потом мы с вами обсудим вопрос скорости перекомпиляции и запуска приложения.

      Что касается «хорошего разработчика», который сначала думает, а потом пишет. То давайте представим небольшую задачу в среде legacy кода. Чтобы иметь возможность сначала много думать, а потом писать, мне нужно убить вагон времени на чтение логики. Поэтому такие задачи решаются эмпирическим путем, где F5 и друг и враг.

      • Антон

        Вы пишите вебаппликации на яве для андроида? Или на пхп? А сколько желочи. Да и дальвик не та конкретная jvm, о которой идёт речь, верно?

        Как раз последние года я работаю в не маленьком проекте (активная разработка с 2004-го года, 120+ разработчиков, 350+ в отделе разработки, 1200+ во всей компании, после редукции на 80 компонент, 15 комманд, 1(!) проект). Не мне ли судить о легаси коде и что касается хорошего разработчика? И даже в таких проектах TDD, MDA и прочие практики имеют место быть и даже внедрение задним числом. Иначе как бы мы могли с такой массой кода каждый спринт производить удивительное множество фич? Нужно только желание. А «мне нужно много думать … Поэтому такие задачи решаются эмпирическим путем» — это не аргумент для не писания разных видов тестов и рефакторинга. Даже наоборот — откуда Вы знаете, что то, что Вы сделали вчера «эмпирическим путем», Вы не сомали сегодня? Вот так и рушатся из-за плохого кода компании, проекты переписываются с нуля и т.д. — в основном из-за нежелания сделать правильно или из-за нехватки хороших практик.

        • Какой такой желчи? Будет вам.
          Я просто не люблю людей, которые читают по диагонали, но торопятся оставить свой важный комментарий. А вы, если судить по первому комментарию, именно так и сделали. Вы даже сейчас спрашиваете меня о том, что я пишу на Java для Android, хотя в последнем абзаце поста я совершенно ясно об этом сказал.
          Лермонтов был прав, когда говорил, что предисловия читать не принято. Что уж там предисловия.

          В данном случае не вам судить о легаси коде, так как я писал именно о маленьких задачах в больших проектах. Опять же, не понятно, как вы прочли мой комментарий. Через слово?

          Если я беру задачу с бюджетом 5000 рублей и необходимостью «ввернуть новую фичу» (таких задач подавляющее большинство). Имею при этом CMS писаную не понятно кем и когда. Вы предлагает внедрить TDD? Написание одних только тестов не влезет в этот бюджет, я уж не говорю о том, чтобы заняться непосредственным решением поставленной задачи. Или вы предлагаете покрыть тестами только мой собственный код? В чем тогда их смысл, если вся остальная система для меня остается черным ящиком? Наверное стоит понимать, что есть разные задачи и условия решения этих задач. Я не буду искусственно увеличивать себе объем работы введением TDD, если за это никто не платит. В тоже время заказчик не будет оплачивать оверхед просто потому, что так будет правильно с точки зрения методологий. Ему до лампочки умные слова из трех латинских букв.

          • Антон

            Ну прочитайте вопрос ещё раз и не по диагонали и не пропуская слов :) (ключевое слово — вебаппликации)

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

            А откуда Вы взяли, что, например, TDD требует много или значительно больше времени и, тем более, тестирование всего CMS — то же не ясно. Наверное, Вы путаете TDD с TestFirst-практиками. Но это не важно, многие путают, да и на трату времени тоже не сильно сказывается.

            • Я просто не понимаю, где вы веб-приложения взяли? Вроде я нигде об этом не говорил.

              Объяснить можно, но не всегда нужно. Я уже пережил тот момент, когда в каждый монастырь ломился со своим уставом. Если я вижу, что проект хороший и делать его нужно хорошо, то я делаю хорошо. Если клиенту нужно дешево и быстро, я не буду ничего объяснять или навязывать. Могу намекнуть, но не более. Возможно моя позиция неверна, но я выработал ее со временем и опытом. Идея «замятинского» счастья меня, слава богу, давно покинула и я стал более прагматичным.

              Нет, я TDD ни с чем не путаю. Но написание и прогон тестов — это время и оплачивать его никто не хочет. Я делаю ровно то, что за что платят. Тут я тоже не хочу сказать, что всем нужно относиться к задаче именно так. Каждому свое.

              По поводу того, как применять TDD можно долго рассуждать. Это отдельная тема и я, пожалуй, развивать ее не стану. Намедни читал пару топиков и комментарии к ним, ввиду чего перенасытился информацией на этот счет.

              upd: Перебирать проектами я тоже могу, но зачем отказываться от тех, где есть хорошее соотношение трудозатрат и получаемых материальных благ? Просто не вижу смысла усложнять себе задачу, тем самым переводя проект в убыточное для себя состояние.

Добавить комментарий для Мурашов Олег Отменить ответ

Ваш e-mail не будет опубликован. Обязательные поля помечены *