Когда её нет
Низкий порог вхождения, легкий способ прострелить себе ногу, потратьте свою энергию на изучение настоящего языка программирования — много обидных слов может услышать PHP-разработчик от коллег-программистов, которым посчастливилось освоить другие технологии. PHP удобно ругать всем, — каждый посвященный может найти, за что зацепиться. Тем не менее, на рынке до сих пор очень востребованы хорошие специалисты, способные писать качественный код на этом языке. Более того, если вы выбрали этот путь, на собеседовании в серьезной компании с подкованными технически руководителями и старшими программистами вы вряд ли услышите что-нибудь глумливое про PHP.
Во многом такое негативное отношение объясняется отсутствием культуры программирования у большого количества PHP-разработчиков. Почему так происходит? Да, у этого языка действительно низкий порог вхождения и легко освоить его может человек без специального технического образования. Изучив основы, можно сразу делать небольшие проектики и даже продавать свои услуги на биржах фрилансеров. А раз на такое есть спрос, зачем тратить время на углубление своих знаний, когда деньги можно зарабатывать уже сейчас?
Иногда случается чудо, — такие проекты «взлетают» и их владельцам требуется расширение функционала и увеличение производительности, а связь с человеком, который год назад всё это наваял, увы, уже оборвалась. Да и у владельцев появились средства на оплату труда настоящих профессионалов.
И вот приходит специалист на поддержку всего этого наследия, клонирует себе репозиторий (в лучшем случае, — бывает, что о контроле версий там и не слыхали) и потихоньку начинает седеть от ужаса. Коллеги ухмыляются — «Ах, да, это же PHP! А чего ты хотел? Каков язык, таков и код». А еще, если с проектом через какой-нибудь API нужно взаимодествовать другим частям разветвленной системы, то «похапэшника», создавшего это, начинают проклинать все технические специалисты в организации. Если вы начинающий PHP-разработчик и вы не любитель унижения, боли и всего такого прочего, попробую поделиться с вами положительным опытом.
Быть культурнее
Мы можем говорить о какой-то общей культуре, когда существует набор символов, кодов, объединяющий нас. У разработчиков программного обеспечения есть
К примеру, я сам начинал разрабатывать на PHP, когда дикая смесь HTML кода с логикой и можество точек вхождения еще не казались чем-то ужасным. Я был абсолютно бескультурным программистом, у меня не было технического образования, про язык я знал из форумов и книги Люка Веллинга и Лоры Томсон «Разработка веб-приложений с помощью PHP и MySQL», но такое положение вещей доставляло много боли. Я даже не слышал такого термина «точка вхождения». Пришла мысль — как бы направить все запросы только к одному скрипту и обрабатывать их централизовано? Любознательность заставила изучить конфигурацию Apache и возможности .htaccess.
Потом пришло понимание, что инвестиции в собственные знания всегда многократно окупаются, — это беспроигрышный вариант. А культура программирования как раз основана на знаниях (но не только), и это основная ценность в сообществе разработчиков.
Культура — это текст
Я встречал программистов, не любивших читать техническую литературу. Не скажу, что это были плохие знатоки своего дела. Чаще всего, на вопрос, почему ты не знаешь этого автора или как ты мог пропустить второе издание, там ведь как раз про то, над чем ты работаешь, отвечают: зачем тратить долгие часы на чтение потоков воды, когда знание можно получить в сжатом и удобном виде из документации и чего-то вроде stackoverflow. Конечно, в ходе разговора часто выяснялось, что это небольшое лукавство, в культурном багаже уже есть и Банда Четырех, и «Совершенный код», и «Программист-прагматик»… Мы понимаем друг друга.
Сейчас серьезные бородатые апологеты Java и C++ зададут вопрос — а какое все это имеет отношение к PHP? Не закидывайте меня порчеными овощами — на PHP тоже можно писать красивые вещи, если, конечно есть глубокое понимание того, как это делать. А оно невозможно без широкого контекста культуры программирования. Увидеть красоту языка, понять, как нужно делать правильно, мне помогла книга Мэтта Зандстры «PHP. Объекты, шаблоны и методики программирования». После первого прочтения многое было непонятно, но возникло непреодолимое желание поглощать технические тексты мегабайтами.
А позже стало ясно, что знать хорошо какой-то язык программирования можно, если знаешь другие языки. Получить хорошую теоретическую базу в этом плане мне сначала помогла книга Бьярне Страуструпа «Программирование: принципы и практика использования C++» (в общем-то, когда-то ее чтение и навело меня на мысль написать статью о культуре программирования и PHP). И не обязательно оттачивать свои способности в другом языке до совершенства (хотя, скорее всего, что-то из этого в итоге будет доставлять больше радости, чем PHP), достаточно понимать принципы и различия. Такой разносторонний взгляд открывает скрытые ранее возможности сделать свой код понятнее и производительнее, а видя в ваших исходных текстах знакомые шаблоны проектирования, гуру Java уже не будут косо смотреть на вас (ну, разве что чуть-чуть, по привычке).
Комментарии (117)
Fesor
25.09.2015 17:09+1Люка Веллинга и Лоры Томсон
О, помню помню, я по ней разбирался… А сейчас видеоуроки подавай…
Boeses_Genie
26.09.2015 00:12Видеоуроки тоже неплохо. Люди воспринимают информацию лучшим образом разными каналами восприятия. По мне, так лучше читать книги и выполнять задания и интересные примеры, как-то структурированнее, обстоятельнее получается… Но хорошая живая лекция на видео тоже многое проясняет, живой человек лучше мотивирует, ему хочется верить.
Fesor
26.09.2015 00:46+1Ключевое слово — лекция. Большинство же учатся по видеоурокам в духе «возьми и делай так», у людей не формируется мышление, они просто не хотят думать.
Boeses_Genie
26.09.2015 00:53В принципе, дело не только в способе передачи информации тогда — видео или текст. а, получается, в качестве. Книги «1001 рецепт сайта на PHP» или там, «Крутые трюки на PHP» тоже часто встречаются. И отфильтровать этот шлак как раз и позволяет культура программирования.
cepreu4habr
28.09.2015 07:54+4А мне одному кажется, что смотреть видео — это дольше, чем то же самое прочитать?
Boeses_Genie
28.09.2015 08:06По своему субъективному опыту. Есть хорошие лекции на видео. Но обучение по ним должно быть активным. Если просто прослушать/просмотреть, и ничего не попробовать из рассказанного — на следующий день всё это вылетит из головы. Обязательно надо прорешать предложенные примеры, обдумать поставленные вопросы. И, самое, может быть, полезное, — опробовать знания на практике, чтобы оценить реальные плюсы от них. Что касается скорости обучения, думаю, тут всё индивидуально. Кто-то быстрее учится по видео, кто-то — по книгам.
MikeLP
28.09.2015 07:42Прикольно. Я как и автор вошел «в тему» после этих 2-х книг. Понятно, что всем все равно), но это как минимум значит что книги отличные!
marenkov
25.09.2015 17:13-1Самая большая проблема PHP — простота освоения. Представьте что творилось бы с авиа полетами если бы лицензию пилота можно было бы получить так же просто как водительское удостоверение. И что было бы на дорогах, если бы ездить разрешили всем желающим без каких либо экзаменов. В идеале, прежде чем разрешать программировать на PHP, надо бы требовать пописать некоторое время на С/С++ (или подобном). Сам я прошел путь: машинные коды и ассемблер — pascal — c/c++ — perl — php — фреймворки на php, и я в ужасе от 80% кода на php.
Fesor
25.09.2015 18:05+2надо бы требовать пописать некоторое время на С/С++ (или подобном)
ну да ну да, будет только хуже. Лучше познакомить их с .NET/Java тогда. Но тогда вопрос, зачем им PHP?
SerafimArts
25.09.2015 19:39PHP всё же лаконичнее джавы, процентов на 25%-30%, да и вольности с типами порой позволяют сокращать алгоритмы (микроархитектуру) раз в 10.
P.S. К списку .NET/Java добавлю Haxe. Из той же оперы.Fesor
25.09.2015 21:12Haxe… как-то видел но не тыкал.
PHP всё же лаконичнее джавы
нуу, потому мне больше нравится C#, но что-то как-то все сижу на PHP. Я к слову не так много джавистов знаю кто мог бы поддерживать беседу когда говорят о TDD, DDD и т.д. Среди .NET-чиков это как-то больше распространено, но может быть у меня выборка не репрезентативна.
По поводу микроархитектуры — в чем-то это так. Но типизации для массивов не хватает.SerafimArts
25.09.2015 21:21Говорят TDD умер, правда ли это? =)
Fesor
25.09.2015 21:49TDD это лишь идея. Идея о том что коду должны предшевствовать тесты, как самый простой способ формализации требований для программиста. Если нет красных тестов, нет смысла писать код. Далее пошло развитие ATDD, с приемочными тестами вместо юнит тестов, и далее уже BDD где в качестве приемочных тестов выступают поведенческие сценарии. Но цикл разработки остается все таким же — красный — зеленый — рефакторинг.
Проблема в другом. TDD это лишь одна из методик предлагаемых в экстримальном программировании (XP). Если люди не в состоянии разобраться с такими относительно простыми идеями как канбан, то куда уж им… Тут на днях вышла интересная дискуссия с одним человеком, который уверял меня что TDD это не жизнеспособная методология, потому что он на одном из проектов следуя TDD месяц писал чисто тесты. Как по мне это явное противоречие подходу. Аналогично один товаристч уверял меня что канбан это есть зло и анархия. При этом все те доводы которые он приводил основываясь на том, как канбан был введен на его проекте, никакого отношения к этому самому канбану не имели.
Ну и да, на собеседованиях часто слышал от ребят всякий трэш в духе XP это когда овертаймишь, деплоишься ночью и т.д (иначе зачем называть «экстримальным»?) и когда узнают что это является грубым нарушением идей XP уже начинают интересоваться что же это такое.SerafimArts
25.09.2015 23:10-1Если честно, даже не пробовал никогда ничего писать по TDD. Тесты всегда на потом оставляю, покрываю только самое критичное, стараюсь сразу писать хороший код. Наверное это не правильно, но проекты не серьёзные особо, 3-4 человека на одном проекте максимум.
Последнее время прямо безумно фанатею по контрактам (DbC), можно ли их рассматривать как некую альтернативу TDD, получая код такого же качества (ну или допустимого), как и при использовании сабжа? Я не рассматриваю сейчас доктриновские аннотации в качестве реализации, это ещё не совсем по-моему продакшн, а скорее как общую концепцию.Fesor
25.09.2015 23:32Ну я совру если скажу что я так уж активно применяю TDD, хотелось бы но на моих проектах в этом нет смысла. Я активно использую ATDD на основе Behat и пытаюсь форсить идеи BDD, а TDD пользуюсь только когда пишу библиотечки, и это реально удобно. С другой стороны у меня уже был опыт с проектами где TDD спосло бы хоть немного, учитывая сложность бизнес логики.
Что до контрактов… не уверен. Идея контрактов состоит в том что бы быть дополнительной проверкой работоспособности бизнес логики на уровне одного метода. Это круто работает на особо критичных системах, например в финансовом секторе DbC любят и пользуют, но лично я не фанат. Отличие же от TDD в том что, последний является большим подспорьем в проектировании системы, нежели в верификации корректности ее работы. Если вам становится тяжко поддерживать тесты (например один класс требует замокать 5 других что бы написать простенький тест), то это скорее всего будет свидетельствовать о необходимости рефакторинга. С контрактами так не выйдет, там даже нет такого понятия как mock.
OnYourLips
27.09.2015 11:22> Лучше познакомить их с .NET/Java тогда. Но тогда вопрос, зачем им PHP?
Вы так говорите, как будто PHP хуже, чем .NET/Java.
Потому что PHP эффективнее решает ряд задач и находится где-то посередине между Rails/Python и .NET/Java, позволяя использовать себя как в стартап проектах, где нужно быстро разрабатывать определённый функционал, так и в крупных бизнес-проектах.
И это дает PHP разработчику гораздо больше возможностей. В том числе и зарплатных: российский PHP-девелопер получает после кризиса в полтора-два раза больше, чем .NET/Java разработчик аналогичного уровня из-за популярности технологии на фрилансе.
MaximChistov
27.09.2015 11:54-1Ну вот сказки не рассказывайте) Java все ещё самая выгодная, если речь об энтерпрайзе
Fesor
27.09.2015 12:35+1Вы так говорите, как будто PHP хуже, чем .NET/Java.
Вы так говорите как буд-то бы это не так. Java лично мне не нравится, но вот C# нежный. PHP действительно эффективнее решает ряд задач, именно поэтому я на нем и пишу.
российский PHP-девелопер получает после кризиса в полтора-два раза больше, чем .NET/Java разработчик аналогичного уровня
Ну на счет российских реалий я не вкурсе, но в Беларуси они получают примерно одинаково. Вот только PHP разработчиков которые смогут потягаться с .NET/Java синьерами не так уж и много.
Ну и да, я не беру в расчет всяких вордпресс девелоперов, магенту девелоперов и т.д. К слову чуваки которые пишут магазинчики на магенту получают очень даже неплохо.
skey
25.09.2015 18:14+4Просто на начальном этапе нужен опытный ведущий программист со знанием и применением хороших практик программирования.
Но к сожалению, в большинстве случаев бывает так: небольшая команда самоучек написала систему и решила, что на этом можно зарабатывать. Деньги потекли, программистов наняли, система разрослась, а рефакторить некогда было. Вот оттуда и выходят потом пхпшники без культуры программирования.
jrip
25.09.2015 18:58А зачем вы ушли из c/с++ на PHP?
>Самая большая проблема PHP — простота освоения.
Простота в чем? написать hello world? Чем сложнее, например С?
Или вы про то, что язык в котором 100500 фреймворков, cms, подходов в программировании — просто освоить?
>И что было бы на дорогах, если бы ездить разрешили всем желающим без каких либо экзаменов.
Экзамены… ну да, прям таки у всех, какой вы наивный :)
>В идеале, прежде чем разрешать программировать на PHP, надо бы требовать пописать некоторое время на С/С++ (или подобном).
Это как бы чем поможет то? Как бы не стоит писать на PHP так, как писали бы на С…
> и я в ужасе от 80% кода на php.
Ужас возникает от непонимания, потом остается только легкое отвращение, которое не вызвает особых эмоций.
Ну типа страшно только первые лет пять :D
michael_vostrikov
25.09.2015 20:40+9Не автор коммента, но попробую рассказать, зачем я ушел из C++ на PHP.
Просто не было работы на C++ в моем городе. Совсем. И в соседних городах тоже редко появлялись. Да и опыт обычно требовался. Зато на PHP вакансий было гораздо больше. После универа я знал только C++, писал на нем все лабы и курсовые. Еще знал ассемблер, но его можно не считать. Помаявшись полгода по небольшим халтуркам, решил изучить веб-программирование. Поначалу было непривычно, потом оказалось, что это очень удобно, когда строки обрабатываются на уровне языка. Когда не надо преобразовывать числа в строки и обратно вручную. Или следить за границами массивов и правильным доступом в память. А через HTML и CSS закодировать интерфейс в большинстве случаев проще, чем на C++ — попробуйте через device context нарисовать на форме поле для тетриса. Но знание C++ дало мне понимание, как программа работает внутри — например, что сравнение строк это не то же самое, что сравнение целочисленных переменных, и оно требует дополнительных ресурсов, или как работает передача по ссылке и чем она отличается от передачи по значению.
Hello world на обоих этих языках написать несложно, а вот вывести табличку с разнородными данными из БД и внизу еще строчку «Итого» на PHP будет попроще.jrip
25.09.2015 20:56Я не спрашивал зачем ушли из С++, спрашивал зачем ушли в PHP, все-таки совсем другая сфера получается и другой подход ))
>Hello world на обоих этих языках написать несложно, а вот вывести табличку с
>разнородными данными из БД и внизу еще строчку «Итого» на PHP будет попроще.
Проще это чутка меньше буков?)
SerafimArts
25.09.2015 21:00Главное не пробуйте применять эти знания для оптимизации. Зачастую всё можно наоборот замедлить, т.к. php изначально затачивался под общие правила. Например работа с бинрниками будет медленнее, чем с интами. Умножение на флоаты по скорости будет так же, как деление на инт. Передача по ссылкам везде и всюду может только усложнить код и сломать логику работы GC. И прочее…
Правило работает не со 100% вероятностью конечно же, но лучше писать красиво и чисто, нежели код побыстрее (потом всегда его можно ускорить).jrip
25.09.2015 21:06-1Думать в php о скорости работы арифметических операций? о GC??
Да вы блин серьезно?Fesor
25.09.2015 21:21о GC??
в любом языке со сборщиком мусора следует помнить о GC, особенно учитывая определенные ограничения оного. Вспомните сюжет этой зимы, когда в composer ради оптимизации обработки графа зависимостей просто отключали GC, который быстро упирался в лимит в 10000 связанных элементов и на каждый чих жрал процессорное время.
Это конечно нужно тоьлко для <1% задач которые решают на PHP, но все же…jrip
25.09.2015 21:31Есть мнение, что для этих 1% задач пхп лучше не использовать, если хочется чтобы все нормально работало. И явно не 1% а даже меньше и там хватает более серьезных проблем, о которых автор сообщения не указал, поэтому про GC было смешно)
SerafimArts
25.09.2015 21:41React, Ratchet, Guzzle и прочие пакеты для асинхронной и\или постоянной работы с вами не согласны. ;)
jrip
25.09.2015 21:45-1Ок. В какой задаче реальной у вас появилась необходимость постоянной работы пхп и почему вы его там использовали?
Fesor
25.09.2015 21:57+1У меня уже чуть меньше года на продакшене крутится чатик с плюшками на reactphp и все вроде бы не плохо. Знаю ребят у которых используется php-pm с целью уменьшения нагрузки на сервер (бойлерплейт фреймворков аля symfony жрет довольно много, php-pm невилирует время инициализации и на простых запросах может экономить до 50% времени обработки оных).
Так же у меня есть демоны для работы с APNS на PHP, есть обработчики очередей и т.д. Все поднимается супервизором и живет себе не тужит.
почему вы его там использовали?
Ну конкретно мой пример не очень показателен. Просто разработчику который начинал проект захотелось попробовать реакт. Но в целом я не вижу в этом ничего дурного, особенно мне нравятся решения в духе php-pm.
Вообще PHP нормально живет в виде демона начиная с PHP 5.3, когда ввели в тот самый GC управление циклическими ссылками. А проблема composer-а весьма специфична. Такое можно получить только когда работаешь с очень большими графами на PHP, что весьма и весьма редкая задача. И тут стоит знать как работает GC, да и вообще это хорошо, знать как работает инструмент с которым ты работаешь, погрузиться хотя бы на один слой абстракции ниже.jrip
25.09.2015 22:10+1У меня один из демонов, написанных на пхп, причем не самый простой был выключен с аптаймом более полугода :) GC того что появился, кажется в 5.3, кстати, тогда еще не было.
В целом вы правы, но не правильно ставите акценты. Нужно думать не о GC, нужно понимать как пхп в целом работает с памятью.Fesor
25.09.2015 22:43Нужно думать не о GC, нужно понимать как пхп в целом работает с памятью.
Полностью согласен.
SerafimArts
26.09.2015 03:25+1Гиттер-бот для группы Laravel, который подсчитывает карму для пользователей. Карма инкрементится за "@user спасибо" и аналогичных. Сейчас он на js, но решили перейти на пых, т.к.
1) Единый стек для сайта (laravel.su\laravel.ru), плюс ларка.
2) Пых позволяет писать более качественный код — тайп-хинтинг, интерфейсы, абстрактные классы\методы и прочее.
3) Опыт и «почему бы и нет?»
0.5) Он вообще под php7 RC3 вертится =)
Исходники доступны в гитхабе, ссыль могу кинуть в личку или тут. Дабы не спамить. За ночь работы (с четверга на пятницу) он схавал один мегабайт памяти (чистый запускается с 14 метрами, на утро было ~15.5) при этом никаких тюнингов не было, более того, наоборот много оверхедов для удобства.
PQR
27.09.2015 07:45А на js сколько этот бот потреблял памяти?
Fesor
27.09.2015 12:40На node.js потребление памяти обычно больше, но в целом 10 или 20 мегабайт это настолько мелочно. Нода крута когда речь идет о работе с вводом выводом, потому чатики и прочее на нем писать хорошо. Но иногда проще написать демон на PHP.
SerafimArts
27.09.2015 21:27Говорят что, цитата: «если я всё правильно смотрю, то 66 мб сам процесс и 22 мб монитор forever».
MTonly
27.09.2015 22:55На всякий случай: мб — это миллибит.
SerafimArts
28.09.2015 00:10Спасибо, не знал. В любом случае из контекста понятно что имелось ввиду.
P.S. миллибит вообще не нагуглился, если не сложно — киньте ссыль в личку, хотя бы почитаю что это такое.Fesor
28.09.2015 00:43миллибит не существует. Бит это квант данных, меньше быть не может, вы же это понимаете? А товаристч придрался к тому что у вас с маленькой буквы обозначение, что буквально читается как мили бит. Мега и байт всегда пишутся с большой.
VolCh
28.09.2015 00:58+1Формально говоря, меньше бита данные могут быть, бит лишь минимальная единица наблюдаемого состояния источника данных (в данный конкретный момент времени в ходе конкретного наблюдения). На то он и квант, что есть квантовая неопределенность :)
SerafimArts
02.10.2015 02:51Если кому интересно — статитика работы бота на php7rc3 после одного дня работы:
[Client started at Thu, Oct 1, 2015 2:31 AM]
[24:19:29]: 10.49mb usedFesor
02.10.2015 09:351 день это ничто, у меня скажем был прецедент когда демон начинал подтекать потихоньку и за месяц работы сервак потихоньку начинал уходить в своп, то тут я виноват а не PHP, у меня там постоянно увеличивался буфер для отправки сообщений и не отчищался.
jrip
25.09.2015 21:04>Когда не надо преобразовывать числа в строки и обратно вручную.
Вот это один из главных минусов PHP. Из-за него получается особо зло***чий бажный гавнокод.
>Или следить за границами массивов и правильным доступом в память.
Да массивы в пхп клевые, офигенные я бы сказал — но не стоит так уж радоваться этой магии, в какойто момент аукнется.
>А через HTML и CSS закодировать интерфейс в большинстве случаев проще, чем на C++
Ну тут вы забыли добавить javascript. и ацкую мешанину технологий и много чего еще «прикольного». На с++ может и больше телодвижений, но если взять всякие либы то на сколько я помню не все так печально, хотя могу тут врать т.к. подзабыл.
Fesor
25.09.2015 21:18Простота в чем? написать hello world? Чем сложнее, например С?
Ну для C++ надо еще компилировать, собирать и прочее. в PHP можно просто запустить. Результат разработчик видит сильно быстрее и проще. Написал строчку и рефрешнул страницу в браузере. Ничего не надо перезапускать. Удобно. Так что в принципе я согласен, у PHP кривая обучения не то что бы очень линейная. Но как по мне это сомнительный довод. Больше боли с тем, что для PHP написанно масса книг, масса статей и прочего что нужно было бы сжечь во славу святой инквизиции. Вот с этим реально есть проблемы. Уже даже потихоньку зреют мысли что бы отфильтровать на stackoverflow все вредные ответы по PHP и сжечь их (или пометить как неблагонадежные).
потом остается только легкое отвращение
А со временем начинаешь получать от этого удовольствие? На самом деле 80% кода на всем заставляет грустить, и тут дело не в языке а в головах людей.jrip
25.09.2015 21:34> Написал строчку и рефрешнул страницу в браузере.
Что на счет знать что такое сервер и туда закачать?
>Ну для C++ надо еще компилировать, собирать и прочее
типа нажать f9?
>А со временем начинаешь получать от этого удовольствие?
А кстати да, когда получается сразу найти багу и разгрести гавно по быстрому чувствуешь себя невероятно :D
Fesor
25.09.2015 22:03Что на счет знать что такое сервер и туда закачать?
сейчас все довольно просто: PHP -S localhost:8000 и все, больше ничего не нужно. Скорее всего новоиспеченный PHP программист просто скопипастит эту строчку из статьи аля «давайте напишем hello world и потом простенькую соц сеть».
Ну для C++ надо еще компилировать, собирать и прочее
Уходим чуть дальше от hello world, скажем сортировку написать. Вы может уже забыли эти чувства когда вываливается segmentation fault а вы еще и понятия не имеете о том что это такое. В PHP все проще, интерпритируемые языки всегда были в этом плане проще.
Ну и да, с Qt ладно, хотя обычно ставят сразу вижлу какую. У меня вот вообще был Borland RAD Studio, который мне дико нравился своим дебагером.
В целом я думаю проблема в том, что люди не видят общей картины, зарываются в деталях и нюансах и не понимают зачем они что делают.
VolCh
26.09.2015 08:45Я ушел, потому что заинтересовался вебом в конце 90-х, на C/C++ экономически приемлемых вариантов делать сайты-визитки (современная терминология) не нашел, а у PHP оказался более понятный синтаксис и более высокое быстродействие (mod_php) чем у Perl(cgi).
Mendel
28.09.2015 23:46Ассемблер и культура пхп?
Может еще классический Бейсик вспомним, с нумерацией строк?)
Помню как недели две ходил матерился как узнал, что в пхп GOTO вернули.
Нет, конечно в начале я так-же матерился когда понял что его нет)
Нет вы конечно больше упоминали Си и Плюсы, но… Чистый Си в этом плане не намного лучше чем ассемблер, только другие болячки выбивать — всё-таки стилистика совсем другая. А плюсы… Плюсы получше конечно в этом плане, но опять таки — обучение бестпрактикс не берется из языка, а вот излишеств нахвататься можно изрядно.
Нет уж, лучше просто сразу учиться писать ПРАВИЛЬНО на том языке что тебе нужен.Fesor
28.09.2015 23:57как узнал, что в пхп GOTO вернули
ой да ладно, вернули goto, страх и ужас, детишки теперь буду нарушать поток выполнения как им вздумается. По факту писать конечные автоматы с goto довольно удобно, так что в принципе если вам приходится писать какой-нибудь парсер простенький или там клиент для собственного мудреного бинарного протокола, то в принципе будет весьма полезным это дело.
Чистый Си в этом плане не намного лучше чем ассемблер
Посмотрите исходники PHP. Теперь посмотрите исходники Postgresql. Найдите отличия. Си бывает очень разный. Как по мне знать Си на определенном уровне должен каждый уважающий себя программист. Должно быть хотя бы понимание того, как все работает на низком уровне. Хотя бы понимать что значит segmentation fault, постраничная организация памяти, да хотя бы что такое указатель и как вообще данные в памяти хранятся.
Плюсы получше конечно в этом плане
Весьма спорное утверждение.
лучше просто сразу учиться писать ПРАВИЛЬНО на том языке что тебе нужен.
Что если я скажу что ПРАВИЛЬНО не бывает?Mendel
29.09.2015 01:17Ну я не спорю, в урезанном виде как оно есть GOTO допустить можно. Начудить можно и похлеще чем с GOTO, чем «детишки» и пользуются. Я просто как пример привел.
Посмотрите исходники PHP. Теперь посмотрите исходники Postgresql. Найдите отличия. Си бывает очень разный.
Так в том то и дело, что может быть очень разный. А _культура_ о которой мы говорим, она не в языке а собственно в этих отличиях.
Как по мне знать Си на определенном уровне должен каждый уважающий себя программист. Должно быть хотя бы понимание того, как все работает на низком уровне. Хотя бы понимать что значит segmentation fault, постраничная организация памяти, да хотя бы что такое указатель и как вообще данные в памяти хранятся.
Тогда уж давайте ассемблер учить, для базовых знаний. «На каком-то уровне» это будет полезным.
Но тут опять таки, можно напороться на проблему. Помню как у меня один разработчик очень подвисал, когда я его с одной стороны ругал за то, что он полбайта ОЗУ лишних использовал (PIC10, давно это было), и в тот же день ругал что мол архив размером в 3Гб это мелочи и урезать его для экономии вовсе не надо… Думаю восьмибитки тут будут оптимальными. Пару десятков килобайт ОЗУ, столько же ПЗУ, пачку маскируемых прерываний, одно немаскируемое для разнообразия, пару мегагерц, и никаких «команд умножения». В общем что-то типа i8080 в простонародье больше известный как К580. Сегфолта здесь не будет, но накосячить можно так-же само, а вот о самой ошибке можно будет и в вики почитать, главное понимание сути…
Но если честно, то бред это. Многим такие знания будут бесполезны, а вот паттерны, алгоритмы и т.п., это нужно всем.
Помню в моем детстве был какой-то язык детский, мне кажется звался он «ЛОГО», похожий на язык управления плоттером, как если бы его писала компания 1С. Вот что-то подобное, с книжкой соответствующей, чтобы люди понимали что такое программа и алгоритм, потом блок-схемы, а дальше уже паттерны и прочие прочие…Fesor
29.09.2015 02:21+2Тогда уж давайте ассемблер учить, для базовых знаний.
Ассемблер это несколько перебор, как минимум потому что он слишком уж примитивен. Хотя знать что он есть такой, и что внутри виртуальной машины PHP выполняется нечто весьма похожее, думаю знать нужно. Ну и да, балуются же люди развлечения ради всякими брейнфаками, как по мне это лучше чем заставлять учить ассемблер при отсутствии необходимости в этом (у некоторых, в частности любителей писать на Си/Си++ такая необходимость порой случается).
Соль в том что бы понимать как работают те слои абстракций, до которых добираются руки разработчика. В частности в случае с PHP нужно понимать как работает интерпритатор. Но это уже не новичкам конечно.
а вот паттерны, алгоритмы и т.п., это нужно всем.
я могу сказать что и эти знания частенько оказываются для людей бесполезными, ибо зная все это у части из них отсутствует свое мышление, они часто не видят всей картины и не понимают зачем вообще все это нужно было изначально. Пытаются подогнать все под те самые паттерны и алгоритмы при этом упуская суть.
Знание паттернов не является культурой. Вот объяснить почему так а не иначе — это уже другое дело. Паттерны это следствие, а причин многие не понимают. А вообще, основная проблема в том, что подавляющая часть разработчиков думают что им платят за то, что бы они код писали, хотя из задача — эффективно решать задачи. И это не всегда значит «писать чистый код».VolCh
29.09.2015 14:07+1Использование паттернов, соблюдение кодинг-стайлов и прочих достаточно формализованных практик является своеобразным этикетом, вежливостью по отношению к тем, кто будет работать с твоим кодом после тебя. Как и в обычном мире надо понимать, что не всегда вежливость бывает уместна, и различать ситуации когда её применять, а когда не стоит, но лучше уж применять её неоправданно, сем не применять никогда.
marenkov
29.09.2015 01:03Я больше о том, чтобы не допускать к программированию на PHP (да и на всем остальном) тех, кто не прошел классическую (хардкордную) школу программирования.
Mendel
29.09.2015 01:18Я бы и до законотворчества без пятилетнего стажа сеньора на хайлоаде не допускал, но к сожалению это фантастика)
yakimoff
25.09.2015 18:37+4Думал увижу что-то интересное в статье, а оказалось что-то вроде мемуара… Автор, зачем?
Boeses_Genie
26.09.2015 00:18+1Для всех по-разному. Для вас эти вещи очевидны. Но мне хотелось новичкам простыми словами донести мысль — не хотите, чтобы над вами глумились? — вникайте глубже в контекст, учите основы, общайтесь, узнавайте новое. А насчёт мемуаров — живой опыт. который сработал, почему бы им не поделиться?
marenkov
29.09.2015 10:35Беда еще в том, что из-за ошибок новичков глумятся над всем сообществом PHP.
И при этом, с другой же стороны, обвиняют тех, кто делает код на PHP похожим на Java.
Прям в ступе не попадешь.Fesor
29.09.2015 10:58В PHP комьюнити наблюдается разделение. Скажем есть у меня знакомый которому приятнее велечать себя Symfony-девелопером, а не PHP девелопером. Как раз таки что бы выставить ментальну стену между ним и всеми теми кто пишет чушь на WP.
VolCh
29.09.2015 14:15Проблема обычно не в ошибках новичков, а принятых в тех или иных субсообществах (а то и у довольно опытных разработчиков лично) практиках.
marenkov
29.09.2015 15:30+1И вот как раз из-за простоты PHP в сообществе полно тех, кто просто не осилил чего-то посложнее и пишет код кое-как, лишь бы как-то работало (да и то не обязательно). От того, что кто-то проговнокодил 5 лет он не переходит из розряда новичков в мидла.
jrip
25.09.2015 18:49+13Опять сравнения с Java/C++ и т.д. Там гавнокода не меньше, просто он там обычно настолько непонятен, что все стыдливо думают «ух как круто и сложно тут написано».
Имхо правильнее на текущий момент сравнить с JavaScript. И вот по моему опыту — там все еще печальнее.
ShadowsMind
25.09.2015 18:54+6Статья коих миллион, где один из «просвятившихся» начинает говорить давно очевидные вещи, что надо уделять время повышению скилла, читать книги, смотреть другие языки/технологии. Не убедите Вы такими статьями тех кто cms'ки подверстывает и 10 for'ов друг в друга вкладывает посмотреть на мир разработки другими глазами. Разработчики они ведь бывают разные, кто-то 2 дня думает как ему массив перебрать, чтобы данные в html вывести, а кто-то машинным обучением занимается или пишет игровые движки etc. Тут даже не вопрос ума или профессианализма, тут все проще — кто какой выбор делает для себя. Если человека удовлетворяет говнокодить и при этом называть себя гордо программистах в хвастливых беседах — то тут проблема человека, он хоть 10 книг прочитает(мы то знаем, что не прочитает; ему некогда, он ведь кулл стори травит за кружкой пива) — он все равно останется тем же самым м**ок, который найдет способ зафакапить, только уже на более высших уровнях.
ShadowsMind
25.09.2015 19:01м**ок -> муд… ом* [fixed], ошибся и было как-то не понятно кого я имею ввиду )
Boeses_Genie
26.09.2015 00:22Ну, если сразу так думать, что никого не получится убедить, так так оно и будет. Попробовать же никому не помешает?
SDSWanderer
25.09.2015 19:59+1А о чем собственно статья? Вряд ли я что-то упустил (она не такая большая) или что-то не понял (пишу и на PHP в том числе), но за буквами статьи так и не разглядел. Мне кажется что культура в php — это стараться по минимуму использовать всякое уродство которого там хватает, и по максимуму новые возможности языка которые приближают возможности другим нормальным инструментам. Кстати говоря, мне в результате такой код начинает напоминать Java (из последнего что смотрел — composer и slim).
FSA
28.09.2015 12:45Вы не одиноки. Когда я решил попробовать сделать что-то в Java, то оказалось, что код особо не отличается. Только я так широко классы и объекты не использовал. Почитал книжку «Совершенный код», попробовал пройти 10 бесплатных уроков на javarush. Сейчас решил переделать свой проект. Посмотрел на старый код и ужаснулся. С ходу понять что там происходит просто невозможно. Переписал по новой. Сам код стал сверхкомпактным и легко читаемым.
Пишу в основном ради интереса, поэтому решил остаться на PHP. Уж очень привык к отсутствию жёсткой типизации. Код получается более компактным, т.к. не нужно заботиться самому о преобразованиях типов.
ncix
25.09.2015 20:24+11Дело в том, что порог вхождения в С++ ничуть не выше. Да-да. В чем-то даже PHP сложнее в начале — нужно как минимум развернуть Веб-сервер, немного знать разметку HTML, стили CSS. В плюсах вы можете поставить какую-нибудь ВижуалСтудию или Qt Creator и увидеть свой первый Hello World уже через 5 минут.
Посему, предлагаю заменить понятие «порог вхождения» на «порог востребованности». Чтобы продать свой труд как программиста С++ придется действительно постараться куда больше. А вот разработчик PHP, как было сказано, будет востребован гораздо скорее.
Я начинал в 6 классе на Лого. Потом были в школе Бэйсик и Паскаль, С в институте. Потом несколько лет настоящей работы на Delphi, еще столько же на С++. Год назад just-for-fun освоил Java+ADT чтобы попрактиковаться в Андроид. Сейчас вот пишу первый проект на PHP и знаете, это очень хороший инструмент. Некоторые вещи, вроде массивов, это просто песня.
А говнокод можно писать на любом языке. Просто не всякий поймет что это говнокод, если он написан на плюсах, например.
И записывать низкий порог вхождения и скорость разработки в минусы PHP — это жестокое и глупое заблуждение.Boeses_Genie
26.09.2015 00:26Дело в том, что на C++ надо компилировать код. Для новичка, который в программировании ничего не понимает, страшно видеть, как в консоли одна за другой лезут ошибки. Страшно ждать, пока программа соберется и сделает что-нибудь осмысленное. Или не очень осмысленное. Компилируемый язык выбивает новичка из зоны комфорта. Гораздо спокойнее мгновенно получить результат и увидеть его в браузере.
skey
26.09.2015 02:05Дело даже не в компиляции кода или консоли. А в практических задачах, на которых обучаться. Поставить задачу написать какой-нибудь простенький сайтик гораздо проще, при текущем то развитии интернета, чем придумать что бы такого сделать полезного на С, например.
Лично у меня, на втором курсе универа, именно так и получилось.ncix
26.09.2015 02:22Да, вы правы, на каком-нибудь языке для классического десктопа с GUI сейчас мало что интересного уже можно сделать, все давным давно есть. В игры и графику порог высокий. Мобильная разработка все еще сложна, хотя в этом направлении определенно есть прогресс. Остаются сайты на PHP и Arduino :)
ncix
26.09.2015 02:19+3Дело в том, что на C++ надо компилировать код.
от новичка это процесс скрыт за кнопкой > (run)
страшно видеть, как в консоли одна за другой лезут ошибки
Не страшнее чем просто белая страница в браузере или 404, безо всяких подсказок, что делать дальше.
MTonly
25.09.2015 22:55-1PHP бы DOM нормальный (в частности, с бережным отношением к пробельным символам при разборе HTML-кода с помощью
loadHTML()и корректным сохранением с помощьюsaveXML()кода элементов типаscript, требующих закрывающего тега) вместо кривого суррогата под названиемDOMDocument.
Andchir
25.09.2015 23:11PHP по популярности стоит рядом с JavaScript. Говнокода на JS написано ни чуть не меньше, порог вхождения тоже примерно одинаковый. Почему же такие статьи не пишут про JS? По-моему побудитель писать такие статьи — стадный инстинкт.
SerafimArts
25.09.2015 23:16+4Потому что JS модно. А говнокода на JS в разы побольше даже будет =)
P.S. Прошу не судить столь критично, просто после эпохи php 4 я не воспринимаю код на JS, выполненный без прототипов, нормального разбиения, ну или на ES6\7 (Babel), TS или Coffee как нормального качества. Может быть это просто стереотипы.
xobotyi
25.09.2015 23:33Полагаю, потому, что на JS довольно сложно наговнокодить в «самом начале», когда тебе просто надо по нажатию на кнопочку прятать один элемент и показывать другой. Потом приходят колбэки и асинхронный отстрел всех твоих асинхронных ног, внутри замыкания — так что твои асинхронные ноги оказываются и не твоими вовсе, вот на этот моменте больше половины и отсеивается.
Так что такого уж глобального говнокода, на мой взгляд, на JS меньше, в то время как на пыхе можнос испугунеожиданно и по инерции фреймворк свой умудриться написатькак сделал я когда-то.Fesor
26.09.2015 00:51+2Полагаю, потому, что на JS довольно сложно наговнокодить в «самом начале»
Да нет же, вот у тебя один селектор, вот у тебя колбэк, вот у тебя в колбэке еще один колбэк, вот у тебя уже кастыли пошли и подпорки…
9/10 библиотек написанных на js из тех что я видел за последние года два — лютый трэш. Но в целом есть позитивная тенденция, раньше их было 19/20Boeses_Genie
26.09.2015 07:20+1Мне кажется, лютый треш в JavaScript объясняется тем, что в него приходят люди с других языков, с классическим наследованием. Не видя привычных классов, начинают плести спагетти-код на пластилиновой архитектуре, при том не считая в принципе JavaScript чем-то серьёзным. А в нём надо думать по-другому, «неклассически».
Fesor
26.09.2015 12:53с классическим наследованием
Вот знаете, я крайне редко использую наследование и в PHP и в JS. Стараюсь обходиться композицией и декорацией.
Не видя привычных классов
Ну люди которые приходят из Python/Ruby тоже пописывают трэш по началу. А эти языки чуть ближе к Javascript. Ну и да, в ES2015 есть сахар для классов, который весьма приятен.
На самом деле я больше говорил о людях для которых JS был первым языком, игнорируя массу верстальщиков, только фронтэнд разработчики. Причем по моей статистике обычно сильнее оказываются люди пришедшие во фронтэнд из бэкэнда, сильных фронтэндеров среди них как-то по больше будет.
По сути до ES2015 с его модулями, с сахаром для Object.create и прочими плюшками реально легко было писать трэш. Сейчас все намного приятнее. А если в будущем введут async/await будет вообще сказка.
weirdan
26.09.2015 07:50+1Я видел чат с ощутимым количеством кода на JS, в котором не использовались локальные переменные. Вообще.
ankh1989
26.09.2015 11:47А так ли они нужны? Более того, необходимы ли функции? Должно хватить меток, нескольких глобальных переменных (штук 10 скажем) и один массив. Так ведь на ассемблере всё написано и никто не жалуется :)
Fesor
26.09.2015 12:55Так ведь на ассемблере всё написано и никто не жалуется :)
Попробуйте написать чатик с сокетами на ассемблере, я думаю вы начнете жаловаться довольно быстро.ncix
26.09.2015 21:04Вероятно, проще сначала написать на ассемблере компилятор С++, на плюсах интерпретатор JS, а на JS уже чатик.
VolCh
27.09.2015 12:16На ассемблере активно используются локальные переменные: при вызове подпрограммы значения используемых в ней регистров сохраняется в стек, регистры используются для внутренних нужд, а потом восстанавливаются из стека перед возвратом.
stychos
27.09.2015 17:45Я как-то всегда думал, что программист я хреновый. Во-первых, потому что самоучка, во-вторых, и потому, что всех этих умных книг перечисленных автором, я не читал. Но вот тут сейчас разбираюсь с PHP-кодом, в котором, в одном файле — 617 глобальных переменных, ну и куча прочих прелестей, объёмом в 16 тысяч строк, — и тут-то я понял, что уже не так уж и плох, оказывается. А самое интересное, что ЭТО ещё и достаточно массово используется в сфере всякой ip-телефонии, и покупается и продаётся за достаточно немалые деньги. Полюбоваться может любой желающий: sourceforge.net/projects/astguiclient/files
Fesor
27.09.2015 18:22project started 2003-10-06
ничего удивительного. Код то никто не переписывал особо с тех пор. Вы на wordpress посмотрите, там все примерно так же.
github.com/inktel/Vicidial — тем кому удобнее на гитхабе смотреть.stychos
27.09.2015 18:25Для меня после недели нереальной боли с этим кодом, возникает один вопрос? — как они умудряются ещё и новые версии выпускать? Как ЭТО вообще может существовать в ритейле? Да там неиссякаемый источник «прекрасного».
Fesor
27.09.2015 18:39Я не так давно ресерчил опенсурсные системы управления тест кейсами, из имеющихся есть только убогий и страшный testlink, написанный на php 10 лет назад. И насколько я знаю им много кто пользуется. А так как разработчикам обычно глубоко плевать на страдания братьев наших QA, то и суппортить это дело будут не многие. При том что коммиты там появляются регулярно, но переписать все нормально — тут нужно много человекочасов и тогда это будет уже другой продукт.
В вашем случае играет роль специфичность решения. Может много кто и юзает но в количестве разработчиков это незначительное количество.
WildZero
26.09.2015 11:21+1>когда тебе просто надо по нажатию на кнопочку прятать один элемент и показывать другой
и стоит попросить реализовать тоже самое без использования jquery и все, приплыли.
WildZero
26.09.2015 11:19Не так давно стал собеседовать на должность фронтенд-разработчика. И волосы стали дыбом от того, что многие просто приходят в ужас от словосочетания «native javascript», и по их мнению javascript = jquery.
ankh1989
26.09.2015 11:54-1Сейчас, кстати, тем же занимаюсь — провожу собеседования на должность js кодера. Несмотря на то, что зарплата начинается от 10*2**10 баксов в месяц, большинство выдаёт код вида «var a = [[]];» (здесь подразумевается двумерный массив), а на вопрос «ну и как сделать чтобы это всё таки работало?» после нескольких минут размышлений меняют на «var a = [][];» :)
Fesor
26.09.2015 13:50на должность js кодера
ну так может для js кодера это норм?
Я по началу спрашивал всякие штуки типа каррирование, или там просто какие-то интересные штуки со скоупами… Но как показала практика если человек вкурсе что такое прототип объекта это уже хорошо.
Prapor
26.09.2015 10:47О чем вы здесь вообще говорите, вот мы на перфокартах…
ЗЫ.
Бывший руководитель.
maxic
26.09.2015 13:17Культура программирования — это архитектура ПО в первую очередь, а код уже последующая составляющая
ncix
26.09.2015 21:10+1Архитектура — это стратегия. Есть еще тактика.
Вот вам простейшая задачка на тактику — есть одномерный массив строк, нужно удалить пустые. В вашем распоряжении получение элемента по индексу, проверка его на пустоту, удаление по индексу, количество элементов массива и цикл for. Можно на псевдоязыке.
На этой задачке у меня сыпались 7 из 10 соискателей.MaximChistov
27.09.2015 12:01Ну самый простой вариант — начать с конца?) тогда можно не париться, что на индекс удаленного элемента придёт непроверенный, который был за ним
VolCh
27.09.2015 12:23+1Культура и архитектура — ортогональные вещи. Архитектура может быть отличной, но при именовании сущностей типа aa123 и xz17 ты этого не успеешь понять за разумное время.
Dromok
27.09.2015 12:01-2Никогда не понимал загонов, когда постоянно какие-то книжки читают по программированию, загоняются по постоянному рефакторингу кода и т.д. Вам шашечки или ехать? Есть четкие стандарты кода, прописанные в документации к используемому фреймворку, например в той же symfony. Главное соблюдать стандарты, чтобы твой код можно было поддерживать и больше ничего не нужно. Книги читать конечно неплохо для повышения так сказать уровня осознанности, но на работе это отражается мало. Это моё мнение как php-программиста с 10-ти летним стажем. Безусловно потребуется изучать новые инструменты, но как правило это происходит не так часто (из собственного примера, долго писал на Yii1, и после выхода Yii2 потребовалось его основательно изучать, так как по сути это уже другой фреймворк).
VolCh
27.09.2015 12:30+2Что там те symfony стандарты? Как скобки расставлять, да пробелы вместо табов. Не зная таких понятий как, например, SOLID, код будет красивым локально, но поддерживать его глобально будет не реально, если, например, бизнес-логику запихивать в репозиторий или репозиторий использовать в модели. А без книг (или статей) ты даже не будешь знать, что такое репозиторий, для чего его нужно использовать, а для чего не нужно. Не, можно прийти к культуре по наитию, опыту и интуиции, но, как правило, книги эффективнее.
Dromok
27.09.2015 13:07Я не совсем верно выразился. Безусловно надо изучить так скажем best way и для этого возможно потребуется прочитать несколько книг, а может быть и достаточно изучить пару статей на эту тематику. Как правило этого достаточно, чтобы уже писать хорошо поддерживаемый код.
Тут видимо у нас непонимание исходных движимых человеком мотивов. Есть программисты, которым нравится программирование только ради программирования. Они постоянно изучают новые книги, пробуют другие языки программирования и паттерны. В этом нет ничего плохого, но время стоит дорого и в этом случае человек становится хорошим программистом, но только исполнителем, он не генерирует свои идеи стартапов, так как у него на это нет времени, он постоянно изучает новые книги по программированию. Хотя ему наверное больше ничего и не надо. Главное найти хорошую работу (в том же стартапе) и дальше оттачивать свое мастерство.
А есть программисты у которых первостепенное значение имеет идея проекта. Эдакие прожектеры. Они придумывают идею проекта, оттачивают ее, рисуют наброски интерфейса и т.д. И только потом начинают выбирать инструмент, который лучше подойдет для реализации идеи. Качество кода для них как правило на втором месте, главное это результат, главное, что проект будет реализован. Вот для меня это ближе и я не понимаю людей, которые постоянно изучают новые книги и постоянно занимаются рефакторингом, так как просто на остальное в этом случае не остается времени.
Вот Стив Возняк и Стив Джобс наглядные примеры первого и второго типа людей. Джобс генерировал идеи, а Возняк по сути их реализовывал.VolCh
27.09.2015 16:43+1Вторые — это скорее бизнесмены, которые могут программировать, чем программисты. Даже если они сейчас занимают должность программиста, то для них это априори временный этап, программирование для них лишь средство, которое можно спихнуть на «аутсорс» подчиненным или партнерам.
И по себе сужу — не генерирую идеи стартапов не потому что на это нет времени или других ресурсов, а потому что это мне не интересно. Но если уж берусь за задачу, то главное чтобы она была реализована согласно требованиям заказчика (будь человек со стороны, начальник отдела или партнер по бизнесу), а качественный код (прежде всего нормальная декомпозиция и именование сущностей) — это мой предпочитаемый стиль работы.
stychos
27.09.2015 17:54+2Ну в итоге Джобс крякнул, а Возняк живёт и радуется.
VolCh
27.09.2015 23:23Меньше ответственности, меньше рисков (как правило не только личных) взятых на себя — меньше рисков проблем с сердечно-сосудистой и нервной системами.
stychos
27.09.2015 23:33+1Это была шутка, но всё же, отсюда следует, как минимум, два метода:
первый — можно генерировать идеи, рисковать, брать технологии нахрапом, не особо вдумываясь в их детали, и в редком случае стать одним из немногих «выстреливших»;
и второй — учиться, учиться и ещё раз учиться, на чужих ошибках и на своих, и может, когда-нибудь, выпестовать потом и кровью одну из немногих «выстреливших» технологий, причём необязательно принесущую денег и популярности, но лишь возможно молчаливой благодарности последователей.
Тут уж каждому выбирать.VolCh
28.09.2015 00:13Методы чего? Методы — это способы достижения цели. У подавляющего большинства программистов, что я знаю лично, цели не состоят в достижении бизнес-целей собственников проектов, даже если они сами являются сособственниками. Подавляющее большинство в ситуации неопределенности успеха стартапа предпочтёт N денег без бонусов, чем 0.9*N + 1% от прибыли, не говоря о 0+50% от прибыли, если N хватает только на привычный образ жизни. Объяснение простое: программисты привыкли (чуть ли не больше чем кто бы то ни было) иметь дело с детерминированными системами.
stychos
28.09.2015 00:18+1Имел в виду методы рабочей жизнедеятельности. Грубо говоря, первый метод — это способ достижения цели, второй — поиск самой цели. Не знаю, конечно, как оно в основной массе, ибо я к сожалению ярый социопат, и с коллегами не общаюсь (в том числе и по причине их физического отсутствия как на моём месте работы, так и, пожалуй, в стране всего пару десятков толковых наберётся (речь не о России)), но сам работаю фактически за еду и идею на государство. И знаете — мне нравится. Несмотря на плачевность финансовой составляющей, мне нравится возможность получать от работы удовольствие и продолжать искать цели саморазвития, и как следствие, совершенствования того, над чем работаю.
VolCh
28.09.2015 00:37Жизнедеятельности кого или чего? Если о разработчике речь, то его, как и любого обычного человека, жизнедеятельность обычно первая его цель — получать, как минимум, еду и жильё, крайне желательно хотя бы на троих :)
В принципе я где-то вас понимаю, сам не вполне удовлетворён финансовой составляющей своей работы, организационной во многом, но ищу в ней возможности для саморазвития и совершенствования того, над чем работаю. Некоторые (а может и многие) могут счесть мою работу (а, вернее, бизнес нашей фирмы) аморальной, но я не работаю с людьми — я реализую бизнес-требования в коде, а код не может быть аморальным. И вот сейчас в отпуске я сижу и глубоко рефакторю код нашей основной системы. Не знаю, примут ли его в продакшен, но мне нравится решать технические проблемы обслуживания бизнес-процессов. И я их решаю.stychos
28.09.2015 01:20+1Да что Вы придрались-то ко мне :-) Я как бы тоже веду речь в отношении автора ветки в том ключе, что не всегда fast-way полезен и далеко не всем нужен.
Fesor
27.09.2015 13:06+2Главное соблюдать стандарты, чтобы твой код можно было поддерживать и больше ничего не нужно.
Собственно об этом и повествует статья. Для многих PHP разработчиков самое важное — кодинг стайл. Я работал как-то с чуваком который с криками «я не могу работать с этим говнокодом» поставил Php codesniffer (причем без автоматического фикса форматирования кода) и размазал очередную часть бизнес логики между сервисами и контроллерами. И там как раз таки был чувак с 10-ти летнем стажем. А писать тесты? Нееет, сам не буду, буду ждать пока кто-то за меня напишет и может тогда, под готовой инфраструктурой я уже этим буду заниматься, а пока буду ловить регрессии по 10 на дню.
Не поймите не правильно, есть разные проекты, и в мире PHP проектов где все это нафиг не надо — большинтсов. Это сайты визитки и прочая чушь вроде простеньких интернет-магазинов, там в принципе нет ничего такого что нужно было бы поддерживать годами. В итоге разработчики привыкают к определенным подходам в разработке и вообще не парятся (в прочем таких масса и среди Java разработчиков, у меня есть и на эту тему примеры).
Но вот у меня специфика такая, что проект можно сдать и через пол года он вернется. И делать его будут другие люди уже, или проект передадут отдельной команде на суппорт и т.д. Так же довольно часть проект, который по началу ничего из себя не представляет постепенно развивается и ошибки проектирования на ранних этапах сказываются огромным оверхэдом в разработке. А огромные оверхэды по времени на мелочи делают клиентов грустными и нередко оценка по внедрению новых фич вынуждает их отказываться от них, хотя фичи полезны и нужны.
Я тоже когда-то писал тупой CRUD, и начал книжки читать когда мы зафакапили один довольно сложный проект. И проблема там была как раз таки в том что люди не понимали что такое слабая связанность и количество возникающих регрессий делало разработку и тестирование адом. Прошло 3 года а я и люди с которыми я работал на этом проекте до сих пор его вспоминают.
scipe
Хорошая попытка, Расмус.
Fesor
Расмус сишник старой школы, вы видели его код на гитхабе?