19 мая 2012 в 04:25

Стоит ли смотреть в сторону PHP тому, кто решился только со второй попытки научиться прилично программировать?

PHP*
Здравствуйте, друзья. С большой осторожностью касаюсь столь холиварной темы, но хочу рассказать свою небольшую историю о том, почему я, будучи уже далеко не в студенческом возрасте, решил всё-таки изучать программирование, и от чего же я собираюсь (о, боже) использовать для реализации своих намерений PHP. Буду рад получить от вас, коллеги по IT-индустрии, ценные советы и наставления.

Забегая вперёд скажу, что в комментариях к топику (кроме холиваров о языках) сказано много полезного. За что огромное спасибо хабровчанам.

Личный опыт

Моя карьера складывалась не самым типичным образом: я постоянно работал сразу в нескольких организациях и почти всегда на свободном графике. Почему меня всюду терпели? Похоже, что за универсальность: мог своими руками проложить сеть, настроить офисный сервер на Debian`е, мог в CorelDraw нарисовать аккуратную листовку, подготовив её к печати с цветоделением, мог обучать пожилых сотрудниц «входить в интернеты», мог нарисовать и сверстать шаблон для CMS и в одиночку за пару недель развернуть для компании небольшой сайт, мог чего-то по месту автоматизировать написанными на коленке программами, когда становилось ясно, что несколько рутинных операций в разы тормозят весь рабочий процесс отдела или конторы в целом. Мог и всё это делал.

Гордиться тут особо нечем, как вы понимаете, узкоспециализированным профессионалом ни в одной из затронутых отраслей я так и не стал, а стал этаким универсальным IT-многоборцем, человеком-окрестром среднего звена, который появляется и максимальную пользу приносит там, где в небольшом коллективе надо решить сразу много проблем. На жизнь, впрочем, вообще не жалуюсь, потому что некоторое время назад удалось запустить свою небольшую, но развивающуюся региональную веб-студию. И там я сам себе проджект-менеджер. Разрабатываем мы, в основном, на CMS Drupal и реже на фреймворке Yii, которые, как известно, на PHP писаны.

Сейчас мне, откровенно говоря, немного неловко управлять парой достойных программистов, чей JS и PHP код я понимаю лишь на 20%.

Университет и многие места работы научили меня основам трёх языков: C++, Java и PHP. Ну, как научили, я всего-то знаком с базовыми алгоритмическими конструкциями, могу отсортировать массив десятком методов (из-за курсовика, написанного по этой теме), понимаю как устроены стеки и очереди, на уровне концепций и учебных задач знаком с ООП. В общем, программированием владею как заурядный, но прилежный студент средненького технического вуза. Зато на практике почему-то меня всегда выручал именно PHP, притом заманивая своими самыми жжёными печеньками с тёмной стороны.

Я писал на PHP шелл-скрипты для коррекции длинных табличных отчётов через PHPExcel, парсил сайты без API сначала регулярками, а потом уж и с использованием phpQuery, быдлокодил (мешая вёрстку с логикой) веб-странички выводящие в интернет актуальные цены из локальной MSSQL-базы складской системы, мастерил всякие конвертеры из разряда «вот сюда вы неправильный файлик загрузите, а потом правильный по этой ссылочке скачаете и там уже сумма будет прописью». В общем, сколько бы я не заставлял себя использовать правильный язык и правильный подход при решении какой-то практической задачи, всегда всё скатывалось к тому, что решение, достаточно быстро и безобразно на уровне архитектуры (без всяких ООП и MVC), создавалось на PHP. При этом снаружи решение выглядело работоспособным и вело себя, увы, тоже как вполне работоспособное. Это всех устраивало, даже меня, потому что придаваться рефлексии и проклинать себя за несоблюдение эстетики — было некогда.

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

Но с чего заново начать, чтобы расти правильным программистом? Вот этого я — не знаю. По PHP я вообще не читал книжек, а учился по коду из статей с комментариями, разбросанному в сети. По Java помню книжку, которая мне понравилась — её автор Хабибуллин. Но эта книжка не учит стилю и правильным подходам, хотя и доступно знакомит с языком и платформой. И книжка не про PHP.

Что делать?

Какой диагноз поставите, коллеги? Можно ли вообще, по вашему мнению, переучиться программировать или, торопясь побыстрее решать рутинные задачи, я бесповоротно сам себя заклеймил на роль вечного «похапэшного быдлокодера»?

Какие первые шаги, по вашему, мне теперь стоило бы совершить: что почитать, какие практические задачи решить, какие табу себе поставить?

P.S. И, чтобы два раза не вставать, задам уж совсем, наверное, смешной вопрос: какую IDE вы посоветуете использовать? Я, стыдно признаться, все мегабайты своего кода написал в PSPad и протестировал в браузере кнопочкой F5, читая про ошибки и нотисы и возвращаясь снова их исправлять в редактор. А как и в чём отладку ведут правильные программисты?

P.P.S. Проще лечить больного по известным симптомам, поэтому, пожалуй, приведу несколько примеров, иллюстрирующих бардак в моей голове. Задам некоторые глупые вопросы, не дающие мне покоя:

1. Приведите минимальный пример, который иллюстрирует модель MVC, так чтобы были видны практические профиты от её применения?

2. Говорят: пишите безопасный код. Но каковы базовые правила? Я, например, понимаю, что если то, что пришло через GET или POST без проверки и обработки отправлять в SQL запрос, то быть беде. Но какие ещё бывают типовые косяки в безопасности, которых стоит сразу же бояться и не допускать как SQL-инъекций?

3. Я встречал несколько разных гайдов по форматированию кода. Они порой постулируют противоречивые вещи. Есть ли где-то хотя бы один русскоязычный гайд, где для каждого пункта приводилось бы пояснение в духе «надо оформлять вот так, потому что это решает такие-то проблемы»?

Промежуточные результаты

В комментариях Juraseg посоветовал «Совершенный код» Стива Макконнелла и сразу несколько человек посоветовали «PHP Objects, Patterns and Practices». К сожалению, английский мой слаб, поэтому буду читать перевод.

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

Многие люто рекомендуют и поддерживают JetBrains PHP Storm в качестве самой правильной IDE для PHP.

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

Ну, и, многие советуют таки забить на PHP и смотреть в сторону других языков, в основном, в сторону Python. На эту тему понравился философский комментарий от LayneBuchyn о том, что для того, чтобы толсто троллить объективно критиковать PHP, надо отлично знать PHP.
Алексей @smartup
карма
10,0
рейтинг 0,0
Самое читаемое Разработка

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

  • +30
    IDE — PHPStorm от JetBrains.
    • 0
      Я про неё слышал, но купить пока не надумал. Подходил и к таким снарядам как NetBeans и Eclipse, но они мне казались большими монстрами. Можете ли ткнуть в какой-то скринкаст или описать в нескольких предложениях, как дебаг происходит в PHPStorm? К нему ставится локальный веб-сервер и где-то уже в недрах IDE перехватываются его ответы и в каком-то своём окошке показываются?
      • 0
        Я с PHP уже полтора года как не общаюсь, но на сайте JetBrains есть скринкасты.
        Более того, доступен 45-тидневный trial.
        • +1
          Если жалко денег на phpstorm, могу посоветовать посмотреть в сторону eclipse pdt (можно, грубо выразившись, сказать, что это бесплатная альтернатива).
          • +2
            Вы уж извините, но Eclipse не альтернатива PhpStorm'у =)
            • 0
              Вы уж извините, но я же грубо выразился.
              • 0
                Не заметил. Действительно.
                Надо читать внимательнее.
        • +2
          30-дневный
      • +1
        И да, очень обидно, что называете Eclipse монстром, он на самом деле не страшный и очень дружелюбный. PDT вполне себе был удобен для программирования на PHP, когда я за него брался. Хотя других редакторов я не использовал, по инерции пересел на него после Java.
        • +1
          Простите, что так обидел ваш любимый инструмент, это я от не знания. Как я написал, я за на него смотрел не со стороны другой IDE, а стороны текстового редактора с подсветкой синтаксиса.
          • 0
            Да все в порядке, кстати, в плане подсветки (тоже есть такой пунктик) Eclipse и вправду не очень хорош. Я подсел на sublime 2 — он божественно красив, если ищете именно это, посмотрите, тут даже много постов было про него. Кроме всего прочего, к нему очень легко писать плагины на Питоне.
      • +2
        У них вечный 45-дневный триал. Когда надоест качать новую версию раз в 45 дней можно и купить. Но де-факто она бесплатна.
      • 0
        Настройка дебага описана здесь:
        blog.jetbrains.com/webide/2011/02/zero-configuration-debugging-with-xdebug-and-phpstorm-2-0/

        Отдельный сервер ставить не нужно, PHPStorm перехватывает ответы от вашего локального сервера через XDebug. Т.е. выполняется всё прямо в браузере, а по брейкпоинту управление передается в IDE
      • +1
        почитайте статью о NetBeans tips & tricks
  • +4
    Хочется учить — учите, PHP не очень сложный язык. Почитайте про паттерты и техники программирования в целом, ибо синтаксис выучить не очень сложно, а научиться писать эффективный хороший код — искусство. Хорошо бы знать какой-нибудь фреймворк (Yii, Symfony и т.д.), дабы не городить свой велосипед (хотя, для начальной стадии обучения, это даже минус).
    Если Вам только кажется, что PHP — лучший язык для обучения, то я бы посоветовал почитать что-нибудь про мейнстимовые языки — python, ruby, C# и т.д. Не холивара ради, но они кажутся мне более гибкими и эффективными (сам пишу на C#).
    Также, конечно, будет неплохо знать html, css, javascript. А так, имхо, никаких проблем — сидите и учите.
    • +5
      Также, конечно, будет неплохо знать html, css, javascript.

      Путь человека-оркестра никогда до добра не доводил.
      Либо ты backend-разработчик (php/python/ruby), либо frontend-разработчик/верстальщик. Хотя основы верстки и JS конечно знать надо, но углубляться не стоит, потому что тем самым вы отвлекаетесь от основного направения — backend, а это нехорошо.
      • +1
        > Путь человека-оркестра никогда до добра не доводил.

        Ну да, и я тому пример. У меня не только бэкенд с фронтэндом смешались, а гораздо более сложный и ядовитый коктейль вышел. Но вот теперь надо выбираться :-)
        • +1
          Зато в качестве менеджера имеете много плюсов в виде понимания процесса с разных сторон
        • +5
          … или углубляться. Не секрет, что в нашей сфере дефицит на хороших разработчиков есть и по всей видимости еще долго будет. Но разработка это не вещь в себе, это не конечная цель. Разработка и разработчики призваны решать бизнес задачи. Что бы решать эти задачи с прибылью требуются люди которые видят четкий вектор и могут ему следовать.Что бы такое виденье было нужен широкий кругозор. Даже ведущего разработчика можно заменить, но вот такого человека с вектором заменить как правило некем. Этих людей не хватает просто катастрофически. Уход ведущего разработчика, особенно в PHP большая конечно проблема, но она решаема. Уход координатора проекта как правило означает угасание проекта.
      • +1
        Поэтому я и написал в самом конце под грифом «неплохо знать». В общих чертах, чтобы понимать написанное, я считаю, знать нужно. А так Вы правы.
      • +1
        По-моему, если сформулировать основное направление как «разработка интернет-проекта», то становится понятно, что можно и нужно уметь делать все. Кроме себя любимого, знаю еще один чудесный пример, когда в конторе сидит 2 дизайнера, флешер, 2 менеджера и 1 программист. И, хочу доложить, неплохо справляется со сложными проектами. Это я не про сайты-визитки сейчас
        • 0
          Могу поспорить что в ближайшее время он либо устанет, либо потребует неплохую прибавку к зарплате.
          • +5
            Усталость — это да ;)

            А ваша позиция — хоть и не лишена здравого смысла, но все же слишком категорична.
            Эволюция «через оркестр» имеет три пути:

            1. Одна область → Еще области (нахватываем) → Нихрена не получается → Останавливаемся на чем-то одном
            2. Одна область → Еще области (нахватываем) → Более-менее получается всё → Остаемся оркестром среднего уровня
            3. Одна область → Еще области (нахватываем) → Получается всё → Становимся CTO (Chief Technology Officer)

            CTO ОБЯЗАН хорошо уметь делать всё.
            Это я вам, как прошедший третий путь, говорю.
            Конечно, людей, которые могут охватить множество областей одинаково хорошо — не так уж и много, но если есть хотя бы мысли о том, что ты можешь буть универсален, НУЖНО пробовать стать оркестром, иначе имеешь шанс загубить в себе CTO. А их ооой как не хватает
            • 0
              А CTO это технический специалист больше или администратор/менеджер?
              • 0
                Тут сильно зависит от структуры организации и рабочего процесса, но вообще больше технический.
                Менеджер — с точки зрения управления процессом разработки и планированием её же (а также бюджетированием оного).
                Административные функции — это функции менеджеров проекта (аккаунт-менеджеров тобишь)
                • +2
                  CTO по сути аналог нашего названия «технический директор».
                  • 0
                    да
      • +1
        Полюбопытствуйте node.js, backbone.js и иже с ними. Это как раз пример того, надо ли backend разработчику знать JS.
        • 0
          а backbone-то за что в backend?
      • +10
        Если работать на кого-то, то да — лучше как иметь наиболее узкую специализацию.
        Если работать на себя — необходимо быть человек-оркестром.
    • 0
      А вы можете предложить какие-то русскоязычные статьи про паттерны и техники, которые именно вам кажутся дельными и понятными?

      Ведь на том же быдлокодерском уровне я знаю html, css (как и писал: могу сверстать несложный шаблон и натянуть его на CMS). Немного знаком и с API Yii, но я, например, не могу читать его исходники и извлекать оттуда опыт или познавать на его примере архитектуру.
      • 0
        Как минимум надо отлично понимать, что такое MVC и MVVM.
        Я много времени программировал (и программирую) на C++, поэтому львиная доля знаний пришла ко мне не из веб-разработки. Отличный список книг представлен на stackoverflow (например, Design Patterns by the Gang of Four). Вот в этом тредике дают хорошие советы о книгах для PHP-разработчиках (о «PHP Objects, Patterns and Practice» я слышал много хорошего).
        • +1
          Спасибо Вам за ссылки.
          Нашел для себя онлайн вариант книги, которую искал очень давно. В каком то книжном магазине наспех пролистал её, денег с собой не было, решил потом зайти. В итоге зашел, её нет, названия не помню. Аналоги, которые находил в сети, были не то. А по Вашей ссылке нашел её, вот собственно сабж commons.oreilly.com/wiki/index.php/PHP_Cookbook
          Еще раз спасибо!
          • 0
            Успехов в изучении ;)
  • +6
    Не холивора ради, но попробуйте всё-таки попробовать начать изучение, например, с того же Питона. В крайнем случае можете изучать его параллельно с PHP, к примеру, можно поставить себе цель писать одни и те же примеры на обоих языках, в любом случае это будет неплохой практикой и даст прививку от прикипания к одному языку.
    • 0
      > прививку от прикипания к одному языку

      Да, возможно, я этим недугом страдаю :-)
      • +2
        Попробуйте python в сочетании с Django — должно понравится, да и документации по них дохрена.

        А вообще, diamant чуть ниже правильно написал — если вы много всего знаете, понимаете процессы, но в общих чертах, из вас может получиться хороший начальник. Начальник должен понимать и оценивать масштабы работы, а не заниматься деталями реализации.
  • +11
    А зачем тебе становится правильным программистом? Узкая специализация — она же не всем и не всегда нужна. Судя по описанию, ты — организатор (менеджер, начальник), который знает обо всём понемногу и чуть-чуть умеет делать всё. А где не хватит собственной квалификации, можно нанять разбирающегося человека.
    Находи узких специалистов и задачи для них, организовывай свой бизнес — если это интересно, конечно.
    • +1
      В общем, как в топике написал, этим-то я сейчас и занимаюсь, на жизнь как раз вполне хватает. Программировать хочется скорее для души. Ну, и, кроме того, я думаю, что смогу эффективнее взаимодействовать с нанимаемыми разработчиками, когда сам буду более квалифицирован в их области.
      • 0
        Судя по описанию в посте, все проекты у вас — на PHP. Поэтому, если говорить о целях взаимодействия с разработчиками, то нет и вопроса о выборе изучаемого языка.
        А вот что вам нужно для души — этого знать никто не может. В мире не было бы многих сотен ЯП, если бы у разных людей душа не лежала к разным вещам :)
      • +3
        Солидарен с diamant. Когда читал, то первая мысль которая возникает «зачем?». Если есть опыт практического использования и получаются работающие решения, то это нормальный инженерный подход. В погоне за всеми этими красивыми аббревиатурами разработчики зачастую забывают, что это не самоцель. Все эти подходы были придуманы и используются ради упрощения и ускорения разработки. Всякие «архытэктары» поназаворачивают вычурные патерны, магические методы и кучу другой магии, а потом это все мало того, что тормозит, так еще младшие разработчики с этим работать не могут. А реалии веб студии таковы, что нужные младшие и средние разработчики которые могут дешево и быстро производить продукт. И рассчитывать нужно в первую очередь на них.

        Поэтому лично я бы рекомендовал двигаться совершенно в других направлениях. Два варианта у меня с ходу есть. Если есть желание написания кода для души, то пусть он приносит пользу людям, в конечно итоге в этом работа инженера и состоит. Поэтому есть смысл создавать полезные для людей веб сервисы. Реализация в виде кода при этом не принципиальна, главное полезное и работающее решение. При этом высока вероятность, что паттерны о которых все говорят таки будут в нем применяться. Но дойти до них получится самостоятельно. А второе направление я бы связал с профессиональной деятельностью. Предлагаю расширять степень охвата областей. Т.е. заняться связанными сферами, копнуть там больше в сторону администрирования, к примеру, или заняться бухгалтерией.
  • –19
    Как бывший ПХПшник советую не забивать себе голову глупостями и функциональщиной (вы ж не студент и лишнего времени у вас скорей всего нет) а сразу начинать с Ruby (and Rails). Я уже 4 года на нем и ПХП вижу только в страшных снах. Очень интуитивный и легко изучаемый язык. Плюс до упора ООП

     > 1.class
     => Fixnum 
     > true.class
     => TrueClass 
     > 1.methods
     => ["%", "odd?", "inspect", "prec_i", "<<", "tap", "div", "&", "clone", ">>", "public_methods", "object_id", "__send__", "instance_variable_defined?", "equal?", "freeze", "to_sym", "*", "ord", "+", "extend", "next", "send", "round", "methods", "prec_f", "-", "even?", "singleton_method_added", "divmod", "hash", "/", "integer?", "downto", "dup", "to_enum", "instance_variables", "|", "eql?", "size", "instance_eval", "truncate", "~", "id", "to_i", "singleton_methods", "modulo", "taint", "zero?", "times", "instance_variable_get", "frozen?", "enum_for", "display", "instance_of?", "^", "method", "to_a", "+@", "-@", "quo", "instance_exec", "type", "**", "upto", "to_f", "<", "step", "protected_methods", "<=>", "between?", "==", "remainder", ">", "===", "to_int", "nonzero?", "pred", "instance_variable_set", "coerce", "respond_to?", "kind_of?", "floor", "succ", ">=", "prec", "to_s", "<=", "fdiv", "class", "private_methods", "=~", "tainted?", "__id__", "abs", "untaint", "nil?", "chr", "id2name", "is_a?", "ceil", "[]"] 
    
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Вот это выше массив с методами.
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Запускаете интерпретптор коммандой irb. Выполняете:
            1.class
            
            получаете:
            Fixnum
            
            То же для true.

            Если есть свободные 10 минут посмотрите видео
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                В рельсе все делается очень легко и просто причем не в ущерб качеству. К примеру мы сейчас работаем над проектом у которого в продакшне более 20млн хостов в сутки и база под терабайт. Приложение очень большое и сложное, разрабатывается около двух лет, при этом мы постоянно наращиваем функционал и не особо вязнем в коде.

                Если интересно посмотреть более подробную инфу по рельсе рекомендую railscasts.com Там как раз про кастомные штуки.
                • НЛО прилетело и опубликовало эту надпись здесь
                • 0
                  сколько серверов держит это все добро?
    • +5
      def bad_example( a = «Тема», b = 'руби', c = 'не', d = 'раскрыта', message = [a,b,c,d] )

      10.times.map { message.join(" ") }.join("! ")

      end
      • +1
        image
        _________
        best regards
        KO
        • +2
          Хм. Холивар двух рубистов в хабе PHP? Сильно.

          Я не том, что ваш пример плох, а о том, что он не очевиден для того, кто с ruby не знаком. (_не очевиден_ != непонятен).

          кстати, почему PHP — «функциональщина»?
          • –12
            Ну, руби изначально ООП. А в PHP он какбэ прикручен что-ли. Язык больше заточён под функциональное программирование. Правда я могу быть не прав т.к. PHP очень давно не занимаюсь и не слежу за последними веяниями. В общем не сильно в курсе что там сейчас. Но когда я на нем писал (писал не хомяки если что) функциональное программирование преобладало.
            • +6
              Функциональное программирование — это совсем не то же самое, что процедурное программирование. Думаю, вы имеете в виду второе.
              • –13
                Возможно. В терминологии я не силен :)
            • +3
              Если так рассуждать, то детские болезни руби (< 1.9) тоже придется предъявлять: тормозной, память жрал (угу, был еще ree). 4 гига 4 ядра, а rake еле ползает… Оба языка сильно поменялись, как и комьюнити. ruby 1.9.3 и php 5.3(4) несколько отличаются от своих давних предков. Конечно strlen и str_replace, как и $ остались. Куда ж без них. Но ООП у пхп вполне имеется. Как и неймспейсы, которых я так ждал и не дождался.

              coffescript like враппер над php для убирания рудиментов? )))) Заодно; под нож )) (irony?)

              Мне конечно руби намного больше нравится, но я бы не сказал, что процесс перелезания на него полностью оправдан и тем более, что это просто. Многим этого просто не нужно, и говорить что они пишут на плохом языке — еще с 5 версии неверно.
          • +1
            Руби программисты они во всех хабах к сожалению.
            • +1
              Ещё они очень злые, да.
    • +1
      image Это я конечно не учел, что упоминать Ruby там где в тексте over 9000 включений PHP, чревато ;)
      • +1
        Так и хаб соответствующий же.
        • 0
          Хаб как раз хороший пример того, что написать хорошее приложение можно на любом языке. Просто для определенных целей есть инструменты более или менее удобные. Но в итоге все равно приложение пишется программистом а не языком.
    • +4
      WTF на каждой ответной строчке. True оказывается не булевый класс, а TrueClass. В методах для чисел по большей мере нечисловая ахинея. В Python, для сравнения:
      In [1]: type(True)
      Out[1]: bool
      
      In [2]: type(42)
      Out[2]: int
      
      In [3]: ', '.join(dir(42))
      Out[3]: '__abs__, __add__, __and__, __class__, __cmp__, __coerce__, __delattr__, __div__, __divmod__, __doc__, __float__, __floordiv__, __format__, __getattribute__, __getnewargs__, __hash__, __hex__, __index__, __init__, __int__, __invert__, __long__, __lshift__, __mod__, __mul__, __neg__, __new__, __nonzero__, __oct__, __or__, __pos__, __pow__, __radd__, __rand__, __rdiv__, __rdivmod__, __reduce__, __reduce_ex__, __repr__, __rfloordiv__, __rlshift__, __rmod__, __rmul__, __ror__, __rpow__, __rrshift__, __rshift__, __rsub__, __rtruediv__, __rxor__, __setattr__, __sizeof__, __str__, __sub__, __subclasshook__, __truediv__, __trunc__, __xor__, bit_length, conjugate, denominator, imag, numerator, real'

      • 0
        Да, пайтон тоже отличный язык. Но для меня как рубиста там тоже огромное количество непонятных и неочевидных вещей. Например почему
        len(myList)
        

        А не
        myList.len
        

        (про __len__ я в курсе если что). Просто языки разные же.
        И да. Про ахинею. У большинства классов есть родительские и у них есть свои методы. Могу подробно описать вам каждый метод чтоб вы могли убедиться что ахинеи там нет. Но думаю что подобное описание немного выходит за рамки обсуждаемой темы.
        З.Ы. И да, то что пример не явный и не совсем удачный я уже понял. Прошу прощения если задел чьи-то чувства.
  • 0
    > люблю изучать разные платформы
    Хорошая привычка. Я как раз пайтон ковыряю в свободное время =)
  • +1
    > Но какие ещё бывают типовые косяки в безопасности, которых стоит сразу же бояться и не допускать как SQL-инъекций?

    Основной принцип — не доверять данным, приходящим от пользователя, т.к. подсунуть могут все что угодно (да-да, как с SQL-инъекциями).

    file_get_contents($_GET['page']);
    require($_COOKIE['data']);
    imageCreate($_POST['width'], $_POST['height']);
  • +1
    Как-то открыл для себя существование прекрасного (на мой взгляд) редактора (и IDE) Komodo Edit
    К сожалению встроенные дебаг-интерфейсы и несколько полезно-интересных плюшек доступны лишь в платной IDE… но с этим я смирился и радостно использую Edit версию редактора :)
    • 0
      Я его пользовал какое-то время. Мне нравилось, что там есть встроенный sftp-клиент. Также там есть автокомплит. Но дебаг всё тот же: через браузер и F5.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Если вы до сих пор не раскачали свой скилл в каком-то одном направлении, то возможно это вам не очень интересно. Раз у вас уже есть маленький бизнес, то я бы сосредоточился на развитии управленческих навыков.

    Если все же решите раскачивать пхп, то рекомендую почитать книгу PHP 5 Objects, Patterns, and Practice — Matt Zandastra. Вроде есть на русском. Ах, ну и качайте английский — айтишник с хорошим знанием английского языка сразу возрастает в цене и в перспективах.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      С радостью как у ребёнка прочитал ваш комментарий… Думал что нашёл ещё один редактор PHP который ещё не пробовал… Да, нашёл… но только виндоверсию :(
      Пока из всех редакторов поддерживающих основные платформы на мой взгляд лучший всё-же Komodo Edit :)
      Может вы знаете ещё какие-нить редакторы заточенные под пых?
      • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      > При программировании нет понятия правильного кода

      Зато в программировании есть понятия «поддерживаемый» и «не поддерживаемый» код.

      > Такими шагами вы придете сами к модели MVC.

      О! А вы, я вижу, активист велосипедостроения! Каждому программисту — по MVC! Побольше концепций, описывающих одно и то же — хороших и разных.
      • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Советую прочитать книгу «Совершенный код» Стива Макконнелла. Затрагивает многие общие вопросы программирования.
    • +5
      Рано. Чтобы понять в полной мере эту книгу, необходим немалый опыт в ООП.
  • +5
    PHP плох, кроме того что обладает кучей особенностей, тем, что не ставит ограничений программисту и на нём наговнокодить неподдерживаемый и нечитаемый код много проще чем на, Python, например.

    Моё мнение — PHP стоит учить, потому что может возникнуть необходимость поддерживать legacy код, но новый код надо писать на другом (я рекомендую Python).
  • +1
    если веб то Ruby вместе Ruby on Rails

    или если интересно objective-c, там паттернов и прочего навалом всегда используется
  • +2
    Прочитал вашу статью, аккуратно могу сказать, что вы уже Junior PHP developer.
    Чтобы в этом убедиться, вам нужно поработать 3-6 мес. в команде под присмотром middle/senior-девелопера.
    • 0
      Думал над этим, чтобы вписаться в какую-то команду и получить тьютора в лице тимлида, но тогда пришлось бы бросать свой маленький зато растущий бизнес. Так что мне светит только самообучение. Возможно, участие в каком-то специфичном опенсоурсном проекте, где готовы возиться с новичками.
  • 0
    Комментарий к заголовку: «прилично программировать» учаться не за попытки а за время…
    • +1
      Но в рамках своей первой попытки я время тратил явно неправильно :-)
      • 0
        Если не секрет, сколько вам лет?
        • 0
          Почти тридцать.
          • 0
            Лично я в 30 перешёл из админов в РНР-разработчики и вообще не комплексую о возрасте. Чуть больше года понадобилось чтобы пройти путь от Джуниора к Мидлу и это не предел. Сейчас начал изучать функциональную парадигму на досуге.
            При желании у вас всё получится. Вы можете выучить РНР или другой язык (если другой, то я бы Питон порекомендовал — по статистике среди пишущих на нём больше всего довольных своим языком).
            • +1
              Кстати, крутая метрика «количество довольных своим языком среди пишущих на нём». Без шуток. Ради этого ведь язык и создаётся: чтобы разработчику было комфортно. Не подкинете ли ссылку на ту статистику, о которой говорите?
  • +4
    Лично мне нравится Sublime Text 2 — шикарный редактор (подсветка синтаксиса множества языков программирования, быстрый и др.) + версии для Linux, Mac OS, Windows.
    • 0
      Шикарный редактор. Но я, к сожалению, уже сильно подсел на TM. Не смог себя пересилить =)
  • +2
    Может просто взять да вписаться юниором в какой-нибудь большой и злой опенсорс проект, там обычно на подхвате дают задачки попроще, а потом уже разобраться на ходу в том как он работает и какие шаблоны проектирования там применяются и все это вместе с практикой.
    Писал бы на С++, я бы посоветовал в Qt Project влиться. Насчет PHP не скажу, но лучше бы от него уходить. Наверняка есть что покодить или на node.js или даже на erlang'е.
    • 0
      А может по JavaScript'у посоветуете большой и злой опенсорс проект заодно? Что-то я в них теряюсь, либы либы либы.
  • 0
    По разметке есть советы от Google, хоть и написаны что для html и css, но многие подойдут и для php

    PHPStorm от JetBrains умеет сам красиво форматировать текст по нажатию клавиш Alt+Ctrl+L
    • 0
      Эмм, а можете привести пример совета по HTML и CSS, который «подойдёт и для PHP»?
      • 0
        Например
        Отступы
        Всегда используйте для отступа два пробела.

        Не используйте табуляцию и не смешивайте табуляцию с пробелами.

        или
        Комментарии
        По возможности поясняйте свой код, где это необходимо.

        И куча других полезных советов. Плюс php часто генерирует html код, который желательно тоже форматировать.
        • 0
          Есть советов много, но у меня к ним встречный вопрос: а почему именно так? Вот стандарта форматирования, где для каждого пункта было бы объяснение — не встречал. Зато однажды видел живого тимлида, который по каждому пункту действующего у них в команде стандарта кодирования мог рассказать какую-нибудь курьёзную историю из разряда: вот что случается, если этот пункт нарушить.
          • +1
            И не получится встретить. Стиль кода не более чем соглашение. Единого стандарта тут быть не может, как и обоснования. Какой приняли в проекте, такому и нужно следовать.
          • 0
            Неплохой стандарт кодирования есть тут —

            framework.zend.com/manual/ru/coding-standard.html

            Некоторые моменты даже объяснены, почему так.
          • 0
            Просто многие подобные советы и «стандарты» нарабатываются годами в определенных фирмах. Некоторые программисты доходят до определенного стиля, который который соответствует их стандарту. Я знаю, что у Яндекса есть стандарт форматирования кода, которого должны все их программисты придерживаться (где то был, но найти не могу).

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

            Просто есть определенные правила-советы, которых стоит придерживаться, без разницы на каком языке ты пишешь.
    • 0
      Есть же PSR-1 и PSR-2
  • 0
    Основной принцип безопасности — никому не верь, даже себе :) Все данные из внешних источников, как-то HTTP-запрос (GET и POST параметры, куки, даже какой-нибудь User-Agent), данные из БД или файла, переменные окружения и т. д., по умолчанию небезопасны и не должны применяться без экранирования и/или фильтрации в контексте допускающем выполнение (SQL-запрос, HTML-код, include/require, system, eval — список не полный), работу с ФС (особенно если имя файла задаётся динамически) и т.п. Даже если вы, например, вырезали HTML-тэги из пользовательского комментария и записали оставшийся текст в БД, то надеяться что при чтении там их не окажется нельзя. Хорошим тоном в определенных кругах считается писать данные с минимальным экранированием (соответствующем конкретной системе хранения, нет смысла делать htmlspecialchars при записи в БД или mysql_real_escape при выводе html), но жёстко экранировать и фильтровать при выводе.

    Ещё советы — осваивайте современные инструменты разработки: системы контроля версий, системы автоматического деплоя, миграции БД, баг-треккеры, системы управления проектами, автоматическое тестирование и т. д.

    В плане чистоты кода, скорее даже архитектуры, очень помогает написание тестов до написания кода, так называемое TDD (Test Driven Development) или, хотя бы, нужно думать о том как код будет тестироваться, если такая необходимость появится.

  • +7
    1. IDE PHP Storm

    2. толку от MVC, PHP, IoC и т.д. нет, если вы не научитесь мыслить объектно-ориентированно.

    начать можно, впрочем, с двух статей.
    они
    wiki.agiledev.ru/doku.php?id=ooad:dependency_injection
    wiki.agiledev.ru/doku.php?id=ooad:manage_dependencies_in_php_code

    также изучите принципы SOLID. лучше на примерах с презентациями
    ссылки можете взять из моего плана (я читаю иногда лекцию своим, набросал план)
    docs.google.com/document/d/1mUigVpqtQ-ZtQfN5fW1qOzQsoKRsf3t0xyz9At8dHLA/edit

    принципы ООП и правильное мышление одинаковы для любого языка. пусть сколько угодно усераются фанаты одного языка, не любящие PHP/Java/C++/подставьте другой язык, если они — дубы, то им ничто не поможет.

    правильные алгоритмы не зависят от языка. ООП не зависит от языка. умение писать в функциональном стиле тоже не зависит от языка.

    и только долбоебизм от него зависит — если вы не владеете виртуозно хотя бы двумя языками разного плана (к примеру, системный C и Perl под веб), в вас 99% рано или поздно проснется фанатизм к своему единственному языку и ненависть к одному или нескольким.

    но я отвлекся. в общем, почитайте статьи, которые я прислал,
    потом посмотрите, как устроены внутри нормальные фреймворки — Yii, а также орм-ка Doctrine и т.д.

    как увидите, что начнете понимать такие вещи, как
    — у этого класса одна ответственность, а вот у этого две и он поэтому кривой
    — так, в этом проекте классы называются Model, однако автор-мудло вместе с высокоуровневой логикой здесь всунул SQL-запрос (детали реализации), нарушение IoC и просто перемешивание архитектурных слоев
    — ага, вот тут применили паттерн Стратегия. он реализует IoC, что, свою очередь, уменьшает количество A<->B зависимостей и приближает к ациклическому направленному графу зависимостей систему, что для ее устойчивости очень хорошо
    и т.д.

    тогда считайте, что левелап произошел
    • +1
      Большое спасибо, вы вполне чёткие триггеры дали для отслеживания собственного профессионального роста. На следующую неделю себе уже выделил полдня на вдумчивое изучение ваших ссылок.
      • 0
        Пожалуйста.
        Только учтите еще одно. Кажется, доктор биологических наук Сергей Савельев сказал, что нейроны в мозгу образуются весьма медленно, и в день можно усвоить не более семи страниц тезисной информации.

        Поэтому тяжело идут такие умные книги, как DDD, или там Rapid Software Development, если их не проглядывать, конечно.

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

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

        Впрочем, дорогу осилит идущий, так что желаю успехов!
    • 0
      толку от MVC, PHP, IoC и т.д. нет, если вы не научитесь мыслить объектно-ориентированно.

      Всё это с ООП мало связано. MVC — разделение логики, на процедурах она, функциях или классах не суть. IoC — изменение контроля потока выполнения, тоже от парадигмы мало зависит, те же ФВП (включая callable в PHP) — вполне себе IoC. Ну а PHP вполне себе мультипарадигменный язык, а элементы ФП в нём чуть ли не с первой версии.

      если вы не владеете виртуозно хотя бы двумя языками разного плана (к примеру, системный C и Perl под веб), в вас 99% рано или поздно проснется фанатизм к своему единственному языку и ненависть к одному или нескольким.

      Я вот виртуозно не владею даже одним языком, но как-то ненависти ни к одному нет, что пробовал. Ненависть не конструктивна.

      у этого класса одна ответственность, а вот у этого две и он поэтому кривой

      Привет, ActiveRecord.

      так, в этом проекте классы называются Model, однако автор-мудло вместе с высокоуровневой логикой здесь всунул SQL-запрос (детали реализации), нарушение IoC и просто перемешивание архитектурных слоев

      Привет, ActiveRecord без ORM-библиотек/фреймворков. И непонятно почему SQL запросы не могут содержаться в классе модели. Да, нарушение S и SOLID, но тот же ActiveRecord это прямо подразумевает, а ведь он весьма популярен (та же Doctrine). А считать то, что в классе содержатся детали его реализации, ошибкой архитектуры по меньшей мере странно — где им ещё содержаться? Главное чтобы эти детали были скрыты от клиентов класса, а что там внутри… А уж «нарушение IoC» по-моему вообще некорректное использование термина IoC — мы либо его применяем, либо нет, как его нарушить-то можно?

      • 0
        >Всё это с ООП мало связано. MVC — разделение логики, на процедурах она, функциях или классах не суть. IoC — изменение контроля потока выполнения, тоже от парадигмы мало зависит, те же ФВП (включая callable в PHP) — вполне себе IoC. Ну а PHP вполне себе мультипарадигменный язык, а элементы ФП в нём чуть ли не с первой версии.

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

        А все, что вы написали в абзаце, как минимум спорно. MVC — да, это разделение кода по определенным областям ответственности. Однако там есть такое требование — взаимозаменяемость, на процедурах это гораздо труднее достигается, чем на ООП (впрочем, зависит от языка).

        Вместо IoC я хотел написать DI. Действительно, IoC можно весьма широко растянуть. В то время как инверсия зависимостей — вполне себе четко применяемый ООП механизм.

        >Я вот виртуозно не владею даже одним языком, но как-то ненависти ни к одному нет, что пробовал. Ненависть не конструктивна.

        По статистике Стаса Михайлова любит 70% в РФ. Но мы же с вами не любим? Но от этого статистика-то не изменилась, верно?

        > И непонятно почему SQL запросы не могут содержаться в классе модели. Да, нарушение S и SOLID, но тот же ActiveRecord это прямо подразумевает, а ведь он весьма популярен (та же Doctrine). А считать то, что в классе содержатся детали его реализации, ошибкой архитектуры по меньшей мере странно — где им ещё содержаться?

        Детали реализации в высокоуровневых классах — это порождение неявных зависимостей.

        Порождение неявных зависимостей — нарушение SPOT/DRY как минимум. Чем это плохо? Мммм ну как вам объяснить? Вот те же SQL запросы заточены в 1000 файлов под Mysql, а завтра проект запустили под Постгресом — и Велкам! Рефакторить и чинить неработающую хрень.

        > А уж «нарушение IoC» по-моему вообще некорректное использование термина IoC — мы либо его применяем, либо нет, как его нарушить-то можно?

        Да нет, нарушение IoC/DI вполне себе четко. Мы же понимания, что низкая связанность — это хорошо, высокая — плохо. Значит, хорошо и правильно — применять IoC в любом виде для уменьшения связности, хотя бы в виде DI. А плохо и неправильно (читай нарушение) — не применять, а писать спагетти код, code that smells.

        А то, что есть проекты, где есть те или иные нарушения принципов SOLID и иже с ними — как правило, это осознанная жертва в угоду чему-то (скорости, читаемости кода и т.д.), и человек делает это с осознанием, чем он жертвует и что получает. Ну вроде как слегка просроченные продукты или около того- вы можете купить их в некоторых странах супердешево, но вы понимаете, что идете на некоторый риск.

        если вы не владеете виртуозно хотя бы двумя языками разного плана (к примеру, системный C и Perl под веб), в вас 99% рано или поздно проснется фанатизм к своему единственному языку и ненависть к одному или нескольким.

        Я вот виртуозно не владею даже одним языком, но как-то ненависти ни к одному нет, что пробовал. Ненависть не конструктивна.

        у этого класса одна ответственность, а вот у этого две и он поэтому кривой

        Привет, ActiveRecord.

        так, в этом проекте классы называются Model, однако автор-мудло вместе с высокоуровневой логикой здесь всунул SQL-запрос (детали реализации), нарушение IoC и просто перемешивание архитектурных слоев

        Привет, ActiveRecord без ORM-библиотек/фреймворков. И непонятно почему SQL запросы не могут содержаться в классе модели. Да, нарушение S и SOLID, но тот же ActiveRecord это прямо подразумевает, а ведь он весьма популярен (та же Doctrine). А считать то, что в классе содержатся детали его реализации, ошибкой архитектуры по меньшей мере странно — где им ещё содержаться? Главное чтобы эти детали были скрыты от клиентов класса, а что там внутри… А уж «нарушение IoC» по-моему вообще некорректное использование термина IoC — мы либо его применяем, либо нет, как его нарушить-то можно?
        • 0
          * применять IoC в любом виде для уменьшения связанности
        • 0
          простите, там ниже абзаца
          А то, что есть проекты, где есть те или иные нарушения принципов SOLID и иже с ними — как правило, это осознанная жертва в угоду чему-то (скорости, читаемости кода и т.д.), и человек делает это с осознанием, чем он жертвует и что получает. Ну вроде как слегка просроченные продукты или около того- вы можете купить их в некоторых странах супердешево, но вы понимаете, что идете на некоторый риск.


          вставился текст, который я проглядел.
        • 0
          Детали реализации в высокоуровневых классах — это порождение неявных зависимостей.

          Порождение неявных зависимостей — нарушение SPOT/DRY как минимум. Чем это плохо? Мммм ну как вам объяснить? Вот те же SQL запросы заточены в 1000 файлов под Mysql, а завтра проект запустили под Постгресом — и Велкам! Рефакторить и чинить неработающую хрень.


          Зато эти неявные зависимости упрощают разработку. От того, что мы порядка 4000 (1000*CRUD) SQL-запросов перенесём в ещё отдельные 1000 файлов, количество необходимых правок не изменится. Может чуть-чуть облегчится нахождение места, где правки нужно вносить, но и разработка усложнится, причём, возможно, не чуть-чуть. Другое дело если изначально стоит задача абстрагироваться от диалекта SQL или, вообще, от уровня хранения…

          Да нет, нарушение IoC/DI вполне себе четко.

          IoC/DI не правило или принцип, чтобы его нарушать. Да, это способ уменьшения связанности (связность — почти противоположный термин) и разграничения ответственности, но не всегда низкая связанность это хорошо. А способ это лишь способ, его можно использовать, а можно нет. При неиспользовании может нарушаться принцип единственной ответственности, а может не нарушаться. А что до принципов типа SOLID, то, имхо, ровно наоборот — человек должен понимать чем он жертвует ради их соблюдения и какие плюсы они дадут (как правило не сиюминутные). Не покупка просроченных продуктов, а, скажем, участие в долевом строительстве вместо взятия ипотечного кредита. Можно сразу улучшить жилищные условия и расплачиваться потом, а можно вложить деньги сейчас, но придётся подождать…
          • 0
            >Зато эти неявные зависимости упрощают разработку.
            Это расхожее заблуждение.

            > Другое дело если изначально стоит задача абстрагироваться от диалекта SQL или, вообще, от уровня хранения…
            Конечно. Ну это же основы, первый класс. У вас есть высокоуровневые объекты и отношения между ними. А есть способ хранения и как это реализуется. Сегодня у нас PostgreSQL запросы, а завтра это переехало в NoSQL базы данных.

            Ну ей богу, смешно. Есть идея и есть много реализаций. Кучи паттернов придумали для решения частных случаев этого подхода.

            Нет, я не против. Есть мастера, которые вообще млять пишут, что шаблоны в PHP не нужны и нужно PHP-код писать вперемешку с HTML, только тогда это будет true. Правда, дать проект поддерживать новичкам почему-то такие товарищи боятся, да и другим коллегам часто тоже передать не могут.

            >IoC/DI не правило или принцип, чтобы его нарушать.
            Да в общем-то, и вежливость и рекомендация не хамить каждому встречному — тоже не правило или принцип, чтобы его нарушать. Только почему-то хамящий рано или поздно получает по морде, и как-то вежливость сама получается.

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

            > Да, это способ уменьшения связанности (связность — почти противоположный термин)
            Да, я опечатался. Мне непривычно говорить это, проще употреблять coupling / cohesion.

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

            конечно, не всегда хорошо, я об этом писал. иногда пишут все мегапросто ради скорости и т.д.

            >А что до принципов типа SOLID, то, имхо, ровно наоборот — человек должен понимать чем он жертвует ради их соблюдения и какие плюсы они дадут (как правило не сиюминутные). Не покупка просроченных продуктов, а, скажем, участие в долевом строительстве вместо взятия ипотечного кредита. Можно сразу улучшить жилищные условия и расплачиваться потом, а можно вложить деньги сейчас, но придётся подождать…

            Ну да, я согласен, это инструмент. Но в 99% случаев под веб ООП рулит.
            • 0
              Это расхожее заблуждение.

              Наверное для него есть основания… Про поддержку кода я ничего не говорил :)

              Конечно. Ну это же основы, первый класс.

              Вот честно, за десяток с лишним лет ни разу не приходилось менять движок SQL-СУБД, не говоря о переходе на не SQL хранилища или наоборот. То есть теоретически я пользу от абстрагирования или, хотя бы, «физического» (в разных файлах/функциях/методах) отделения системы хранения данных от бизнес-логики и остального понимаю, но на практике все что я делал для этого оказалось излишеством. Вполне достаточным оказалось не смешивать хранение и логику в одной функции/методе, а горождение многоуровневой абстракций типа EntityAbstractStorage > UserAbstractStorage > UserDatabaseStorage > UserSQLStorage > UserMySQLStorage > UserMySQL5Storage с глубоким использованием отражений и прочих интроспекций доставляло только чувство извращенного удовлетворения и страх запускать профайлер. :) И угадайте в каком случае коллеги жаловались на сложность поддержки, когда в классе User (и остальных классах моделей) был метод save(), вызывающий SQL запрос напрямую (и легко меняющийся на любой SQL движок, или, скажем, RPC-запрос), или когда нужно было иметь дело с такой абстракцией?

              Есть мастера, которые вообще млять пишут, что шаблоны в PHP не нужны и нужно PHP-код писать вперемешку с HTML, только тогда это будет true.

              Польза от шаблонов действительна не очевидна, учитывая что PHP сам по себе шаблонизатор и подавляющее большинство шаблонизаторов для него транслируют код шаблонов в него же. True, не true, но оверхид будет минимален. (Главное не забывать писать htmlspecialchars почти везде при echo. Собственно это основная причина почему я использую шаблонизаторы типа Twig или Smarty 3 — забывчив я и ленив :) ).

              • 0
                >Вот честно, за десяток с лишним лет ни разу не приходилось менять движок SQL-СУБД, не говоря о переходе на не SQL хранилища или наоборот. То есть теоретически я пользу от абстрагирования или, хотя бы, «физического» (в разных файлах/функциях/методах) отделения системы хранения данных от бизнес-логики и остального понимаю, но на практике все что я делал для этого оказалось излишеством.

                Ну а вот мы за последние 5 лет, пока я работаю в этой компании, успели перейти Oracle->Postgre, совсем недавно до меня был переход MSSQL -> Oracle. БД резко растет — с 2х миллионов записей в начале 2000х до 7 миллиардов в пик сезона в 2010х, при этом она постоянно обновляется (каждый час целиком) и читается.

                И тут очень пригодились абстракции.

                > Вполне достаточным оказалось не смешивать хранение и логику в одной функции/методе, а горождение многоуровневой абстракций типа EntityAbstractStorage > UserAbstractStorage > UserDatabaseStorage > UserSQLStorage > UserMySQLStorage > UserMySQL5Storage с глубоким использованием отражений и прочих интроспекций доставляло только чувство извращенного удовлетворения и страх запускать профайлер. :)

                Согласен, это уже ООП ради ООП. Мы применяем к примеру DDD, там есть объекты типа Storage. Они через небольшую обертку-абстракцию прямо напрямую работают с БД, методы save() и т.д. Это очень удобно, хотя и не труЪ ООП с ORM и прочей фигней.

                Собственно, любителей усложить тоже хватает, мама не горюй. Авторы Гибернейт знают толк в этом деле.

                >И угадайте в каком случае коллеги жаловались на сложность поддержки, когда в классе User (и остальных классах моделей) был метод save(), вызывающий SQL запрос напрямую (и легко меняющийся на любой SQL движок, или, скажем, RPC-запрос), или когда нужно было иметь дело с такой абстракцией?

                Согласен, простите меня, если я был резок. Бывают и такие решения удобны.

                >Польза от шаблонов действительна не очевидна, учитывая что PHP сам по себе шаблонизатор и подавляющее большинство шаблонизаторов для него транслируют код шаблонов в него же. True, не true, но оверхид будет минимален. (Главное не забывать писать htmlspecialchars почти везде при echo. Собственно это основная причина почему я использую шаблонизаторы типа Twig или Smarty 3 — забывчив я и ленив :) ).

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

                ИМХО!
  • +1
    Вы определитесь с областью, в которой хотите работать. Не стоит сразу ставить себе шоры. Составьте список интересных платформ/языков и выделите по 3-4 дня на первое впечатление. У каждого языка есть свои плюсы/минусы и своя область приложения.

    PS:
    >>Мне уже не стать профессиональным программистом, но до уровня junior`а с правильно
    поставленными мыслями и руками мне бы очень хотелось дойти.

    Вот не надо вешать на себя ярлыки. Главный вопрос «а нужно ли вам это?».

    PS2:
    я вимом пользуюсь, устраивает на все сто двадцать
  • +2
    могу отсортировать массив десятком методов… В общем, программированием владею как заурядный, но прилежный студент средненького технического вуза.

    Хотел бы я посмотреть как заурядные студенты моего вуза (БГУ) отсортируют массив 10 способами, даже сразу после выпуска. Может, конечно, нас неправильно учили, но, если специально этим не заниматься, на выходе в памяти остаются 1-5 методов, в зависимости от «прилежности».
    • +1
      Вообще я, наверное, не самый удачный пример привёл: у нас на выходе народ тоже знал что-нибудь типа сортировки выбором, пузырьком и вставками (тоже не больше 5 методов). Просто я по сортировкам делал курсовик и темой увлёкся :-)
  • +1
    Как будто сам писал. Спасибо.
    • +1
      А вы в итоге как-то для себя решили проблему? У меня лично есть такое ощущение, что в IT отрасли достаточно много подобных нам универсалов, многие из нас хорошо устраиваются на менеджерские позиции, но когда денег на сытый прокорм семьи уже хватает, то появляется время «для души» и вылезают вот эти самые комплексы собственной недоделанности по одному из приоритетных направлений.
      • 0
        Я, в общем-то, перестал на это заморачиваться.: )

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

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

        Кстати, рекомендую для развития читать книги с паттернами программирования, различными схемами, UML-диаграммами. Это позволяет общаться с программистами на близком языке, но на уровне алгоритмов, а не php, python или java. Я действительно научился у своих программистов многим новым трюкам, посмотрел на сколько это делает код безопасным, масштабируемым, модульным, понятным в конце концов (кстати, да мы на php работаем: ). Как всякие разные фичи из книг делаются в коде Yii, например. В итоге я понимаю, все что они пишут, но сам бы я так точно не написал (у меня было бы гораздо привычнее и громоздче) и тешу себя, что если что-то пойдет не так, то я-то уж точно залезу в код и исправлю косяки.

        Резюме: учитесь использовать максимально то, что уже есть, а изучать технологии по пути.
  • +1
    Я бы не заморачивался :)
  • +2
    Насчет IDE — пишу и дебажусь точно также — PSPad + F5.
    Раньше был менее ленив, и ставил Aptana (бесплатная), но видимо мне и в PSPad неплохо.

    MVC — не гарантия и не требование хорошего кода.
  • 0
    Но с чего заново начать, чтобы расти правильным программистом
    На самом ни с чего… т.е. всё придёт с опытом. И всё равно вы придёте рано или поздно к тому, что поймёте, что же вы хотите в итоге. Вы действительно хотите тратить 8 часов в сутки своей жизни сидя у компа и набирая код. Если «да» — тогда просто расслабьтесь и пишите код. Правильный код. Гуглите, читайте и т.д. Вы когда-нибудь встаните перед вопросом (что делать — писать код на дядю или попробоывать открыть своё дело, если конечно будете развиваться в том же направлении) и вам ответят — «это ваша жизнь» — поступайте так, как считаете нужным. Профессионализм во многом зависит от желания и цели человека. Никто и никогда не скажет что вы не понимаете в программировании — а если скажут — поверьте — это бизнесс(если конечно вы не соврали). Всё в ваших руках. А если вы пришли устраиваться на работу — и вам сказали что на позицию «junior php developer» вы не годитесь — поставьте себя на место управляющего и поймите, что они стараются минимизировать «затраты и риски». И не парьтесь. Просто развивайтесь. Надеюсь минусов не будет — ибо субъективаная точка зрения и совет.
  • +1
    Прежде чем учиться что-то делать «правильно» нужно понять одну простую мысль: не бывает абсолютного «правильно» — та или иная техника, правило или запись на скрижалях появилась по определенным причинам и только для решение оных она хороша. Во всех остальных случаях «правильность» спорна и неизбежный оверхед от дополнительных телодвижений будет только во вред.

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

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

    3 форматирование кода нужно имхо лишь для того что бы быстро читать код, не спотыкаясь на хитрых конструкциях. Это важно в команде. Какие при этом будет выбраны правила — неважно, главное что бы они были удобны и приняты всеми членами команды. Что бы избежать неизбежных холиваров, лучше найти style guide для используемых инструментов или выбрать из публичных и распространенных.

    IDE лучше взять помощнее и разобраться с ним — это хороший урок. Посмотреть что там с форматированием есть. Попробовать рефакторинг. Пощупать code navigation. Разобраться с проектами и так далее — это все так или иначе относится к «хорошим практикам» и ответам на заданные выше вопросы.

    Могу также посоветовать разбирать написанный вашими достойными программистами код. Задавайтесь вопросами — почему так а не по другому, думайте как бы вы сами написали данный кусок, ищите альтернативы. Не стесняйтесь задавать вопросы — профи уже давно знает ваш уровень, главное что бы работе не мешало :)
    • 0
      Спасибо. По последнему абзацу: я именно так и стараюсь делать, но при этом понимаю, что деньги я им плачу не за обучение меня, а за разработку. Но в целом именно желание понимать написанное во всех нюансах меня толкает к прокачке собственных скилов.
      • 0
        Я добавлю по последнему абзацу из своей практики: у нас стоит Redmine с хранилищем Mercurial'а, так там все добавленные изменения кода программистами можно сравнить, посмотреть, покрутить, задать вопрос: «А чой-то так-то вдруг теперь?»: ) И это круто, потому как программисты могут и любят объяснять свой код: «Ну, тут мы к объекту интерфейс добавили, теперь вот методы наследовались, а раньше было не так удобно».
  • +5
    Я вот здесь вижу много комментариев, советующих переучиваться на python или другой язык, потому как PHP «позволяет писать говнокод» и т.д. и т.п. Спорить тут я не стану — у PHP есть проблемы, но у какого языка их нет? Я уже не первый раз начинаю думать, что существует некоторое число PHP-шников с комплексом по поводу используемого языка. Обычно это происходит так: человек кодит на PHP, но постоянно со всех сторон слышит то шутливые, то серьезные холиварные заявления о том, что PHP это недоязык или язык для быдлокодеров, или что писать на PHP непрофессионально, или что он позволяет писать страшный говнокод. В дополнение к этому, в таких холиварах часто наводятся всякие рассказы о том, как кто-то влиятельный и авторитетный прикалывается над PHP ("… Мы заказываем пиццу через сайт. Так вот тот сайт сделан на PHP...").
    Такой человек начинает испытывать комплекс, старается переучиться — а в то же время нужно за что-то жить и зарабатывать деньги. Такой человек продолжает вынужденно писать на PHP, по крайней мере какое-то время, но уже не учит ничего нового, связанного с этим языком. Потом этот человек углубляет познания, скажем, в python'e, и восхищенно рассказывает о его супер-преимуществах над PHP. Причем, что смешно, довольно часто эти преимущества оказываются несущественными, а еще чаще — наводятся вовсе неправильные примеры, не являющиеся преимуществами. Я, к примеру, видел PHP-шников, которые довольно успешно по несколько лет работали с этим языком, использовали фреймворки и делали рабочие продукты, но не знали о существовании анонимных функций и callback'ов в PHP, восхищаясь затем этим функционалом в других языках.
    Выводов у меня несколько:
    1. Когда человек испытывает комплекс по поводу используемого языка, он зачастую перестает развивать знания этого языка, и метается от одного к другому — в итоге не становится профессионалом ни в одной области (ни в одном языке). Лично мое мнение — чтобы судить об языке и сравнивать его с другими, нужно быть профессионалом в сравниваемых языках. Станьте профессиональным PHP-программистом, изучите все его возможности, а потом ругайте его.
    2. PHP — замечательный язык, и достоин того, чтобы изучить его вдоль и поперек.
    3. Знать другие языки — это хорошо, но не стоит метаться от языка к языку, не успев освоить хорошо хотя бы один.

    З.Ы. Сразу хочу отметить, что ни в коем случае не пытаюсь холиварить или применьшить значимость того же python'а. Чтобы было понятнее — я использую и PHP, и Python, и обожаю оба эти языка — да-да, при этом я не говорю, что один из них говно, а второй конфетка.
    • 0
      Забыл добавить вывод в стиле Кэпа:
      На любом языке можно писать как страшный говнокод, так и изящнейший код.
    • 0
      У меня в голове диссонанс наступает как раз от того, что, как вы подметили, массы ругают PHP, а меня тот же самый PHP постоянно выручал и любой алгоритм мне проще и быстрее воплотить именно на нём. Так что, да, проблема «травли» действительно существует.
      • 0
        Что смешно, PHP в основном ругают снобски настроенные теоретики, не имеющие достаточно практики. PHP отличный язык — просто не стоит его использовать в тех областях, для которых он плохо приспособлен — например, в реализациях Comet я использую демоны, написанные на Python.
    • +1
      Хорошо подмечено про комплексы. Но, с другой стороны, многие фичи, те же callable (ФВП по сути), прикручены к PHP не самым очевидным и простым образом и изучать их на примере PHP не самый эффективный путь. И зацикливаться на одном языке, по-моему, не стоит. Следует изучать общие концепции программирования как бы абстрактно, а уж потом смотреть как они реализованы на том или ином языке. Решать задачу в терминах высокоуровневых абстракций, а потом подбирать инструмент(ы), которым лучше эти абстракции выразить. А не так, что решение задачи (а то и постановку) подгонять под любимый (а то и единственный) инструмент.

      В общем, по-моему, с самого начала освоения «правильного» программирования имеет смысл одну и ту же задачу решать с помощью нескольких языков (желательно как-то оставаясь в рамках best practices каждого языка) и сравнивать полученные решения, анализируя достоинства и недостатки.
    • 0
      /немного подумав/ Поддерживаю. Каждый язык хорош для своих задач, для которых он, собственно, и используется. И если сегодня мы решаем другие задачи — это значит только, что этот язык нам не подходит для этих задач. Как сказал МакКоннелл, «Программируйте не на языке, а с использованием языка» ©.
      • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Я сейчас порву тутошние шаблоны: учи C#. Без подколок. И в веб сможешь и ООП правильный и типизация строгая.
  • +1
    Для начинающего я бы вообще посоветовал забыть об IDE, вы должны сначала научится помимать как всё работает. ООП, паттерны не что иное как попытка управлять сложностью, подходы которые работают для 100-1000 строчек и количество состояний системы менее 20-50 перестают работать для проэктов с большим количеством состояний/строчек.
    Как вступление в ООП, паттерны я рекомендую обычно Крега Лармана «Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку» но для совсем новичкам она бывает сложна, тогда можно смотреть серию OReily Head First Patterns если есть перевод на русском.
    О PHP для понимания концепций стоит лучше забыть, есть языки более выразительные. И даже если вы исспользуете PHP для комерческой разработки, знакомство с другими языками рассширит ваш кругозор и позволит исспольховать некоторые конструкции для построения более качественных решений. Насчёт языка я бы порекомендовал Python, но это уже больше дело вкуса.
    • 0
      Кстати, если Вы хорошо понимаете ООП, сможете ли построить аналог наследования на чистом Си? :-)
      Вопрос только для Вас лично, не требующий ответа. Думаю, любому ООП-специалисту имеет смысл на него ответить.
      • 0
        У меня в загашнике целый фреймворк на Си для микроконтролера з эмуляцией ООП. Что-то вроде Си с класами. И о vtbl я знаю на практике.
  • 0
    Стоит! FaceBook и ВК частично написан на PHP.
    • 0
      По вашему VK и FB пишут начинающиеся переучивающиеся программисты? :-)
      • 0
        Все когда-то были начинающими, переучивающиеся. Когда я переходил с Perl, выбрал именно PHP.

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

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