Некоторые инженерные практики для улучшения качества web application на PHP

    Этот топик мой ответ на жалобу одного человека, что «баги достали».

    Для начала, никакая методология положения не спасет. Начинать нужно с инженерных практик – внедрив их и почувствовав уверенность в своем коде можно внедрять любую методологию.

    Первые задачи могут быть такие:
    • Обеспечить интеграционное тестирование, чтобы каждое обновление на production не было головной болью.
    • Обеспечить регрессионное тестирование – чтобы выявленные ошибки не возникали опять (отслеживались автоматически).


    На мой взгляд, напрашивается внедрение Continuous Integration. Я не знаю, как ты сейчас собираешь проекты, но это делается не IDE, а с помощью тулов вроде Ant. Тот же Ant запускает автоматические тесты. Да, тесты начать писать это не очень просто, но ведь не нужно сразу все охватывать – внедрение CI точно не сделает в ваших проектах дополнительных багов.

    1. Самая лучшая статья про CI – это Мартина Фаулера: www.martinfowler.com/articles/continuousIntegration.html#EveryCommitShouldBuildTheMainlineOnAnIntegrationMachine

    2. Дальше – презентация «A Quick Start to Continuous Integration» — правда на примере phpUnderControl: sebastian-bergmann.de/archives/818-A-Quick-Start-to-Continuous-Integration.html

    3. Презентация о тестах PHPUnit и Selenium «Quality Assurance in PHP Projects»:
    sebastian-bergmann.de/archives/817-Quality-Assurance-in-PHP-Projects.html

    Вот конкретные инструменты – вроде эти нормальные, но сам смотри:
    1. xinc code.google.com/p/xinc — CI для PHP
    2. Phing – типа Ant для PHP
    3. PHPUnit — www.phpunit.de
    4. Selenium — en.wikipedia.org/wiki/Selenium_(software) – тестирование интерфейсов, интегрируется с PHPUnit
    5. SVN

    Ты говорил, что не представляешь как писать тесты – даже на самом сайте PHPUnit куча отличных статей: www.phpunit.de/wiki/ArticlesAndPresentations.
    А вообще хороший обзор Testing & QA на сайте фирмы МкКоннела:
    construx.com/Page.aspx?nid=208

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

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

    Я говорю о CI, т.к. считаю эту практику самой первой для внедрения. Всякие там метрики кода, проверка качества кода и т.п. только потом будут полезны (если вообще будут нужны). Ну а тесты писать нужно учиться (никто ведь не заставляет сразу в проект пихать) – материала в инете достаточно, в т.ч. для PHP.

    Удачи! Если будут какие-то идеи можно обсудить.
    Ads

    Comments 57

      +6
      К сожалению научиться хорошо программировать намного легче чем научиться программировать без ошибок или использовать автоматизированые тесты.

      Говорю на своем опыте.
      Да и тесты — они частно нафиг не нужны. Думаю отладить маленькие функции — проблемы нет.
      Года три назад к нам в офис приезжали tauSDL
      Model Driven Development of Complex Systems and Services
      Суть проста — собираете каркас програмы на SDL диаграме, разбавляете Скодом
      И получаете механизм на конечных автоматах…
      IDE строит дерево возможных использованией, а потом полурандомно начинает туда сигналы и пакеты кидать.
      Все ждет свихнется программа или нет.

      В общем на этом тау летают боинги и лифты ходят :)
      И мы тоже. За два года ниодного бага, ниодной проблемы.
      Все были ВЫРВАНЫ из кода роботом во время симуляции
        +1
        Это интересно.
          +1
          А в какой области вы работаете?
          Видимо эта Tau стоит бешеных денег и нужна для сверхнадежных систем?
            +2
            Тау стоит около 30к баксов.
            А работаем мы в телефонии, то есть там где конечные автоматы правят бал.
            На выходе имеем код в разы меньше и в разы надежнее
          +3
          Не планируете об этом статью писать? Думаю, многим было бы интересно.
            +1
            Уж полгода обещал как.
            Но к сожалению за это время писать статьи так и не научился
            хотя… попытка не пытка?
              –1
              Так ведь чтобы научиться, надо писать :) Я тоже вот пишу сейчас.
          +1
          ИМХО, тестирование хотя и полезная вещь, но для более успешного создания безбаговой программы важнее использовать хорошую архитектуру. Хорошая архитектура, в моем понимании, подразумевает высокую степень инкапсуляции и низкую степень сцепления между компонентами. Тогда, как правило, отладив один компонент, можно про него «забыть» до лучших времен, и вероятность того, что он «сломается», практически нулевая.

          Кроме того, есть еще два возражения, благодаря которому у меня тестирование не прижилось.
          1) Практическая невозможность тестировать пользовательские интерфейсы.
          2) Сильное понижение скорости разработки за счет написания тестов для нетривиальных компонент — которые работают с выводом, только в контексте системы, используют ввод пользователя и переменные сервера… В результате, у меня есть только 2 или 3 компонента, которые могут быть эффективно оттестированны — один из них — это «слой» между программой и БД.

          Ну, и еще о философском значении тестирования. Нас учили, что существуют несколько подходов к программированию — один из них — программирование как программная инженерия. Программная инженерия подразумевает, что есть архитектор и много-много кодеров, почти как при создании реального здания. Практика тестирования, хочу заметить, развивалось именно в рамках этого подхода. Она там практически необходима для того, чтобы контролировать «кодеров». Это не значит, что она не полезна в рамках других подходов. Но это значит, что существуют и другие подходы, например, программирование, как искусство создания кода. Понятного кода, который практически не нуждается в тестировании, и понятной архитектуры.
            +2
            Хорошую архитектуру очень важно использовать, но это ни уменьшает значения _интеграционного_ тестирования. Трое достаточно шустрых программиста способны разнести любую архитектуру очень быстро, ContinuesIntegration и UnitTest в том числе, позволяют следить, за тем чтобы этого не случилось. Также следить за этим помогают все практики направленные collaborations.
            По поводу возражений, соглашусь, всегда нужно думать что собираешься тестировать.
            Последнюю мысль не понял.
              0
              Прошу прощения, не сразу понял, что имелось ввиду под ContinuesIntegration.

              Фактически, постоянно использую именно только эту практику. С юнит-тестами, как уже писал, не сложилось, но, возможно, у меня просто не было ситуаций с 3 шустрыми программистами. В данном случае меня скорее спасают интерфейсы и соглашения. Выполняй — и все работать будет.
              +1
              при правильной архитектуре, проблем с подцепкой тестов не должно возникать., на то она и _правильная_. тем более если у вас низкий уровень связанности, тогда компоненты тестировать и вовсе плёвое дело. Проблемы возникают когда связанность большая.
              >> 1) Практическая невозможность тестировать пользовательские интерфейсы.
              не обязательно покрывать тестами всё приложение, главное бизнес логику тестить.
                0
                >> при правильной архитектуре, проблем с подцепкой тестов не должно возникать., на то она и _правильная_

                Очень верное замечание, честно говоря, в исходном комментарии я немного слукавил :)

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

                Характерную ситуацию можно описать так: ядро создает обьект с помощью фабрики, затем вызывается метод, который настраивает объект другой фабрики, выдающий HTML-код некоего элемента управления. Причем сам элемент управления не является неким статичным HTML-кодом — он как раз может и должен меняться (View в модели MVC). Фактически, этот код и является результатом выполнения функции. Вопрос — как это грамотно протестировать?

                  0
                  ты должен отдельно тестить, обект подготавливающий данные и отдельно вьюху. ты же сам писал о низкой степени связоности, разделяй и властвуй. падовая известные значения в оба объекта по отдельности, ты можешь знать что получится на выходе, другое дело если их пытаться тестировать скопом, так даже не узнаешь в каком звене цепочки произошёл сбой.
                +1
                Что касается веб-интерфейсов, то вопрос решается Selenium RC например, и других много тулов.
                Хотя я согласен, что не все нужно и можно протестировать, но все-таки подход «архитектор-кодеры» плохо срабатывает, т. к. невозможно ручками контролировать все аспекты системы.
                  +1
                  А еще лучше использовать хорошую архитекту покрытую тестами. Более того, тесты могут косвенно влиять на саму архитектуру в дальнейшем (т. к. со временем вы будите заранее, либо писать тесты, либо думать о том, как покрывать тестами тот или иной компонент, что в свою очередь будет приводить к малому сцеплению между компонентами). К сожалению, или к счастью если вы занимаетесь проектом не один, и проект развивается, то компонентов которые бы остались в совершенно неизменном виде с момента их первоночального написания остается крайне мало, а проверять каждое изменение вручную в итоге выйдет дольше, кроме того на одной из проверок кто нибудь, что нибудь обязательно забудет предусмотреть.

                  1) Практическая невозможность тестировать пользовательские интерфейсы.

                  Вобщем-то автор статьи указал на решение.

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

                  TDD, является частью XP и часто приминяется вместе с практиками Agile, что само по себе противоречит «архитектор и много-много кодеров», а динамитом, некто Нобель тоже сначала планировал деревья корчевать, да завалы разбирать.

                  Но это значит, что существуют и другие подходы, например, программирование, как искусство создания кода. Понятного кода, который практически не нуждается в тестировании, и понятной архитектуры.
                  Звучит красиво, но уж очень похоже на идельный мир, а проекты живут в мире реальном, где случаются глюки, люди ошибаются, а софту, если он хочет быть надежным софтом, лучше все же быть протестированным.
                    0
                    Вторично прошу прощения — не сразу разобрался, что подразумевается под словом ContinuesIntegration. По сути, использую только эту практику. От использования юнит-тестов спасает использование интерфейсов и соглашения. Собственно, это и подразумевалось под хорошей архитектурой.

                    Насчет частого изменения компонентов — с вашим замечанием согласен. Однако я работаю в такой ситуации, когда мои компоненты используются в разных системах, в том числе и устаревших. В результате, я использую нечто вроде принципов COM — один раз определенный интерфейс _никогда_ не меняется. Если нужно использовать что-то более сложное («апгрейдить» компонент), то пишется второй интерфейс.
                    0
                    Я всегда считал, что при использовании TDD получается (сама собой) лучшая архитектура, чем без него, т. к. «testable» код подразумевает низкую степень сцепления.
                    +6
                    Автор, а почему Вы разговариваете на «ты» с Вашим читателем?

                    А в целом соглашусь. Вы правы. Единственное, что не понравилось — выражение «Самая лучшая статья про CI». Кто же это решил, что она самая лучшая? Лично Вы или же есть статистика голосования (которую можно глянуть)?
                      +1
                      если один авторитетный специалист сказал что статья лучшая, то значит она лучшая. а вот какое бы там не было голосование, оно все равно останется необоснованым и необъективным. степень авторитетности и знаний специалиста — это уже отдельный вопрос и как правило он решается при тесном общении с человеком, желателько в единой с ним рабочей среде. лично я задумаюсь и приму к сведению мнение авторитетного для меня специалиста, и не обращу внимания вообще на какие бы то нибыло голосвания хоть на хабре или где-то еще…
                        +2
                        В данном случае у меня нет ни каких данных об авторитетности автора в данной сфере.
                        +5
                        +1. WIndows — лучшая операционная система :-D
                          +2
                          На «ты», т. к. «Этот топик мой ответ на жалобу одного человека, что «баги достали».» — это письмо другу если хотите.
                          Про статью Фаулера — да, это мое мнение, что она лучшая по CI. Т. е. лучше написать было «По моему мнения это самая лучшая статься по CI»…
                            0
                            Еще не все потеряно, и Вы можете это отредактировать.
                              0
                              А из того факта, что статья авторская, вы не делаете вывод, что любое в ней мнение — тоже авторское? Не добавили «имхо» — значит претендуем на вселенскую истину? Что за фарисейские придирки?
                                0
                                Что же вы так нервничаете. Я вовсе и не придирался. В первом случае, я просто сказал, что мне не нравится. Вот втором комментарии просто напомнил, что коль вы решили, что лучше было написать по другому, то можно отредактировать.

                                Абсолютно не придираюсь. Не нервничайте. Желаю добра ;)
                            +1
                            Кстати многие менеджеры просто советуют обращаться на ты что бы быть ближе к человеку, а так же психологи советуют.
                              +1
                              А мне не хочется, что бы посторонние люди (для меня) были ближе. Об этом Вы не думали?
                                0
                                Есть свободная берлога, будешь заселяться?
                                  –1
                                  Это Вы к чему? Видимо в свою очередь я мог бы ответить — «Есть свободное место в углу, около тех трёх не приятно пахнущих бомжей, ложись рядом!». Мог бы, но не буду.
                                    0
                                    Я буду! :0)
                              +1
                              Де-факто, тестирование, и гибкая разработка, нужна лишь программистам/компаниям, играющим по взрослому.

                              Теперь зададим себе вопрос: а что такое тест? По-сути, это некоторый код, который запускает другой код (в цикле, с разными параметрами конфигураций и т. д). Ловит исключения, регистрирует их.

                              Так вот у меня вопрос: много людей, которые не делают этого? Т. е. не пишут стартер для классов?
                                +1
                                Юнит тест — это стартер на каждый класс и на большинство методов. Юнит тест в рамках TDD это сначала стартер, а потом уже класс.
                                  +1
                                  Но когда нужно запускать например 1000 классов, да даже если 50, то очень удобно :-)
                                  +3
                                  * ContinuesIntegration и UnitTests работают не только в отношении web applications и PHP — это о связи содержания с заголовком.
                                  * Регрессионное тестирование и юнит тестирование — это разные вещи.
                                  * UnitTest наиболее сильна, если ее применять в рамках TDD (Test Driven Development), иначе может иногда даже в пустую отнимать время. Как обычно, весьма сложно покрываемая юнит тестами область — пользовательские интерфейсы и даже упомянутый в статье selenium позволяет решить проблему только в небольшой части. Еще избавить код от непроверенных комитов позволяют такие практики как CodeReview и PairProgramming (вместе не применять :))
                                  * о СontinuesIntegration имеет смысл говорить если у вас 3 и более разработчиков, одновременно комитящих код, в остальных случаях, если это не налаженная ранее система, то потеря времени.
                                  * начиная всерьез внедрять эти практики, Вы уже начали думать о методологии :)
                                    +1
                                    1. Конечно не только для web applications и PHP. Про связь названия и содержания не понял — разве есть несоответствие?
                                    2. Почему разные. ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%B3%D1%80%D0%B5%D1%81%D1%81%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B5_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
                                    думаю, что запуская юнит тесты при каждой сборки мы как раз удостоверяемся что старые ошибки снова не возникли. А еще если синтегрнировать с Selenium RC то можно и на уровне интерфейсов проверять.
                                    3. Возможно.
                                    4.
                                    5. Но методология без практик мертва. Поэтому я и советую сначала сконцентрироваться на практиках. Так никакой Scrum сам по себе не сделает код качественнее.
                                      +1
                                      1. Да, наверно я придираюсь :)
                                      2. Потому что регрешен можно (и нужно) осуществлять не только юнит тестами, а юнит тесты служат не только для регрессии.
                                      5. Scrum это agile планирование, он не поддерживает ни одной инженерной практики и не занимается вопросами кода в принципе.
                                    +3
                                    всё уже найдено… и всё хочется попробовать… но вот пробовать надо на живых примерах. А там сроки, делайны, которые не хочется срывать. Всё не пойдёт гладко. А заставить всех программистов самообучаться новым технологиям вне рабочего времени — смерти подобно…
                                      +1
                                      Спасибо за ссылки, а что насчёт phpUnderControl?
                                        –1
                                        xinc мне более симпатичен — он специально для PHP.
                                        А CruiseControl большая дурка, в которой сложнее разобраться.
                                        –2
                                        Автор, web application — это веб-приложение. Учите русский, не надо мешать языки. Либо целиком на английском пишите.
                                          +2
                                          А вэб-приложение — это чисто на русском чтоли?
                                            +1
                                            Конечно. Толко не вЭб, а веб. Слова «веб» и «приложение» имеются в русском языке. Что вас смущает?
                                              –1
                                              слово веб — в русском языке?
                                                +1
                                                Любой язык — это динамическая структура, постоянно пополняющаяся новыми словами. Безусловно, слово «веб» есть в русском языке. Ведь такое явление, как веб, надо обозначать каким-то термином, верно?
                                                  –1
                                                  но тогда почему Вэб — неправильное слово?:)
                                                    –1
                                                    В любой поисковой системе введите по очереди оба слова и посмотрите на каком количестве страниц каждое из них присутствует. Так же обратите внимание какие источники используют тот или иной вариант написания. Думаю, у вас отпадут все вопросы.
                                                      –1
                                                      по вашей логике, кол-во страниц на слово х*й и пи*да (в сумме) должно быть такое же, как и на слово ж*па, потому что их количество в мире равно =)
                                                      это я к тому, что не все измеряется кол-вом результатов выдачи поисковика.
                                                        0
                                                        Вы сделали, как я предложил, или сразу ответ написали? Только честно. По слову «вэб» вообще Внешэкономбанк находится, а по «веб» — то о чем мы с вами говорим, причем этот вариант используется авторитетными источниками.

                                                        Вообще конечно здорово: я вам про русский язык, а вы мне про гениталии :-/ Предлагаю закончить дискуссию на эту тему, ее никому не интересно читать кроме нас с вами.
                                                          0
                                                          еще и долбоебы минусуют =)

                                                          по ссылкам сходил, мне понравилось:
                                                          Вэб-инвест Банк
                                                          www.web-***.ru/

                                                          таки слово web у некоторых читается как вэб =)
                                                            0
                                                            Слово «класть» тоже у некоторых читается как «ложить» ))) Все, ушел работать.
                                                              0
                                                              удачной работы =)
                                          0
                                          eclipse с phpunit дружит?
                                          вообще хотелось бы вменяймое сравнение simpletest vs phpunit для того чтобы иметь возможность сознательного выбора
                                            +1
                                            ZendStudio дружит.
                                            Сравнение? Наверное, вот. Имхо, критерии достаточно вменяемы.
                                              +1
                                              Держи, коллега :) piece-framework.com/projects/makegood
                                                0
                                                уже не актуально :)
                                                  0
                                                  Тьфу ты блин, забылся в какого года я топике :)
                                              0

                                              Only users with full accounts can post comments. Log in, please.