Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 138
Я про неё слышал, но купить пока не надумал. Подходил и к таким снарядам как NetBeans и Eclipse, но они мне казались большими монстрами. Можете ли ткнуть в какой-то скринкаст или описать в нескольких предложениях, как дебаг происходит в PHPStorm? К нему ставится локальный веб-сервер и где-то уже в недрах IDE перехватываются его ответы и в каком-то своём окошке показываются?
И да, очень обидно, что называете Eclipse монстром, он на самом деле не страшный и очень дружелюбный. PDT вполне себе был удобен для программирования на PHP, когда я за него брался. Хотя других редакторов я не использовал, по инерции пересел на него после Java.
У них вечный 45-дневный триал. Когда надоест качать новую версию раз в 45 дней можно и купить. Но де-факто она бесплатна.
почитайте статью о NetBeans tips & tricks
Хочется учить — учите, PHP не очень сложный язык. Почитайте про паттерты и техники программирования в целом, ибо синтаксис выучить не очень сложно, а научиться писать эффективный хороший код — искусство. Хорошо бы знать какой-нибудь фреймворк (Yii, Symfony и т.д.), дабы не городить свой велосипед (хотя, для начальной стадии обучения, это даже минус).
Если Вам только кажется, что PHP — лучший язык для обучения, то я бы посоветовал почитать что-нибудь про мейнстимовые языки — python, ruby, C# и т.д. Не холивара ради, но они кажутся мне более гибкими и эффективными (сам пишу на C#).
Также, конечно, будет неплохо знать html, css, javascript. А так, имхо, никаких проблем — сидите и учите.
Если Вам только кажется, что PHP — лучший язык для обучения, то я бы посоветовал почитать что-нибудь про мейнстимовые языки — python, ruby, C# и т.д. Не холивара ради, но они кажутся мне более гибкими и эффективными (сам пишу на C#).
Также, конечно, будет неплохо знать html, css, javascript. А так, имхо, никаких проблем — сидите и учите.
> Путь человека-оркестра никогда до добра не доводил.
Ну да, и я тому пример. У меня не только бэкенд с фронтэндом смешались, а гораздо более сложный и ядовитый коктейль вышел. Но вот теперь надо выбираться :-)
Ну да, и я тому пример. У меня не только бэкенд с фронтэндом смешались, а гораздо более сложный и ядовитый коктейль вышел. Но вот теперь надо выбираться :-)
Зато в качестве менеджера имеете много плюсов в виде понимания процесса с разных сторон
… или углубляться. Не секрет, что в нашей сфере дефицит на хороших разработчиков есть и по всей видимости еще долго будет. Но разработка это не вещь в себе, это не конечная цель. Разработка и разработчики призваны решать бизнес задачи. Что бы решать эти задачи с прибылью требуются люди которые видят четкий вектор и могут ему следовать.Что бы такое виденье было нужен широкий кругозор. Даже ведущего разработчика можно заменить, но вот такого человека с вектором заменить как правило некем. Этих людей не хватает просто катастрофически. Уход ведущего разработчика, особенно в PHP большая конечно проблема, но она решаема. Уход координатора проекта как правило означает угасание проекта.
Поэтому я и написал в самом конце под грифом «неплохо знать». В общих чертах, чтобы понимать написанное, я считаю, знать нужно. А так Вы правы.
По-моему, если сформулировать основное направление как «разработка интернет-проекта», то становится понятно, что можно и нужно уметь делать все. Кроме себя любимого, знаю еще один чудесный пример, когда в конторе сидит 2 дизайнера, флешер, 2 менеджера и 1 программист. И, хочу доложить, неплохо справляется со сложными проектами. Это я не про сайты-визитки сейчас
Усталость — это да ;)
А ваша позиция — хоть и не лишена здравого смысла, но все же слишком категорична.
Эволюция «через оркестр» имеет три пути:
1. Одна область → Еще области (нахватываем) → Нихрена не получается → Останавливаемся на чем-то одном
2. Одна область → Еще области (нахватываем) → Более-менее получается всё → Остаемся оркестром среднего уровня
3. Одна область → Еще области (нахватываем) → Получается всё → Становимся CTO (Chief Technology Officer)
CTO ОБЯЗАН хорошо уметь делать всё.
Это я вам, как прошедший третий путь, говорю.
Конечно, людей, которые могут охватить множество областей одинаково хорошо — не так уж и много, но если есть хотя бы мысли о том, что ты можешь буть универсален, НУЖНО пробовать стать оркестром, иначе имеешь шанс загубить в себе CTO. А их ооой как не хватает
А ваша позиция — хоть и не лишена здравого смысла, но все же слишком категорична.
Эволюция «через оркестр» имеет три пути:
1. Одна область → Еще области (нахватываем) → Нихрена не получается → Останавливаемся на чем-то одном
2. Одна область → Еще области (нахватываем) → Более-менее получается всё → Остаемся оркестром среднего уровня
3. Одна область → Еще области (нахватываем) → Получается всё → Становимся CTO (Chief Technology Officer)
CTO ОБЯЗАН хорошо уметь делать всё.
Это я вам, как прошедший третий путь, говорю.
Конечно, людей, которые могут охватить множество областей одинаково хорошо — не так уж и много, но если есть хотя бы мысли о том, что ты можешь буть универсален, НУЖНО пробовать стать оркестром, иначе имеешь шанс загубить в себе CTO. А их ооой как не хватает
А CTO это технический специалист больше или администратор/менеджер?
Полюбопытствуйте node.js, backbone.js и иже с ними. Это как раз пример того, надо ли backend разработчику знать JS.
Если работать на кого-то, то да — лучше как иметь наиболее узкую специализацию.
Если работать на себя — необходимо быть человек-оркестром.
Если работать на себя — необходимо быть человек-оркестром.
А вы можете предложить какие-то русскоязычные статьи про паттерны и техники, которые именно вам кажутся дельными и понятными?
Ведь на том же быдлокодерском уровне я знаю html, css (как и писал: могу сверстать несложный шаблон и натянуть его на CMS). Немного знаком и с API Yii, но я, например, не могу читать его исходники и извлекать оттуда опыт или познавать на его примере архитектуру.
Ведь на том же быдлокодерском уровне я знаю html, css (как и писал: могу сверстать несложный шаблон и натянуть его на CMS). Немного знаком и с API Yii, но я, например, не могу читать его исходники и извлекать оттуда опыт или познавать на его примере архитектуру.
Как минимум надо отлично понимать, что такое MVC и MVVM.
Я много времени программировал (и программирую) на C++, поэтому львиная доля знаний пришла ко мне не из веб-разработки. Отличный список книг представлен на stackoverflow (например, Design Patterns by the Gang of Four). Вот в этом тредике дают хорошие советы о книгах для PHP-разработчиках (о «PHP Objects, Patterns and Practice» я слышал много хорошего).
Я много времени программировал (и программирую) на C++, поэтому львиная доля знаний пришла ко мне не из веб-разработки. Отличный список книг представлен на stackoverflow (например, Design Patterns by the Gang of Four). Вот в этом тредике дают хорошие советы о книгах для PHP-разработчиках (о «PHP Objects, Patterns and Practice» я слышал много хорошего).
Спасибо Вам за ссылки.
Нашел для себя онлайн вариант книги, которую искал очень давно. В каком то книжном магазине наспех пролистал её, денег с собой не было, решил потом зайти. В итоге зашел, её нет, названия не помню. Аналоги, которые находил в сети, были не то. А по Вашей ссылке нашел её, вот собственно сабж commons.oreilly.com/wiki/index.php/PHP_Cookbook
Еще раз спасибо!
Нашел для себя онлайн вариант книги, которую искал очень давно. В каком то книжном магазине наспех пролистал её, денег с собой не было, решил потом зайти. В итоге зашел, её нет, названия не помню. Аналоги, которые находил в сети, были не то. А по Вашей ссылке нашел её, вот собственно сабж commons.oreilly.com/wiki/index.php/PHP_Cookbook
Еще раз спасибо!
Не холивора ради, но попробуйте всё-таки попробовать начать изучение, например, с того же Питона. В крайнем случае можете изучать его параллельно с PHP, к примеру, можно поставить себе цель писать одни и те же примеры на обоих языках, в любом случае это будет неплохой практикой и даст прививку от прикипания к одному языку.
> прививку от прикипания к одному языку
Да, возможно, я этим недугом страдаю :-)
Да, возможно, я этим недугом страдаю :-)
Попробуйте python в сочетании с Django — должно понравится, да и документации по них дохрена.
А вообще, diamant чуть ниже правильно написал — если вы много всего знаете, понимаете процессы, но в общих чертах, из вас может получиться хороший начальник. Начальник должен понимать и оценивать масштабы работы, а не заниматься деталями реализации.
А вообще, diamant чуть ниже правильно написал — если вы много всего знаете, понимаете процессы, но в общих чертах, из вас может получиться хороший начальник. Начальник должен понимать и оценивать масштабы работы, а не заниматься деталями реализации.
А зачем тебе становится правильным программистом? Узкая специализация — она же не всем и не всегда нужна. Судя по описанию, ты — организатор (менеджер, начальник), который знает обо всём понемногу и чуть-чуть умеет делать всё. А где не хватит собственной квалификации, можно нанять разбирающегося человека.
Находи узких специалистов и задачи для них, организовывай свой бизнес — если это интересно, конечно.
Находи узких специалистов и задачи для них, организовывай свой бизнес — если это интересно, конечно.
В общем, как в топике написал, этим-то я сейчас и занимаюсь, на жизнь как раз вполне хватает. Программировать хочется скорее для души. Ну, и, кроме того, я думаю, что смогу эффективнее взаимодействовать с нанимаемыми разработчиками, когда сам буду более квалифицирован в их области.
Судя по описанию в посте, все проекты у вас — на PHP. Поэтому, если говорить о целях взаимодействия с разработчиками, то нет и вопроса о выборе изучаемого языка.
А вот что вам нужно для души — этого знать никто не может. В мире не было бы многих сотен ЯП, если бы у разных людей душа не лежала к разным вещам :)
А вот что вам нужно для души — этого знать никто не может. В мире не было бы многих сотен ЯП, если бы у разных людей душа не лежала к разным вещам :)
Солидарен с diamant. Когда читал, то первая мысль которая возникает «зачем?». Если есть опыт практического использования и получаются работающие решения, то это нормальный инженерный подход. В погоне за всеми этими красивыми аббревиатурами разработчики зачастую забывают, что это не самоцель. Все эти подходы были придуманы и используются ради упрощения и ускорения разработки. Всякие «архытэктары» поназаворачивают вычурные патерны, магические методы и кучу другой магии, а потом это все мало того, что тормозит, так еще младшие разработчики с этим работать не могут. А реалии веб студии таковы, что нужные младшие и средние разработчики которые могут дешево и быстро производить продукт. И рассчитывать нужно в первую очередь на них.
Поэтому лично я бы рекомендовал двигаться совершенно в других направлениях. Два варианта у меня с ходу есть. Если есть желание написания кода для души, то пусть он приносит пользу людям, в конечно итоге в этом работа инженера и состоит. Поэтому есть смысл создавать полезные для людей веб сервисы. Реализация в виде кода при этом не принципиальна, главное полезное и работающее решение. При этом высока вероятность, что паттерны о которых все говорят таки будут в нем применяться. Но дойти до них получится самостоятельно. А второе направление я бы связал с профессиональной деятельностью. Предлагаю расширять степень охвата областей. Т.е. заняться связанными сферами, копнуть там больше в сторону администрирования, к примеру, или заняться бухгалтерией.
Поэтому лично я бы рекомендовал двигаться совершенно в других направлениях. Два варианта у меня с ходу есть. Если есть желание написания кода для души, то пусть он приносит пользу людям, в конечно итоге в этом работа инженера и состоит. Поэтому есть смысл создавать полезные для людей веб сервисы. Реализация в виде кода при этом не принципиальна, главное полезное и работающее решение. При этом высока вероятность, что паттерны о которых все говорят таки будут в нем применяться. Но дойти до них получится самостоятельно. А второе направление я бы связал с профессиональной деятельностью. Предлагаю расширять степень охвата областей. Т.е. заняться связанными сферами, копнуть там больше в сторону администрирования, к примеру, или заняться бухгалтерией.
Как бывший ПХПшник советую не забивать себе голову глупостями и функциональщиной (вы ж не студент и лишнего времени у вас скорей всего нет) а сразу начинать с 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", "[]"]
Вот это выше массив с методами.
Запускаете интерпретптор коммандой
Если есть свободные 10 минут посмотрите видео
irb. Выполняете: 1.class
Fixnum
true.Если есть свободные 10 минут посмотрите видео
В рельсе все делается очень легко и просто причем не в ущерб качеству. К примеру мы сейчас работаем над проектом у которого в продакшне более 20млн хостов в сутки и база под терабайт. Приложение очень большое и сложное, разрабатывается около двух лет, при этом мы постоянно наращиваем функционал и не особо вязнем в коде.
Если интересно посмотреть более подробную инфу по рельсе рекомендую railscasts.com Там как раз про кастомные штуки.
Если интересно посмотреть более подробную инфу по рельсе рекомендую railscasts.com Там как раз про кастомные штуки.
def bad_example( a = «Тема», b = 'руби', c = 'не', d = 'раскрыта', message = [a,b,c,d] )
10.times.map { message.join(" ") }.join("! ")
end
10.times.map { message.join(" ") }.join("! ")
end
_________
best regards
KO
Хм. Холивар двух рубистов в хабе PHP? Сильно.
Я не том, что ваш пример плох, а о том, что он не очевиден для того, кто с ruby не знаком. (_не очевиден_ != непонятен).
кстати, почему PHP — «функциональщина»?
Я не том, что ваш пример плох, а о том, что он не очевиден для того, кто с ruby не знаком. (_не очевиден_ != непонятен).
кстати, почему PHP — «функциональщина»?
Ну, руби изначально ООП. А в PHP он какбэ прикручен что-ли. Язык больше заточён под функциональное программирование. Правда я могу быть не прав т.к. PHP очень давно не занимаюсь и не слежу за последними веяниями. В общем не сильно в курсе что там сейчас. Но когда я на нем писал (писал не хомяки если что) функциональное программирование преобладало.
Функциональное программирование — это совсем не то же самое, что процедурное программирование. Думаю, вы имеете в виду второе.
Если так рассуждать, то детские болезни руби (< 1.9) тоже придется предъявлять: тормозной, память жрал (угу, был еще ree). 4 гига 4 ядра, а rake еле ползает… Оба языка сильно поменялись, как и комьюнити. ruby 1.9.3 и php 5.3(4) несколько отличаются от своих давних предков. Конечно strlen и str_replace, как и $ остались. Куда ж без них. Но ООП у пхп вполне имеется. Как и неймспейсы, которых я так ждал и не дождался.
coffescript like враппер над php для убирания рудиментов? )))) Заодно; под нож )) (irony?)
Мне конечно руби намного больше нравится, но я бы не сказал, что процесс перелезания на него полностью оправдан и тем более, что это просто. Многим этого просто не нужно, и говорить что они пишут на плохом языке — еще с 5 версии неверно.
coffescript like враппер над php для убирания рудиментов? )))) Заодно; под нож )) (irony?)
Мне конечно руби намного больше нравится, но я бы не сказал, что процесс перелезания на него полностью оправдан и тем более, что это просто. Многим этого просто не нужно, и говорить что они пишут на плохом языке — еще с 5 версии неверно.
Руби программисты они во всех хабах к сожалению.
Это я конечно не учел, что упоминать Ruby там где в тексте over 9000 включений PHP, чревато ;)
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'Да, пайтон тоже отличный язык. Но для меня как рубиста там тоже огромное количество непонятных и неочевидных вещей. Например почему
А не
(про __len__ я в курсе если что). Просто языки разные же.
И да. Про ахинею. У большинства классов есть родительские и у них есть свои методы. Могу подробно описать вам каждый метод чтоб вы могли убедиться что ахинеи там нет. Но думаю что подобное описание немного выходит за рамки обсуждаемой темы.
З.Ы. И да, то что пример не явный и не совсем удачный я уже понял. Прошу прощения если задел чьи-то чувства.
len(myList)
А не
myList.len
(про __len__ я в курсе если что). Просто языки разные же.
И да. Про ахинею. У большинства классов есть родительские и у них есть свои методы. Могу подробно описать вам каждый метод чтоб вы могли убедиться что ахинеи там нет. Но думаю что подобное описание немного выходит за рамки обсуждаемой темы.
З.Ы. И да, то что пример не явный и не совсем удачный я уже понял. Прошу прощения если задел чьи-то чувства.
> люблю изучать разные платформы
Хорошая привычка. Я как раз пайтон ковыряю в свободное время =)
Хорошая привычка. Я как раз пайтон ковыряю в свободное время =)
> Но какие ещё бывают типовые косяки в безопасности, которых стоит сразу же бояться и не допускать как SQL-инъекций?
Основной принцип — не доверять данным, приходящим от пользователя, т.к. подсунуть могут все что угодно (да-да, как с SQL-инъекциями).
file_get_contents($_GET['page']);
require($_COOKIE['data']);
imageCreate($_POST['width'], $_POST['height']);
Основной принцип — не доверять данным, приходящим от пользователя, т.к. подсунуть могут все что угодно (да-да, как с SQL-инъекциями).
file_get_contents($_GET['page']);
require($_COOKIE['data']);
imageCreate($_POST['width'], $_POST['height']);
Как-то открыл для себя существование прекрасного (на мой взгляд) редактора (и IDE) Komodo Edit
К сожалению встроенные дебаг-интерфейсы и несколько полезно-интересных плюшек доступны лишь в платной IDE… но с этим я смирился и радостно использую Edit версию редактора :)
К сожалению встроенные дебаг-интерфейсы и несколько полезно-интересных плюшек доступны лишь в платной IDE… но с этим я смирился и радостно использую Edit версию редактора :)
Если вы до сих пор не раскачали свой скилл в каком-то одном направлении, то возможно это вам не очень интересно. Раз у вас уже есть маленький бизнес, то я бы сосредоточился на развитии управленческих навыков.
Если все же решите раскачивать пхп, то рекомендую почитать книгу PHP 5 Objects, Patterns, and Practice — Matt Zandastra. Вроде есть на русском. Ах, ну и качайте английский — айтишник с хорошим знанием английского языка сразу возрастает в цене и в перспективах.
Если все же решите раскачивать пхп, то рекомендую почитать книгу PHP 5 Objects, Patterns, and Practice — Matt Zandastra. Вроде есть на русском. Ах, ну и качайте английский — айтишник с хорошим знанием английского языка сразу возрастает в цене и в перспективах.
Для программирования на PHP нужна не мощная IDE, а программа, в которой удобно подсвечивается синтаксис, я раньше использовал PHP Expert Editor, а сейчас пересел на Codelobster PHP Edition.
При программировании нет понятия правильного кода, программа либо работает, либо нет. То, о чем вы говорите, приходит с опытом. Возьмите идею и начните её реализовывать как умеете, со временем, вам станет неудобно вносить изменения в существующий код, так как он будет слишком велик. Вы задумаетесь о выделении повторяющихся участков кода в функции. Потом у вас появятся наборы функций для работы с определенными наборами данных, и вам окажется проще их объединить в классы (это уже пойдет полноценное ООП). Такими шагами вы придете сами к модели MVC.
В программирование главное умение разложить задачу на алгоритмы, а потом выбрать наиболее подходящий язык для описания этих алгоритмов.
П.С. Так называемый правильный код, появляется из лени программистов, описывать каждый раз одно и тоже ;)
При программировании нет понятия правильного кода, программа либо работает, либо нет. То, о чем вы говорите, приходит с опытом. Возьмите идею и начните её реализовывать как умеете, со временем, вам станет неудобно вносить изменения в существующий код, так как он будет слишком велик. Вы задумаетесь о выделении повторяющихся участков кода в функции. Потом у вас появятся наборы функций для работы с определенными наборами данных, и вам окажется проще их объединить в классы (это уже пойдет полноценное ООП). Такими шагами вы придете сами к модели MVC.
В программирование главное умение разложить задачу на алгоритмы, а потом выбрать наиболее подходящий язык для описания этих алгоритмов.
П.С. Так называемый правильный код, появляется из лени программистов, описывать каждый раз одно и тоже ;)
С радостью как у ребёнка прочитал ваш комментарий… Думал что нашёл ещё один редактор PHP который ещё не пробовал… Да, нашёл… но только виндоверсию :(
Пока из всех редакторов поддерживающих основные платформы на мой взгляд лучший всё-же Komodo Edit :)
Может вы знаете ещё какие-нить редакторы заточенные под пых?
Пока из всех редакторов поддерживающих основные платформы на мой взгляд лучший всё-же Komodo Edit :)
Может вы знаете ещё какие-нить редакторы заточенные под пых?
> При программировании нет понятия правильного кода
Зато в программировании есть понятия «поддерживаемый» и «не поддерживаемый» код.
> Такими шагами вы придете сами к модели MVC.
О! А вы, я вижу, активист велосипедостроения! Каждому программисту — по MVC! Побольше концепций, описывающих одно и то же — хороших и разных.
Зато в программировании есть понятия «поддерживаемый» и «не поддерживаемый» код.
> Такими шагами вы придете сами к модели MVC.
О! А вы, я вижу, активист велосипедостроения! Каждому программисту — по MVC! Побольше концепций, описывающих одно и то же — хороших и разных.
Советую прочитать книгу «Совершенный код» Стива Макконнелла. Затрагивает многие общие вопросы программирования.
PHP плох, кроме того что обладает кучей особенностей, тем, что не ставит ограничений программисту и на нём наговнокодить неподдерживаемый и нечитаемый код много проще чем на, Python, например.
Моё мнение — PHP стоит учить, потому что может возникнуть необходимость поддерживать legacy код, но новый код надо писать на другом (я рекомендую Python).
Моё мнение — PHP стоит учить, потому что может возникнуть необходимость поддерживать legacy код, но новый код надо писать на другом (я рекомендую Python).
если веб то Ruby вместе Ruby on Rails
или если интересно objective-c, там паттернов и прочего навалом всегда используется
или если интересно objective-c, там паттернов и прочего навалом всегда используется
Прочитал вашу статью, аккуратно могу сказать, что вы уже Junior PHP developer.
Чтобы в этом убедиться, вам нужно поработать 3-6 мес. в команде под присмотром middle/senior-девелопера.
Чтобы в этом убедиться, вам нужно поработать 3-6 мес. в команде под присмотром middle/senior-девелопера.
Комментарий к заголовку: «прилично программировать» учаться не за попытки а за время…
Но в рамках своей первой попытки я время тратил явно неправильно :-)
Если не секрет, сколько вам лет?
Почти тридцать.
Лично я в 30 перешёл из админов в РНР-разработчики и вообще не комплексую о возрасте. Чуть больше года понадобилось чтобы пройти путь от Джуниора к Мидлу и это не предел. Сейчас начал изучать функциональную парадигму на досуге.
При желании у вас всё получится. Вы можете выучить РНР или другой язык (если другой, то я бы Питон порекомендовал — по статистике среди пишущих на нём больше всего довольных своим языком).
При желании у вас всё получится. Вы можете выучить РНР или другой язык (если другой, то я бы Питон порекомендовал — по статистике среди пишущих на нём больше всего довольных своим языком).
Кстати, крутая метрика «количество довольных своим языком среди пишущих на нём». Без шуток. Ради этого ведь язык и создаётся: чтобы разработчику было комфортно. Не подкинете ли ссылку на ту статистику, о которой говорите?
dou.ua/lenta/articles/language-rating-1h2012/
см. показатель Индекс привязанности
см. показатель Индекс привязанности
Лично мне нравится Sublime Text 2 — шикарный редактор (подсветка синтаксиса множества языков программирования, быстрый и др.) + версии для Linux, Mac OS, Windows.
Может просто взять да вписаться юниором в какой-нибудь большой и злой опенсорс проект, там обычно на подхвате дают задачки попроще, а потом уже разобраться на ходу в том как он работает и какие шаблоны проектирования там применяются и все это вместе с практикой.
Писал бы на С++, я бы посоветовал в Qt Project влиться. Насчет PHP не скажу, но лучше бы от него уходить. Наверняка есть что покодить или на node.js или даже на erlang'е.
Писал бы на С++, я бы посоветовал в Qt Project влиться. Насчет PHP не скажу, но лучше бы от него уходить. Наверняка есть что покодить или на node.js или даже на erlang'е.
По разметке есть советы от Google, хоть и написаны что для html и css, но многие подойдут и для php
PHPStorm от JetBrains умеет сам красиво форматировать текст по нажатию клавиш Alt+Ctrl+L
PHPStorm от JetBrains умеет сам красиво форматировать текст по нажатию клавиш Alt+Ctrl+L
Эмм, а можете привести пример совета по HTML и CSS, который «подойдёт и для PHP»?
Например
или
И куча других полезных советов. Плюс php часто генерирует html код, который желательно тоже форматировать.
Отступы
Всегда используйте для отступа два пробела.
Не используйте табуляцию и не смешивайте табуляцию с пробелами. или
Комментарии
По возможности поясняйте свой код, где это необходимо. И куча других полезных советов. Плюс php часто генерирует html код, который желательно тоже форматировать.
Есть советов много, но у меня к ним встречный вопрос: а почему именно так? Вот стандарта форматирования, где для каждого пункта было бы объяснение — не встречал. Зато однажды видел живого тимлида, который по каждому пункту действующего у них в команде стандарта кодирования мог рассказать какую-нибудь курьёзную историю из разряда: вот что случается, если этот пункт нарушить.
И не получится встретить. Стиль кода не более чем соглашение. Единого стандарта тут быть не может, как и обоснования. Какой приняли в проекте, такому и нужно следовать.
Неплохой стандарт кодирования есть тут —
framework.zend.com/manual/ru/coding-standard.html
Некоторые моменты даже объяснены, почему так.
framework.zend.com/manual/ru/coding-standard.html
Некоторые моменты даже объяснены, почему так.
Просто многие подобные советы и «стандарты» нарабатываются годами в определенных фирмах. Некоторые программисты доходят до определенного стиля, который который соответствует их стандарту. Я знаю, что у Яндекса есть стандарт форматирования кода, которого должны все их программисты придерживаться (где то был, но найти не могу).
Если брать примеры из жизни. В универе со мной учился хороший программер, у которого был кардинально другой стиль форматирования. Например, я брал отступ в два пробела и отдельная строка для каждого оператора, то у него — написание блока в одну строчку (разумеется, без комментариев) и понять его код было гораздо сложнее.
Просто есть определенные правила-советы, которых стоит придерживаться, без разницы на каком языке ты пишешь.
Если брать примеры из жизни. В универе со мной учился хороший программер, у которого был кардинально другой стиль форматирования. Например, я брал отступ в два пробела и отдельная строка для каждого оператора, то у него — написание блока в одну строчку (разумеется, без комментариев) и понять его код было гораздо сложнее.
Просто есть определенные правила-советы, которых стоит придерживаться, без разницы на каком языке ты пишешь.
Основной принцип безопасности — никому не верь, даже себе :) Все данные из внешних источников, как-то HTTP-запрос (GET и POST параметры, куки, даже какой-нибудь User-Agent), данные из БД или файла, переменные окружения и т. д., по умолчанию небезопасны и не должны применяться без экранирования и/или фильтрации в контексте допускающем выполнение (SQL-запрос, HTML-код, include/require, system, eval — список не полный), работу с ФС (особенно если имя файла задаётся динамически) и т.п. Даже если вы, например, вырезали HTML-тэги из пользовательского комментария и записали оставшийся текст в БД, то надеяться что при чтении там их не окажется нельзя. Хорошим тоном в определенных кругах считается писать данные с минимальным экранированием (соответствующем конкретной системе хранения, нет смысла делать htmlspecialchars при записи в БД или mysql_real_escape при выводе html), но жёстко экранировать и фильтровать при выводе.
Ещё советы — осваивайте современные инструменты разработки: системы контроля версий, системы автоматического деплоя, миграции БД, баг-треккеры, системы управления проектами, автоматическое тестирование и т. д.
В плане чистоты кода, скорее даже архитектуры, очень помогает написание тестов до написания кода, так называемое TDD (Test Driven Development) или, хотя бы, нужно думать о том как код будет тестироваться, если такая необходимость появится.
Ещё советы — осваивайте современные инструменты разработки: системы контроля версий, системы автоматического деплоя, миграции БД, баг-треккеры, системы управления проектами, автоматическое тестирование и т. д.
В плане чистоты кода, скорее даже архитектуры, очень помогает написание тестов до написания кода, так называемое TDD (Test Driven Development) или, хотя бы, нужно думать о том как код будет тестироваться, если такая необходимость появится.
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 зависимостей и приближает к ациклическому направленному графу зависимостей систему, что для ее устойчивости очень хорошо
и т.д.
тогда считайте, что левелап произошел
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 зависимостей и приближает к ациклическому направленному графу зависимостей систему, что для ее устойчивости очень хорошо
и т.д.
тогда считайте, что левелап произошел
Большое спасибо, вы вполне чёткие триггеры дали для отслеживания собственного профессионального роста. На следующую неделю себе уже выделил полдня на вдумчивое изучение ваших ссылок.
Пожалуйста.
Только учтите еще одно. Кажется, доктор биологических наук Сергей Савельев сказал, что нейроны в мозгу образуются весьма медленно, и в день можно усвоить не более семи страниц тезисной информации.
Поэтому тяжело идут такие умные книги, как DDD, или там Rapid Software Development, если их не проглядывать, конечно.
То есть будьте готовы, что на усвоение концепций уйдет где-то полгода постоянной тренировки мозга.
Плюс еще учтите, у некоторых в принципе мозги по каким-то причинам не могут переварить материалы выше определенной сложности. Ну как если у вас рост два метра, а рядом с вами прыгает десятиметровый великан — вы никогда не прыгните дальше просто физически.
Впрочем, дорогу осилит идущий, так что желаю успехов!
Только учтите еще одно. Кажется, доктор биологических наук Сергей Савельев сказал, что нейроны в мозгу образуются весьма медленно, и в день можно усвоить не более семи страниц тезисной информации.
Поэтому тяжело идут такие умные книги, как DDD, или там Rapid Software Development, если их не проглядывать, конечно.
То есть будьте готовы, что на усвоение концепций уйдет где-то полгода постоянной тренировки мозга.
Плюс еще учтите, у некоторых в принципе мозги по каким-то причинам не могут переварить материалы выше определенной сложности. Ну как если у вас рост два метра, а рядом с вами прыгает десятиметровый великан — вы никогда не прыгните дальше просто физически.
Впрочем, дорогу осилит идущий, так что желаю успехов!
толку от 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 — мы либо его применяем, либо нет, как его нарушить-то можно?
Всё это с ООП мало связано. MVC — разделение логики, на процедурах она, функциях или классах не суть. IoC — изменение контроля потока выполнения, тоже от парадигмы мало зависит, те же ФВП (включая callable в PHP) — вполне себе IoC. Ну а PHP вполне себе мультипарадигменный язык, а элементы ФП в нём чуть ли не с первой версии.
если вы не владеете виртуозно хотя бы двумя языками разного плана (к примеру, системный C и Perl под веб), в вас 99% рано или поздно проснется фанатизм к своему единственному языку и ненависть к одному или нескольким.
Я вот виртуозно не владею даже одним языком, но как-то ненависти ни к одному нет, что пробовал. Ненависть не конструктивна.
у этого класса одна ответственность, а вот у этого две и он поэтому кривой
Привет, ActiveRecord.
так, в этом проекте классы называются Model, однако автор-мудло вместе с высокоуровневой логикой здесь всунул SQL-запрос (детали реализации), нарушение IoC и просто перемешивание архитектурных слоев
Привет, ActiveRecord без ORM-библиотек/фреймворков. И непонятно почему SQL запросы не могут содержаться в классе модели. Да, нарушение S и SOLID, но тот же ActiveRecord это прямо подразумевает, а ведь он весьма популярен (та же Doctrine). А считать то, что в классе содержатся детали его реализации, ошибкой архитектуры по меньшей мере странно — где им ещё содержаться? Главное чтобы эти детали были скрыты от клиентов класса, а что там внутри… А уж «нарушение IoC» по-моему вообще некорректное использование термина IoC — мы либо его применяем, либо нет, как его нарушить-то можно?
>Всё это с ООП мало связано. 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 — мы либо его применяем, либо нет, как его нарушить-то можно?
Там шло перечисление как иллюстрация разных терминов. Посыл такой был у моего абзаца — пока нет правильного мышления, учить всякие определения просто так смысла не имеет.
А все, что вы написали в абзаце, как минимум спорно. 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 — мы либо его применяем, либо нет, как его нарушить-то можно?
* применять IoC в любом виде для уменьшения связанности
простите, там ниже абзаца
А то, что есть проекты, где есть те или иные нарушения принципов SOLID и иже с ними — как правило, это осознанная жертва в угоду чему-то (скорости, читаемости кода и т.д.), и человек делает это с осознанием, чем он жертвует и что получает. Ну вроде как слегка просроченные продукты или около того- вы можете купить их в некоторых странах супердешево, но вы понимаете, что идете на некоторый риск.
вставился текст, который я проглядел.
А то, что есть проекты, где есть те или иные нарушения принципов SOLID и иже с ними — как правило, это осознанная жертва в угоду чему-то (скорости, читаемости кода и т.д.), и человек делает это с осознанием, чем он жертвует и что получает. Ну вроде как слегка просроченные продукты или около того- вы можете купить их в некоторых странах супердешево, но вы понимаете, что идете на некоторый риск.
вставился текст, который я проглядел.
Детали реализации в высокоуровневых классах — это порождение неявных зависимостей.
Порождение неявных зависимостей — нарушение SPOT/DRY как минимум. Чем это плохо? Мммм ну как вам объяснить? Вот те же SQL запросы заточены в 1000 файлов под Mysql, а завтра проект запустили под Постгресом — и Велкам! Рефакторить и чинить неработающую хрень.
Зато эти неявные зависимости упрощают разработку. От того, что мы порядка 4000 (1000*CRUD) SQL-запросов перенесём в ещё отдельные 1000 файлов, количество необходимых правок не изменится. Может чуть-чуть облегчится нахождение места, где правки нужно вносить, но и разработка усложнится, причём, возможно, не чуть-чуть. Другое дело если изначально стоит задача абстрагироваться от диалекта SQL или, вообще, от уровня хранения…
Да нет, нарушение IoC/DI вполне себе четко.
IoC/DI не правило или принцип, чтобы его нарушать. Да, это способ уменьшения связанности (связность — почти противоположный термин) и разграничения ответственности, но не всегда низкая связанность это хорошо. А способ это лишь способ, его можно использовать, а можно нет. При неиспользовании может нарушаться принцип единственной ответственности, а может не нарушаться. А что до принципов типа SOLID, то, имхо, ровно наоборот — человек должен понимать чем он жертвует ради их соблюдения и какие плюсы они дадут (как правило не сиюминутные). Не покупка просроченных продуктов, а, скажем, участие в долевом строительстве вместо взятия ипотечного кредита. Можно сразу улучшить жилищные условия и расплачиваться потом, а можно вложить деньги сейчас, но придётся подождать…
Порождение неявных зависимостей — нарушение SPOT/DRY как минимум. Чем это плохо? Мммм ну как вам объяснить? Вот те же SQL запросы заточены в 1000 файлов под Mysql, а завтра проект запустили под Постгресом — и Велкам! Рефакторить и чинить неработающую хрень.
Зато эти неявные зависимости упрощают разработку. От того, что мы порядка 4000 (1000*CRUD) SQL-запросов перенесём в ещё отдельные 1000 файлов, количество необходимых правок не изменится. Может чуть-чуть облегчится нахождение места, где правки нужно вносить, но и разработка усложнится, причём, возможно, не чуть-чуть. Другое дело если изначально стоит задача абстрагироваться от диалекта SQL или, вообще, от уровня хранения…
Да нет, нарушение IoC/DI вполне себе четко.
IoC/DI не правило или принцип, чтобы его нарушать. Да, это способ уменьшения связанности (связность — почти противоположный термин) и разграничения ответственности, но не всегда низкая связанность это хорошо. А способ это лишь способ, его можно использовать, а можно нет. При неиспользовании может нарушаться принцип единственной ответственности, а может не нарушаться. А что до принципов типа SOLID, то, имхо, ровно наоборот — человек должен понимать чем он жертвует ради их соблюдения и какие плюсы они дадут (как правило не сиюминутные). Не покупка просроченных продуктов, а, скажем, участие в долевом строительстве вместо взятия ипотечного кредита. Можно сразу улучшить жилищные условия и расплачиваться потом, а можно вложить деньги сейчас, но придётся подождать…
>Зато эти неявные зависимости упрощают разработку.
Это расхожее заблуждение.
> Другое дело если изначально стоит задача абстрагироваться от диалекта SQL или, вообще, от уровня хранения…
Конечно. Ну это же основы, первый класс. У вас есть высокоуровневые объекты и отношения между ними. А есть способ хранения и как это реализуется. Сегодня у нас PostgreSQL запросы, а завтра это переехало в NoSQL базы данных.
Ну ей богу, смешно. Есть идея и есть много реализаций. Кучи паттернов придумали для решения частных случаев этого подхода.
Нет, я не против. Есть мастера, которые вообще млять пишут, что шаблоны в PHP не нужны и нужно PHP-код писать вперемешку с HTML, только тогда это будет true. Правда, дать проект поддерживать новичкам почему-то такие товарищи боятся, да и другим коллегам часто тоже передать не могут.
>IoC/DI не правило или принцип, чтобы его нарушать.
Да в общем-то, и вежливость и рекомендация не хамить каждому встречному — тоже не правило или принцип, чтобы его нарушать. Только почему-то хамящий рано или поздно получает по морде, и как-то вежливость сама получается.
Так и тут — никто не говорит, пишите без принципов ООП, вообще без ООП, это все тупые мудаки придумали (я не шучу, есть известные гуру, которые считают, что ООП не оправдало своей роли и провалилось; ничего кроме сочувствия они не вызывают).
> Да, это способ уменьшения связанности (связность — почти противоположный термин)
Да, я опечатался. Мне непривычно говорить это, проще употреблять coupling / cohesion.
>и разграничения ответственности, но не всегда низкая связанность это хорошо. А способ это лишь способ, его можно использовать, а можно нет. При неиспользовании может нарушаться принцип единственной ответственности, а может не нарушаться.
конечно, не всегда хорошо, я об этом писал. иногда пишут все мегапросто ради скорости и т.д.
>А что до принципов типа SOLID, то, имхо, ровно наоборот — человек должен понимать чем он жертвует ради их соблюдения и какие плюсы они дадут (как правило не сиюминутные). Не покупка просроченных продуктов, а, скажем, участие в долевом строительстве вместо взятия ипотечного кредита. Можно сразу улучшить жилищные условия и расплачиваться потом, а можно вложить деньги сейчас, но придётся подождать…
Ну да, я согласен, это инструмент. Но в 99% случаев под веб ООП рулит.
Это расхожее заблуждение.
> Другое дело если изначально стоит задача абстрагироваться от диалекта SQL или, вообще, от уровня хранения…
Конечно. Ну это же основы, первый класс. У вас есть высокоуровневые объекты и отношения между ними. А есть способ хранения и как это реализуется. Сегодня у нас PostgreSQL запросы, а завтра это переехало в NoSQL базы данных.
Ну ей богу, смешно. Есть идея и есть много реализаций. Кучи паттернов придумали для решения частных случаев этого подхода.
Нет, я не против. Есть мастера, которые вообще млять пишут, что шаблоны в PHP не нужны и нужно PHP-код писать вперемешку с HTML, только тогда это будет true. Правда, дать проект поддерживать новичкам почему-то такие товарищи боятся, да и другим коллегам часто тоже передать не могут.
>IoC/DI не правило или принцип, чтобы его нарушать.
Да в общем-то, и вежливость и рекомендация не хамить каждому встречному — тоже не правило или принцип, чтобы его нарушать. Только почему-то хамящий рано или поздно получает по морде, и как-то вежливость сама получается.
Так и тут — никто не говорит, пишите без принципов ООП, вообще без ООП, это все тупые мудаки придумали (я не шучу, есть известные гуру, которые считают, что ООП не оправдало своей роли и провалилось; ничего кроме сочувствия они не вызывают).
> Да, это способ уменьшения связанности (связность — почти противоположный термин)
Да, я опечатался. Мне непривычно говорить это, проще употреблять coupling / cohesion.
>и разграничения ответственности, но не всегда низкая связанность это хорошо. А способ это лишь способ, его можно использовать, а можно нет. При неиспользовании может нарушаться принцип единственной ответственности, а может не нарушаться.
конечно, не всегда хорошо, я об этом писал. иногда пишут все мегапросто ради скорости и т.д.
>А что до принципов типа SOLID, то, имхо, ровно наоборот — человек должен понимать чем он жертвует ради их соблюдения и какие плюсы они дадут (как правило не сиюминутные). Не покупка просроченных продуктов, а, скажем, участие в долевом строительстве вместо взятия ипотечного кредита. Можно сразу улучшить жилищные условия и расплачиваться потом, а можно вложить деньги сейчас, но придётся подождать…
Ну да, я согласен, это инструмент. Но в 99% случаев под веб ООП рулит.
Это расхожее заблуждение.
Наверное для него есть основания… Про поддержку кода я ничего не говорил :)
Конечно. Ну это же основы, первый класс.
Вот честно, за десяток с лишним лет ни разу не приходилось менять движок SQL-СУБД, не говоря о переходе на не SQL хранилища или наоборот. То есть теоретически я пользу от абстрагирования или, хотя бы, «физического» (в разных файлах/функциях/методах) отделения системы хранения данных от бизнес-логики и остального понимаю, но на практике все что я делал для этого оказалось излишеством. Вполне достаточным оказалось не смешивать хранение и логику в одной функции/методе, а горождение многоуровневой абстракций типа
Есть мастера, которые вообще млять пишут, что шаблоны в PHP не нужны и нужно PHP-код писать вперемешку с HTML, только тогда это будет true.
Польза от шаблонов действительна не очевидна, учитывая что PHP сам по себе шаблонизатор и подавляющее большинство шаблонизаторов для него транслируют код шаблонов в него же. True, не true, но оверхид будет минимален. (Главное не забывать писать htmlspecialchars почти везде при echo. Собственно это основная причина почему я использую шаблонизаторы типа Twig или Smarty 3 — забывчив я и ленив :) ).
Наверное для него есть основания… Про поддержку кода я ничего не говорил :)
Конечно. Ну это же основы, первый класс.
Вот честно, за десяток с лишним лет ни разу не приходилось менять движок 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 — забывчив я и ленив :) ).
>Вот честно, за десяток с лишним лет ни разу не приходилось менять движок 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 — забывчив я и ленив :) ).
Все-таки шаблонизатор нужен как самостраховка. Если весь код написан нормально — новичок будет стараться писать неплохо. Если весь код с отделением в отдельный шаблонизатор, из кода видно как нужно делать контроллеры и т.д. — будут так писать
ИМХО!
Ну а вот мы за последние 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 — забывчив я и ленив :) ).
Все-таки шаблонизатор нужен как самостраховка. Если весь код написан нормально — новичок будет стараться писать неплохо. Если весь код с отделением в отдельный шаблонизатор, из кода видно как нужно делать контроллеры и т.д. — будут так писать
ИМХО!
Вы определитесь с областью, в которой хотите работать. Не стоит сразу ставить себе шоры. Составьте список интересных платформ/языков и выделите по 3-4 дня на первое впечатление. У каждого языка есть свои плюсы/минусы и своя область приложения.
PS:
>>Мне уже не стать профессиональным программистом, но до уровня junior`а с правильно
поставленными мыслями и руками мне бы очень хотелось дойти.
Вот не надо вешать на себя ярлыки. Главный вопрос «а нужно ли вам это?».
PS2:
я вимом пользуюсь, устраивает на все сто двадцать
PS:
>>Мне уже не стать профессиональным программистом, но до уровня junior`а с правильно
поставленными мыслями и руками мне бы очень хотелось дойти.
Вот не надо вешать на себя ярлыки. Главный вопрос «а нужно ли вам это?».
PS2:
я вимом пользуюсь, устраивает на все сто двадцать
могу отсортировать массив десятком методов… В общем, программированием владею как заурядный, но прилежный студент средненького технического вуза.
Хотел бы я посмотреть как заурядные студенты моего вуза (БГУ) отсортируют массив 10 способами, даже сразу после выпуска. Может, конечно, нас неправильно учили, но, если специально этим не заниматься, на выходе в памяти остаются 1-5 методов, в зависимости от «прилежности».
Как будто сам писал. Спасибо.
А вы в итоге как-то для себя решили проблему? У меня лично есть такое ощущение, что в IT отрасли достаточно много подобных нам универсалов, многие из нас хорошо устраиваются на менеджерские позиции, но когда денег на сытый прокорм семьи уже хватает, то появляется время «для души» и вылезают вот эти самые комплексы собственной недоделанности по одному из приоритетных направлений.
Я, в общем-то, перестал на это заморачиваться.: )
Иначе говоря, вашими словами, плюнул на эти «комплексы недоделанности», взял команду молодых парней программистов (некоторые из которых ой какие уже профи в Yii) и стал делать проект.
В отличие от них у меня есть опыт достижения результата в крайние сроки, планирования, манипулирования, общения с различными категориями людей, а у них есть время чтобы всему этому научиться, а главное, я могу взять на себя все то, что мешает им продуктивно программировать. Я организую работу, процессы, взаимодействие с другими отделами компании, а «для души» я постоянно лезу к ним и расспрашиваю о коде, советую, рассматриваю схемы, запрещаю реализовывать велосипеды, ищу уже готовые компоненты и заставляю их пробовать и т.п.
Кстати, рекомендую для развития читать книги с паттернами программирования, различными схемами, UML-диаграммами. Это позволяет общаться с программистами на близком языке, но на уровне алгоритмов, а не php, python или java. Я действительно научился у своих программистов многим новым трюкам, посмотрел на сколько это делает код безопасным, масштабируемым, модульным, понятным в конце концов (кстати, да мы на php работаем: ). Как всякие разные фичи из книг делаются в коде Yii, например. В итоге я понимаю, все что они пишут, но сам бы я так точно не написал (у меня было бы гораздо привычнее и громоздче) и тешу себя, что если что-то пойдет не так, то я-то уж точно залезу в код и исправлю косяки.
Резюме: учитесь использовать максимально то, что уже есть, а изучать технологии по пути.
Иначе говоря, вашими словами, плюнул на эти «комплексы недоделанности», взял команду молодых парней программистов (некоторые из которых ой какие уже профи в Yii) и стал делать проект.
В отличие от них у меня есть опыт достижения результата в крайние сроки, планирования, манипулирования, общения с различными категориями людей, а у них есть время чтобы всему этому научиться, а главное, я могу взять на себя все то, что мешает им продуктивно программировать. Я организую работу, процессы, взаимодействие с другими отделами компании, а «для души» я постоянно лезу к ним и расспрашиваю о коде, советую, рассматриваю схемы, запрещаю реализовывать велосипеды, ищу уже готовые компоненты и заставляю их пробовать и т.п.
Кстати, рекомендую для развития читать книги с паттернами программирования, различными схемами, UML-диаграммами. Это позволяет общаться с программистами на близком языке, но на уровне алгоритмов, а не php, python или java. Я действительно научился у своих программистов многим новым трюкам, посмотрел на сколько это делает код безопасным, масштабируемым, модульным, понятным в конце концов (кстати, да мы на php работаем: ). Как всякие разные фичи из книг делаются в коде Yii, например. В итоге я понимаю, все что они пишут, но сам бы я так точно не написал (у меня было бы гораздо привычнее и громоздче) и тешу себя, что если что-то пойдет не так, то я-то уж точно залезу в код и исправлю косяки.
Резюме: учитесь использовать максимально то, что уже есть, а изучать технологии по пути.
Я бы не заморачивался :)
Насчет IDE — пишу и дебажусь точно также — PSPad + F5.
Раньше был менее ленив, и ставил Aptana (бесплатная), но видимо мне и в PSPad неплохо.
MVC — не гарантия и не требование хорошего кода.
Раньше был менее ленив, и ставил Aptana (бесплатная), но видимо мне и в PSPad неплохо.
MVC — не гарантия и не требование хорошего кода.
Но с чего заново начать, чтобы расти правильным программистом
На самом ни с чего… т.е. всё придёт с опытом. И всё равно вы придёте рано или поздно к тому, что поймёте, что же вы хотите в итоге. Вы действительно хотите тратить 8 часов в сутки своей жизни сидя у компа и набирая код. Если «да» — тогда просто расслабьтесь и пишите код. Правильный код. Гуглите, читайте и т.д. Вы когда-нибудь встаните перед вопросом (что делать — писать код на дядю или попробоывать открыть своё дело, если конечно будете развиваться в том же направлении) и вам ответят — «это ваша жизнь» — поступайте так, как считаете нужным. Профессионализм во многом зависит от желания и цели человека. Никто и никогда не скажет что вы не понимаете в программировании — а если скажут — поверьте — это бизнесс(если конечно вы не соврали). Всё в ваших руках. А если вы пришли устраиваться на работу — и вам сказали что на позицию «junior php developer» вы не годитесь — поставьте себя на место управляющего и поймите, что они стараются минимизировать «затраты и риски». И не парьтесь. Просто развивайтесь. Надеюсь минусов не будет — ибо субъективаная точка зрения и совет.
На самом ни с чего… т.е. всё придёт с опытом. И всё равно вы придёте рано или поздно к тому, что поймёте, что же вы хотите в итоге. Вы действительно хотите тратить 8 часов в сутки своей жизни сидя у компа и набирая код. Если «да» — тогда просто расслабьтесь и пишите код. Правильный код. Гуглите, читайте и т.д. Вы когда-нибудь встаните перед вопросом (что делать — писать код на дядю или попробоывать открыть своё дело, если конечно будете развиваться в том же направлении) и вам ответят — «это ваша жизнь» — поступайте так, как считаете нужным. Профессионализм во многом зависит от желания и цели человека. Никто и никогда не скажет что вы не понимаете в программировании — а если скажут — поверьте — это бизнесс(если конечно вы не соврали). Всё в ваших руках. А если вы пришли устраиваться на работу — и вам сказали что на позицию «junior php developer» вы не годитесь — поставьте себя на место управляющего и поймите, что они стараются минимизировать «затраты и риски». И не парьтесь. Просто развивайтесь. Надеюсь минусов не будет — ибо субъективаная точка зрения и совет.
Прежде чем учиться что-то делать «правильно» нужно понять одну простую мысль: не бывает абсолютного «правильно» — та или иная техника, правило или запись на скрижалях появилась по определенным причинам и только для решение оных она хороша. Во всех остальных случаях «правильность» спорна и неизбежный оверхед от дополнительных телодвижений будет только во вред.
Например из того что привели:
1 MVC создавались что бы разделить работу разных людей — верстальщика, программиста и бизнес-аналиста. Также такое разделение хорошо работает там где надо много менять уже рабочий код — например при внедрении бизнес приложения, потому что люди которые пользуются приложением, создают для него ТЗ и пишут приложение, мало того что разные, но зачастую просто не понимают друг друга и только итерационно можно придти к нужному результату — в этом случае небольшие изменения с меньшей вероятностью поломают что-то другое и рабочее.
Также любое логичное разделение хорошо работает если приложение собирается развиваться — тогда разные части как бы независимы и могут меняться и рефакториться без ущерба для остальных частей. Но это уже концепция ООП.
2 Есть SQL-иньекции и есть непредусмотренное функционалом использование входящих данных — надо данные проверять на валидность. И делать это не только при получении через http — например валидация данных полезна для интерфейсов в отдельном модуле или в публичных методах класса — это защита от ошибок в других местах приложения.
Также хорошо делать корректную обработку ошибок — они всегда будут появляться и хорошо когда они хотя бы корректно падают в лог и не роняют приложение.
Еще хорошо всегда инициализировать переменные и массивы, не надеясь на дефолт, проверять корректность всяких ключей и индексов и иметь отработку если они некорректные.
3 форматирование кода нужно имхо лишь для того что бы быстро читать код, не спотыкаясь на хитрых конструкциях. Это важно в команде. Какие при этом будет выбраны правила — неважно, главное что бы они были удобны и приняты всеми членами команды. Что бы избежать неизбежных холиваров, лучше найти style guide для используемых инструментов или выбрать из публичных и распространенных.
IDE лучше взять помощнее и разобраться с ним — это хороший урок. Посмотреть что там с форматированием есть. Попробовать рефакторинг. Пощупать code navigation. Разобраться с проектами и так далее — это все так или иначе относится к «хорошим практикам» и ответам на заданные выше вопросы.
Могу также посоветовать разбирать написанный вашими достойными программистами код. Задавайтесь вопросами — почему так а не по другому, думайте как бы вы сами написали данный кусок, ищите альтернативы. Не стесняйтесь задавать вопросы — профи уже давно знает ваш уровень, главное что бы работе не мешало :)
Например из того что привели:
1 MVC создавались что бы разделить работу разных людей — верстальщика, программиста и бизнес-аналиста. Также такое разделение хорошо работает там где надо много менять уже рабочий код — например при внедрении бизнес приложения, потому что люди которые пользуются приложением, создают для него ТЗ и пишут приложение, мало того что разные, но зачастую просто не понимают друг друга и только итерационно можно придти к нужному результату — в этом случае небольшие изменения с меньшей вероятностью поломают что-то другое и рабочее.
Также любое логичное разделение хорошо работает если приложение собирается развиваться — тогда разные части как бы независимы и могут меняться и рефакториться без ущерба для остальных частей. Но это уже концепция ООП.
2 Есть SQL-иньекции и есть непредусмотренное функционалом использование входящих данных — надо данные проверять на валидность. И делать это не только при получении через http — например валидация данных полезна для интерфейсов в отдельном модуле или в публичных методах класса — это защита от ошибок в других местах приложения.
Также хорошо делать корректную обработку ошибок — они всегда будут появляться и хорошо когда они хотя бы корректно падают в лог и не роняют приложение.
Еще хорошо всегда инициализировать переменные и массивы, не надеясь на дефолт, проверять корректность всяких ключей и индексов и иметь отработку если они некорректные.
3 форматирование кода нужно имхо лишь для того что бы быстро читать код, не спотыкаясь на хитрых конструкциях. Это важно в команде. Какие при этом будет выбраны правила — неважно, главное что бы они были удобны и приняты всеми членами команды. Что бы избежать неизбежных холиваров, лучше найти style guide для используемых инструментов или выбрать из публичных и распространенных.
IDE лучше взять помощнее и разобраться с ним — это хороший урок. Посмотреть что там с форматированием есть. Попробовать рефакторинг. Пощупать code navigation. Разобраться с проектами и так далее — это все так или иначе относится к «хорошим практикам» и ответам на заданные выше вопросы.
Могу также посоветовать разбирать написанный вашими достойными программистами код. Задавайтесь вопросами — почему так а не по другому, думайте как бы вы сами написали данный кусок, ищите альтернативы. Не стесняйтесь задавать вопросы — профи уже давно знает ваш уровень, главное что бы работе не мешало :)
Спасибо. По последнему абзацу: я именно так и стараюсь делать, но при этом понимаю, что деньги я им плачу не за обучение меня, а за разработку. Но в целом именно желание понимать написанное во всех нюансах меня толкает к прокачке собственных скилов.
Я добавлю по последнему абзацу из своей практики: у нас стоит Redmine с хранилищем Mercurial'а, так там все добавленные изменения кода программистами можно сравнить, посмотреть, покрутить, задать вопрос: «А чой-то так-то вдруг теперь?»: ) И это круто, потому как программисты могут и любят объяснять свой код: «Ну, тут мы к объекту интерфейс добавили, теперь вот методы наследовались, а раньше было не так удобно».
Я вот здесь вижу много комментариев, советующих переучиваться на python или другой язык, потому как PHP «позволяет писать говнокод» и т.д. и т.п. Спорить тут я не стану — у PHP есть проблемы, но у какого языка их нет? Я уже не первый раз начинаю думать, что существует некоторое число PHP-шников с комплексом по поводу используемого языка. Обычно это происходит так: человек кодит на PHP, но постоянно со всех сторон слышит то шутливые, то серьезные холиварные заявления о том, что PHP это недоязык или язык для быдлокодеров, или что писать на PHP непрофессионально, или что он позволяет писать страшный говнокод. В дополнение к этому, в таких холиварах часто наводятся всякие рассказы о том, как кто-то влиятельный и авторитетный прикалывается над PHP ("… Мы заказываем пиццу через сайт. Так вот тот сайт сделан на PHP...").
Такой человек начинает испытывать комплекс, старается переучиться — а в то же время нужно за что-то жить и зарабатывать деньги. Такой человек продолжает вынужденно писать на PHP, по крайней мере какое-то время, но уже не учит ничего нового, связанного с этим языком. Потом этот человек углубляет познания, скажем, в python'e, и восхищенно рассказывает о его супер-преимуществах над PHP. Причем, что смешно, довольно часто эти преимущества оказываются несущественными, а еще чаще — наводятся вовсе неправильные примеры, не являющиеся преимуществами. Я, к примеру, видел PHP-шников, которые довольно успешно по несколько лет работали с этим языком, использовали фреймворки и делали рабочие продукты, но не знали о существовании анонимных функций и callback'ов в PHP, восхищаясь затем этим функционалом в других языках.
Выводов у меня несколько:
1. Когда человек испытывает комплекс по поводу используемого языка, он зачастую перестает развивать знания этого языка, и метается от одного к другому — в итоге не становится профессионалом ни в одной области (ни в одном языке). Лично мое мнение — чтобы судить об языке и сравнивать его с другими, нужно быть профессионалом в сравниваемых языках. Станьте профессиональным PHP-программистом, изучите все его возможности, а потом ругайте его.
2. PHP — замечательный язык, и достоин того, чтобы изучить его вдоль и поперек.
3. Знать другие языки — это хорошо, но не стоит метаться от языка к языку, не успев освоить хорошо хотя бы один.
З.Ы. Сразу хочу отметить, что ни в коем случае не пытаюсь холиварить или применьшить значимость того же python'а. Чтобы было понятнее — я использую и PHP, и Python, и обожаю оба эти языка — да-да, при этом я не говорю, что один из них говно, а второй конфетка.
Такой человек начинает испытывать комплекс, старается переучиться — а в то же время нужно за что-то жить и зарабатывать деньги. Такой человек продолжает вынужденно писать на PHP, по крайней мере какое-то время, но уже не учит ничего нового, связанного с этим языком. Потом этот человек углубляет познания, скажем, в python'e, и восхищенно рассказывает о его супер-преимуществах над PHP. Причем, что смешно, довольно часто эти преимущества оказываются несущественными, а еще чаще — наводятся вовсе неправильные примеры, не являющиеся преимуществами. Я, к примеру, видел PHP-шников, которые довольно успешно по несколько лет работали с этим языком, использовали фреймворки и делали рабочие продукты, но не знали о существовании анонимных функций и callback'ов в PHP, восхищаясь затем этим функционалом в других языках.
Выводов у меня несколько:
1. Когда человек испытывает комплекс по поводу используемого языка, он зачастую перестает развивать знания этого языка, и метается от одного к другому — в итоге не становится профессионалом ни в одной области (ни в одном языке). Лично мое мнение — чтобы судить об языке и сравнивать его с другими, нужно быть профессионалом в сравниваемых языках. Станьте профессиональным PHP-программистом, изучите все его возможности, а потом ругайте его.
2. PHP — замечательный язык, и достоин того, чтобы изучить его вдоль и поперек.
3. Знать другие языки — это хорошо, но не стоит метаться от языка к языку, не успев освоить хорошо хотя бы один.
З.Ы. Сразу хочу отметить, что ни в коем случае не пытаюсь холиварить или применьшить значимость того же python'а. Чтобы было понятнее — я использую и PHP, и Python, и обожаю оба эти языка — да-да, при этом я не говорю, что один из них говно, а второй конфетка.
Забыл добавить вывод в стиле Кэпа:
На любом языке можно писать как страшный говнокод, так и изящнейший код.
На любом языке можно писать как страшный говнокод, так и изящнейший код.
У меня в голове диссонанс наступает как раз от того, что, как вы подметили, массы ругают PHP, а меня тот же самый PHP постоянно выручал и любой алгоритм мне проще и быстрее воплотить именно на нём. Так что, да, проблема «травли» действительно существует.
Хорошо подмечено про комплексы. Но, с другой стороны, многие фичи, те же callable (ФВП по сути), прикручены к PHP не самым очевидным и простым образом и изучать их на примере PHP не самый эффективный путь. И зацикливаться на одном языке, по-моему, не стоит. Следует изучать общие концепции программирования как бы абстрактно, а уж потом смотреть как они реализованы на том или ином языке. Решать задачу в терминах высокоуровневых абстракций, а потом подбирать инструмент(ы), которым лучше эти абстракции выразить. А не так, что решение задачи (а то и постановку) подгонять под любимый (а то и единственный) инструмент.
В общем, по-моему, с самого начала освоения «правильного» программирования имеет смысл одну и ту же задачу решать с помощью нескольких языков (желательно как-то оставаясь в рамках best practices каждого языка) и сравнивать полученные решения, анализируя достоинства и недостатки.
В общем, по-моему, с самого начала освоения «правильного» программирования имеет смысл одну и ту же задачу решать с помощью нескольких языков (желательно как-то оставаясь в рамках best practices каждого языка) и сравнивать полученные решения, анализируя достоинства и недостатки.
/немного подумав/ Поддерживаю. Каждый язык хорош для своих задач, для которых он, собственно, и используется. И если сегодня мы решаем другие задачи — это значит только, что этот язык нам не подходит для этих задач. Как сказал МакКоннелл, «Программируйте не на языке, а с использованием языка» ©.
> «Программируйте не на языке, а с использованием языка» © МакКоннелл
Все приходят к этой мысли, когда знают более 2-3 языков программирования. Я использую порядка 7ми языков программирования и каждый из них выполняет для меня свою задачу. Наверное с изучения 4го языка, я перестал обращать внимание на споры, какой язык лучше.
Все приходят к этой мысли, когда знают более 2-3 языков программирования. Я использую порядка 7ми языков программирования и каждый из них выполняет для меня свою задачу. Наверное с изучения 4го языка, я перестал обращать внимание на споры, какой язык лучше.
Я сейчас порву тутошние шаблоны: учи C#. Без подколок. И в веб сможешь и ООП правильный и типизация строгая.
Для начинающего я бы вообще посоветовал забыть об IDE, вы должны сначала научится помимать как всё работает. ООП, паттерны не что иное как попытка управлять сложностью, подходы которые работают для 100-1000 строчек и количество состояний системы менее 20-50 перестают работать для проэктов с большим количеством состояний/строчек.
Как вступление в ООП, паттерны я рекомендую обычно Крега Лармана «Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку» но для совсем новичкам она бывает сложна, тогда можно смотреть серию OReily Head First Patterns если есть перевод на русском.
О PHP для понимания концепций стоит лучше забыть, есть языки более выразительные. И даже если вы исспользуете PHP для комерческой разработки, знакомство с другими языками рассширит ваш кругозор и позволит исспольховать некоторые конструкции для построения более качественных решений. Насчёт языка я бы порекомендовал Python, но это уже больше дело вкуса.
Как вступление в ООП, паттерны я рекомендую обычно Крега Лармана «Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку» но для совсем новичкам она бывает сложна, тогда можно смотреть серию OReily Head First Patterns если есть перевод на русском.
О PHP для понимания концепций стоит лучше забыть, есть языки более выразительные. И даже если вы исспользуете PHP для комерческой разработки, знакомство с другими языками рассширит ваш кругозор и позволит исспольховать некоторые конструкции для построения более качественных решений. Насчёт языка я бы порекомендовал Python, но это уже больше дело вкуса.
Стоит! FaceBook и ВК частично написан на PHP.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стоит ли смотреть в сторону PHP тому, кто решился только со второй попытки научиться прилично программировать?