Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 117
Хорошая попытка, Расмус.
Люка Веллинга и Лоры Томсон
О, помню помню, я по ней разбирался… А сейчас видеоуроки подавай…
Видеоуроки тоже неплохо. Люди воспринимают информацию лучшим образом разными каналами восприятия. По мне, так лучше читать книги и выполнять задания и интересные примеры, как-то структурированнее, обстоятельнее получается… Но хорошая живая лекция на видео тоже многое проясняет, живой человек лучше мотивирует, ему хочется верить.
Ключевое слово — лекция. Большинство же учатся по видеоурокам в духе «возьми и делай так», у людей не формируется мышление, они просто не хотят думать.
А мне одному кажется, что смотреть видео — это дольше, чем то же самое прочитать?
По своему субъективному опыту. Есть хорошие лекции на видео. Но обучение по ним должно быть активным. Если просто прослушать/просмотреть, и ничего не попробовать из рассказанного — на следующий день всё это вылетит из головы. Обязательно надо прорешать предложенные примеры, обдумать поставленные вопросы. И, самое, может быть, полезное, — опробовать знания на практике, чтобы оценить реальные плюсы от них. Что касается скорости обучения, думаю, тут всё индивидуально. Кто-то быстрее учится по видео, кто-то — по книгам.
Прикольно. Я как и автор вошел «в тему» после этих 2-х книг. Понятно, что всем все равно), но это как минимум значит что книги отличные!
Самая большая проблема PHP — простота освоения. Представьте что творилось бы с авиа полетами если бы лицензию пилота можно было бы получить так же просто как водительское удостоверение. И что было бы на дорогах, если бы ездить разрешили всем желающим без каких либо экзаменов. В идеале, прежде чем разрешать программировать на PHP, надо бы требовать пописать некоторое время на С/С++ (или подобном). Сам я прошел путь: машинные коды и ассемблер — pascal — c/c++ — perl — php — фреймворки на php, и я в ужасе от 80% кода на php.
Да, бывает ужасно, зато работает =)
надо бы требовать пописать некоторое время на С/С++ (или подобном)
ну да ну да, будет только хуже. Лучше познакомить их с .NET/Java тогда. Но тогда вопрос, зачем им PHP?
PHP всё же лаконичнее джавы, процентов на 25%-30%, да и вольности с типами порой позволяют сокращать алгоритмы (микроархитектуру) раз в 10.
P.S. К списку .NET/Java добавлю Haxe. Из той же оперы.
P.S. К списку .NET/Java добавлю Haxe. Из той же оперы.
Haxe… как-то видел но не тыкал.
нуу, потому мне больше нравится C#, но что-то как-то все сижу на PHP. Я к слову не так много джавистов знаю кто мог бы поддерживать беседу когда говорят о TDD, DDD и т.д. Среди .NET-чиков это как-то больше распространено, но может быть у меня выборка не репрезентативна.
По поводу микроархитектуры — в чем-то это так. Но типизации для массивов не хватает.
PHP всё же лаконичнее джавы
нуу, потому мне больше нравится C#, но что-то как-то все сижу на PHP. Я к слову не так много джавистов знаю кто мог бы поддерживать беседу когда говорят о TDD, DDD и т.д. Среди .NET-чиков это как-то больше распространено, но может быть у меня выборка не репрезентативна.
По поводу микроархитектуры — в чем-то это так. Но типизации для массивов не хватает.
Говорят TDD умер, правда ли это? =)
TDD это лишь идея. Идея о том что коду должны предшевствовать тесты, как самый простой способ формализации требований для программиста. Если нет красных тестов, нет смысла писать код. Далее пошло развитие ATDD, с приемочными тестами вместо юнит тестов, и далее уже BDD где в качестве приемочных тестов выступают поведенческие сценарии. Но цикл разработки остается все таким же — красный — зеленый — рефакторинг.
Проблема в другом. TDD это лишь одна из методик предлагаемых в экстримальном программировании (XP). Если люди не в состоянии разобраться с такими относительно простыми идеями как канбан, то куда уж им… Тут на днях вышла интересная дискуссия с одним человеком, который уверял меня что TDD это не жизнеспособная методология, потому что он на одном из проектов следуя TDD месяц писал чисто тесты. Как по мне это явное противоречие подходу. Аналогично один товаристч уверял меня что канбан это есть зло и анархия. При этом все те доводы которые он приводил основываясь на том, как канбан был введен на его проекте, никакого отношения к этому самому канбану не имели.
Ну и да, на собеседованиях часто слышал от ребят всякий трэш в духе XP это когда овертаймишь, деплоишься ночью и т.д (иначе зачем называть «экстримальным»?) и когда узнают что это является грубым нарушением идей XP уже начинают интересоваться что же это такое.
Проблема в другом. TDD это лишь одна из методик предлагаемых в экстримальном программировании (XP). Если люди не в состоянии разобраться с такими относительно простыми идеями как канбан, то куда уж им… Тут на днях вышла интересная дискуссия с одним человеком, который уверял меня что TDD это не жизнеспособная методология, потому что он на одном из проектов следуя TDD месяц писал чисто тесты. Как по мне это явное противоречие подходу. Аналогично один товаристч уверял меня что канбан это есть зло и анархия. При этом все те доводы которые он приводил основываясь на том, как канбан был введен на его проекте, никакого отношения к этому самому канбану не имели.
Ну и да, на собеседованиях часто слышал от ребят всякий трэш в духе XP это когда овертаймишь, деплоишься ночью и т.д (иначе зачем называть «экстримальным»?) и когда узнают что это является грубым нарушением идей XP уже начинают интересоваться что же это такое.
Если честно, даже не пробовал никогда ничего писать по TDD. Тесты всегда на потом оставляю, покрываю только самое критичное, стараюсь сразу писать хороший код. Наверное это не правильно, но проекты не серьёзные особо, 3-4 человека на одном проекте максимум.
Последнее время прямо безумно фанатею по контрактам (DbC), можно ли их рассматривать как некую альтернативу TDD, получая код такого же качества (ну или допустимого), как и при использовании сабжа? Я не рассматриваю сейчас доктриновские аннотации в качестве реализации, это ещё не совсем по-моему продакшн, а скорее как общую концепцию.
Последнее время прямо безумно фанатею по контрактам (DbC), можно ли их рассматривать как некую альтернативу TDD, получая код такого же качества (ну или допустимого), как и при использовании сабжа? Я не рассматриваю сейчас доктриновские аннотации в качестве реализации, это ещё не совсем по-моему продакшн, а скорее как общую концепцию.
Ну я совру если скажу что я так уж активно применяю TDD, хотелось бы но на моих проектах в этом нет смысла. Я активно использую ATDD на основе Behat и пытаюсь форсить идеи BDD, а TDD пользуюсь только когда пишу библиотечки, и это реально удобно. С другой стороны у меня уже был опыт с проектами где TDD спосло бы хоть немного, учитывая сложность бизнес логики.
Что до контрактов… не уверен. Идея контрактов состоит в том что бы быть дополнительной проверкой работоспособности бизнес логики на уровне одного метода. Это круто работает на особо критичных системах, например в финансовом секторе DbC любят и пользуют, но лично я не фанат. Отличие же от TDD в том что, последний является большим подспорьем в проектировании системы, нежели в верификации корректности ее работы. Если вам становится тяжко поддерживать тесты (например один класс требует замокать 5 других что бы написать простенький тест), то это скорее всего будет свидетельствовать о необходимости рефакторинга. С контрактами так не выйдет, там даже нет такого понятия как mock.
Что до контрактов… не уверен. Идея контрактов состоит в том что бы быть дополнительной проверкой работоспособности бизнес логики на уровне одного метода. Это круто работает на особо критичных системах, например в финансовом секторе DbC любят и пользуют, но лично я не фанат. Отличие же от TDD в том что, последний является большим подспорьем в проектировании системы, нежели в верификации корректности ее работы. Если вам становится тяжко поддерживать тесты (например один класс требует замокать 5 других что бы написать простенький тест), то это скорее всего будет свидетельствовать о необходимости рефакторинга. С контрактами так не выйдет, там даже нет такого понятия как mock.
Ну вот сказки не рассказывайте) Java все ещё самая выгодная, если речь об энтерпрайзе
Вы так говорите, как будто PHP хуже, чем .NET/Java.
Вы так говорите как буд-то бы это не так. Java лично мне не нравится, но вот C# нежный. PHP действительно эффективнее решает ряд задач, именно поэтому я на нем и пишу.
российский PHP-девелопер получает после кризиса в полтора-два раза больше, чем .NET/Java разработчик аналогичного уровня
Ну на счет российских реалий я не вкурсе, но в Беларуси они получают примерно одинаково. Вот только PHP разработчиков которые смогут потягаться с .NET/Java синьерами не так уж и много.
Ну и да, я не беру в расчет всяких вордпресс девелоперов, магенту девелоперов и т.д. К слову чуваки которые пишут магазинчики на магенту получают очень даже неплохо.
Просто на начальном этапе нужен опытный ведущий программист со знанием и применением хороших практик программирования.
Но к сожалению, в большинстве случаев бывает так: небольшая команда самоучек написала систему и решила, что на этом можно зарабатывать. Деньги потекли, программистов наняли, система разрослась, а рефакторить некогда было. Вот оттуда и выходят потом пхпшники без культуры программирования.
Но к сожалению, в большинстве случаев бывает так: небольшая команда самоучек написала систему и решила, что на этом можно зарабатывать. Деньги потекли, программистов наняли, система разрослась, а рефакторить некогда было. Вот оттуда и выходят потом пхпшники без культуры программирования.
А зачем вы ушли из c/с++ на PHP?
>Самая большая проблема PHP — простота освоения.
Простота в чем? написать hello world? Чем сложнее, например С?
Или вы про то, что язык в котором 100500 фреймворков, cms, подходов в программировании — просто освоить?
>И что было бы на дорогах, если бы ездить разрешили всем желающим без каких либо экзаменов.
Экзамены… ну да, прям таки у всех, какой вы наивный :)
>В идеале, прежде чем разрешать программировать на PHP, надо бы требовать пописать некоторое время на С/С++ (или подобном).
Это как бы чем поможет то? Как бы не стоит писать на PHP так, как писали бы на С…
> и я в ужасе от 80% кода на php.
Ужас возникает от непонимания, потом остается только легкое отвращение, которое не вызвает особых эмоций.
Ну типа страшно только первые лет пять :D
>Самая большая проблема PHP — простота освоения.
Простота в чем? написать hello world? Чем сложнее, например С?
Или вы про то, что язык в котором 100500 фреймворков, cms, подходов в программировании — просто освоить?
>И что было бы на дорогах, если бы ездить разрешили всем желающим без каких либо экзаменов.
Экзамены… ну да, прям таки у всех, какой вы наивный :)
>В идеале, прежде чем разрешать программировать на PHP, надо бы требовать пописать некоторое время на С/С++ (или подобном).
Это как бы чем поможет то? Как бы не стоит писать на PHP так, как писали бы на С…
> и я в ужасе от 80% кода на php.
Ужас возникает от непонимания, потом остается только легкое отвращение, которое не вызвает особых эмоций.
Ну типа страшно только первые лет пять :D
Не автор коммента, но попробую рассказать, зачем я ушел из C++ на PHP.
Просто не было работы на C++ в моем городе. Совсем. И в соседних городах тоже редко появлялись. Да и опыт обычно требовался. Зато на PHP вакансий было гораздо больше. После универа я знал только C++, писал на нем все лабы и курсовые. Еще знал ассемблер, но его можно не считать. Помаявшись полгода по небольшим халтуркам, решил изучить веб-программирование. Поначалу было непривычно, потом оказалось, что это очень удобно, когда строки обрабатываются на уровне языка. Когда не надо преобразовывать числа в строки и обратно вручную. Или следить за границами массивов и правильным доступом в память. А через HTML и CSS закодировать интерфейс в большинстве случаев проще, чем на C++ — попробуйте через device context нарисовать на форме поле для тетриса. Но знание C++ дало мне понимание, как программа работает внутри — например, что сравнение строк это не то же самое, что сравнение целочисленных переменных, и оно требует дополнительных ресурсов, или как работает передача по ссылке и чем она отличается от передачи по значению.
Hello world на обоих этих языках написать несложно, а вот вывести табличку с разнородными данными из БД и внизу еще строчку «Итого» на PHP будет попроще.
Просто не было работы на C++ в моем городе. Совсем. И в соседних городах тоже редко появлялись. Да и опыт обычно требовался. Зато на PHP вакансий было гораздо больше. После универа я знал только C++, писал на нем все лабы и курсовые. Еще знал ассемблер, но его можно не считать. Помаявшись полгода по небольшим халтуркам, решил изучить веб-программирование. Поначалу было непривычно, потом оказалось, что это очень удобно, когда строки обрабатываются на уровне языка. Когда не надо преобразовывать числа в строки и обратно вручную. Или следить за границами массивов и правильным доступом в память. А через HTML и CSS закодировать интерфейс в большинстве случаев проще, чем на C++ — попробуйте через device context нарисовать на форме поле для тетриса. Но знание C++ дало мне понимание, как программа работает внутри — например, что сравнение строк это не то же самое, что сравнение целочисленных переменных, и оно требует дополнительных ресурсов, или как работает передача по ссылке и чем она отличается от передачи по значению.
Hello world на обоих этих языках написать несложно, а вот вывести табличку с разнородными данными из БД и внизу еще строчку «Итого» на PHP будет попроще.
Я не спрашивал зачем ушли из С++, спрашивал зачем ушли в PHP, все-таки совсем другая сфера получается и другой подход ))
>Hello world на обоих этих языках написать несложно, а вот вывести табличку с
>разнородными данными из БД и внизу еще строчку «Итого» на PHP будет попроще.
Проще это чутка меньше буков?)
>Hello world на обоих этих языках написать несложно, а вот вывести табличку с
>разнородными данными из БД и внизу еще строчку «Итого» на PHP будет попроще.
Проще это чутка меньше буков?)
Главное не пробуйте применять эти знания для оптимизации. Зачастую всё можно наоборот замедлить, т.к. php изначально затачивался под общие правила. Например работа с бинрниками будет медленнее, чем с интами. Умножение на флоаты по скорости будет так же, как деление на инт. Передача по ссылкам везде и всюду может только усложнить код и сломать логику работы GC. И прочее…
Правило работает не со 100% вероятностью конечно же, но лучше писать красиво и чисто, нежели код побыстрее (потом всегда его можно ускорить).
Правило работает не со 100% вероятностью конечно же, но лучше писать красиво и чисто, нежели код побыстрее (потом всегда его можно ускорить).
Думать в php о скорости работы арифметических операций? о GC??
Да вы блин серьезно?
Да вы блин серьезно?
о GC??
в любом языке со сборщиком мусора следует помнить о GC, особенно учитывая определенные ограничения оного. Вспомните сюжет этой зимы, когда в composer ради оптимизации обработки графа зависимостей просто отключали GC, который быстро упирался в лимит в 10000 связанных элементов и на каждый чих жрал процессорное время.
Это конечно нужно тоьлко для <1% задач которые решают на PHP, но все же…
Есть мнение, что для этих 1% задач пхп лучше не использовать, если хочется чтобы все нормально работало. И явно не 1% а даже меньше и там хватает более серьезных проблем, о которых автор сообщения не указал, поэтому про GC было смешно)
React, Ratchet, Guzzle и прочие пакеты для асинхронной и\или постоянной работы с вами не согласны. ;)
Ок. В какой задаче реальной у вас появилась необходимость постоянной работы пхп и почему вы его там использовали?
У меня уже чуть меньше года на продакшене крутится чатик с плюшками на reactphp и все вроде бы не плохо. Знаю ребят у которых используется php-pm с целью уменьшения нагрузки на сервер (бойлерплейт фреймворков аля symfony жрет довольно много, php-pm невилирует время инициализации и на простых запросах может экономить до 50% времени обработки оных).
Так же у меня есть демоны для работы с APNS на PHP, есть обработчики очередей и т.д. Все поднимается супервизором и живет себе не тужит.
Ну конкретно мой пример не очень показателен. Просто разработчику который начинал проект захотелось попробовать реакт. Но в целом я не вижу в этом ничего дурного, особенно мне нравятся решения в духе php-pm.
Вообще PHP нормально живет в виде демона начиная с PHP 5.3, когда ввели в тот самый GC управление циклическими ссылками. А проблема composer-а весьма специфична. Такое можно получить только когда работаешь с очень большими графами на PHP, что весьма и весьма редкая задача. И тут стоит знать как работает GC, да и вообще это хорошо, знать как работает инструмент с которым ты работаешь, погрузиться хотя бы на один слой абстракции ниже.
Так же у меня есть демоны для работы с APNS на PHP, есть обработчики очередей и т.д. Все поднимается супервизором и живет себе не тужит.
почему вы его там использовали?
Ну конкретно мой пример не очень показателен. Просто разработчику который начинал проект захотелось попробовать реакт. Но в целом я не вижу в этом ничего дурного, особенно мне нравятся решения в духе php-pm.
Вообще PHP нормально живет в виде демона начиная с PHP 5.3, когда ввели в тот самый GC управление циклическими ссылками. А проблема composer-а весьма специфична. Такое можно получить только когда работаешь с очень большими графами на PHP, что весьма и весьма редкая задача. И тут стоит знать как работает GC, да и вообще это хорошо, знать как работает инструмент с которым ты работаешь, погрузиться хотя бы на один слой абстракции ниже.
Гиттер-бот для группы Laravel, который подсчитывает карму для пользователей. Карма инкрементится за "@user спасибо" и аналогичных. Сейчас он на js, но решили перейти на пых, т.к.
1) Единый стек для сайта (laravel.su\laravel.ru), плюс ларка.
2) Пых позволяет писать более качественный код — тайп-хинтинг, интерфейсы, абстрактные классы\методы и прочее.
3) Опыт и «почему бы и нет?»
0.5) Он вообще под php7 RC3 вертится =)
Исходники доступны в гитхабе, ссыль могу кинуть в личку или тут. Дабы не спамить. За ночь работы (с четверга на пятницу) он схавал один мегабайт памяти (чистый запускается с 14 метрами, на утро было ~15.5) при этом никаких тюнингов не было, более того, наоборот много оверхедов для удобства.
1) Единый стек для сайта (laravel.su\laravel.ru), плюс ларка.
2) Пых позволяет писать более качественный код — тайп-хинтинг, интерфейсы, абстрактные классы\методы и прочее.
3) Опыт и «почему бы и нет?»
0.5) Он вообще под php7 RC3 вертится =)
Исходники доступны в гитхабе, ссыль могу кинуть в личку или тут. Дабы не спамить. За ночь работы (с четверга на пятницу) он схавал один мегабайт памяти (чистый запускается с 14 метрами, на утро было ~15.5) при этом никаких тюнингов не было, более того, наоборот много оверхедов для удобства.
А на js сколько этот бот потреблял памяти?
На node.js потребление памяти обычно больше, но в целом 10 или 20 мегабайт это настолько мелочно. Нода крута когда речь идет о работе с вводом выводом, потому чатики и прочее на нем писать хорошо. Но иногда проще написать демон на PHP.
Говорят что, цитата: «если я всё правильно смотрю, то 66 мб сам процесс и 22 мб монитор forever».
На всякий случай: мб — это миллибит.
Спасибо, не знал. В любом случае из контекста понятно что имелось ввиду.
P.S. миллибит вообще не нагуглился, если не сложно — киньте ссыль в личку, хотя бы почитаю что это такое.
P.S. миллибит вообще не нагуглился, если не сложно — киньте ссыль в личку, хотя бы почитаю что это такое.
Если кому интересно — статитика работы бота на php7rc3 после одного дня работы:
[Client started at Thu, Oct 1, 2015 2:31 AM]
[24:19:29]: 10.49mb used
>Когда не надо преобразовывать числа в строки и обратно вручную.
Вот это один из главных минусов PHP. Из-за него получается особо зло***чий бажный гавнокод.
>Или следить за границами массивов и правильным доступом в память.
Да массивы в пхп клевые, офигенные я бы сказал — но не стоит так уж радоваться этой магии, в какойто момент аукнется.
>А через HTML и CSS закодировать интерфейс в большинстве случаев проще, чем на C++
Ну тут вы забыли добавить javascript. и ацкую мешанину технологий и много чего еще «прикольного». На с++ может и больше телодвижений, но если взять всякие либы то на сколько я помню не все так печально, хотя могу тут врать т.к. подзабыл.
Вот это один из главных минусов PHP. Из-за него получается особо зло***чий бажный гавнокод.
>Или следить за границами массивов и правильным доступом в память.
Да массивы в пхп клевые, офигенные я бы сказал — но не стоит так уж радоваться этой магии, в какойто момент аукнется.
>А через HTML и CSS закодировать интерфейс в большинстве случаев проще, чем на C++
Ну тут вы забыли добавить javascript. и ацкую мешанину технологий и много чего еще «прикольного». На с++ может и больше телодвижений, но если взять всякие либы то на сколько я помню не все так печально, хотя могу тут врать т.к. подзабыл.
Простота в чем? написать hello world? Чем сложнее, например С?
Ну для C++ надо еще компилировать, собирать и прочее. в PHP можно просто запустить. Результат разработчик видит сильно быстрее и проще. Написал строчку и рефрешнул страницу в браузере. Ничего не надо перезапускать. Удобно. Так что в принципе я согласен, у PHP кривая обучения не то что бы очень линейная. Но как по мне это сомнительный довод. Больше боли с тем, что для PHP написанно масса книг, масса статей и прочего что нужно было бы сжечь во славу святой инквизиции. Вот с этим реально есть проблемы. Уже даже потихоньку зреют мысли что бы отфильтровать на stackoverflow все вредные ответы по PHP и сжечь их (или пометить как неблагонадежные).
потом остается только легкое отвращение
А со временем начинаешь получать от этого удовольствие? На самом деле 80% кода на всем заставляет грустить, и тут дело не в языке а в головах людей.
> Написал строчку и рефрешнул страницу в браузере.
Что на счет знать что такое сервер и туда закачать?
>Ну для C++ надо еще компилировать, собирать и прочее
типа нажать f9?
>А со временем начинаешь получать от этого удовольствие?
А кстати да, когда получается сразу найти багу и разгрести гавно по быстрому чувствуешь себя невероятно :D
Что на счет знать что такое сервер и туда закачать?
>Ну для C++ надо еще компилировать, собирать и прочее
типа нажать f9?
>А со временем начинаешь получать от этого удовольствие?
А кстати да, когда получается сразу найти багу и разгрести гавно по быстрому чувствуешь себя невероятно :D
Что на счет знать что такое сервер и туда закачать?
сейчас все довольно просто: PHP -S localhost:8000 и все, больше ничего не нужно. Скорее всего новоиспеченный PHP программист просто скопипастит эту строчку из статьи аля «давайте напишем hello world и потом простенькую соц сеть».
Ну для C++ надо еще компилировать, собирать и прочее
Уходим чуть дальше от hello world, скажем сортировку написать. Вы может уже забыли эти чувства когда вываливается segmentation fault а вы еще и понятия не имеете о том что это такое. В PHP все проще, интерпритируемые языки всегда были в этом плане проще.
Ну и да, с Qt ладно, хотя обычно ставят сразу вижлу какую. У меня вот вообще был Borland RAD Studio, который мне дико нравился своим дебагером.
В целом я думаю проблема в том, что люди не видят общей картины, зарываются в деталях и нюансах и не понимают зачем они что делают.
Я ушел, потому что заинтересовался вебом в конце 90-х, на C/C++ экономически приемлемых вариантов делать сайты-визитки (современная терминология) не нашел, а у PHP оказался более понятный синтаксис и более высокое быстродействие (mod_php) чем у Perl(cgi).
Ассемблер и культура пхп?
Может еще классический Бейсик вспомним, с нумерацией строк?)
Помню как недели две ходил матерился как узнал, что в пхп GOTO вернули.
Нет, конечно в начале я так-же матерился когда понял что его нет)
Нет вы конечно больше упоминали Си и Плюсы, но… Чистый Си в этом плане не намного лучше чем ассемблер, только другие болячки выбивать — всё-таки стилистика совсем другая. А плюсы… Плюсы получше конечно в этом плане, но опять таки — обучение бестпрактикс не берется из языка, а вот излишеств нахвататься можно изрядно.
Нет уж, лучше просто сразу учиться писать ПРАВИЛЬНО на том языке что тебе нужен.
Может еще классический Бейсик вспомним, с нумерацией строк?)
Помню как недели две ходил матерился как узнал, что в пхп GOTO вернули.
Нет, конечно в начале я так-же матерился когда понял что его нет)
Нет вы конечно больше упоминали Си и Плюсы, но… Чистый Си в этом плане не намного лучше чем ассемблер, только другие болячки выбивать — всё-таки стилистика совсем другая. А плюсы… Плюсы получше конечно в этом плане, но опять таки — обучение бестпрактикс не берется из языка, а вот излишеств нахвататься можно изрядно.
Нет уж, лучше просто сразу учиться писать ПРАВИЛЬНО на том языке что тебе нужен.
как узнал, что в пхп GOTO вернули
ой да ладно, вернули goto, страх и ужас, детишки теперь буду нарушать поток выполнения как им вздумается. По факту писать конечные автоматы с goto довольно удобно, так что в принципе если вам приходится писать какой-нибудь парсер простенький или там клиент для собственного мудреного бинарного протокола, то в принципе будет весьма полезным это дело.
Чистый Си в этом плане не намного лучше чем ассемблер
Посмотрите исходники PHP. Теперь посмотрите исходники Postgresql. Найдите отличия. Си бывает очень разный. Как по мне знать Си на определенном уровне должен каждый уважающий себя программист. Должно быть хотя бы понимание того, как все работает на низком уровне. Хотя бы понимать что значит segmentation fault, постраничная организация памяти, да хотя бы что такое указатель и как вообще данные в памяти хранятся.
Плюсы получше конечно в этом плане
Весьма спорное утверждение.
лучше просто сразу учиться писать ПРАВИЛЬНО на том языке что тебе нужен.
Что если я скажу что ПРАВИЛЬНО не бывает?
Ну я не спорю, в урезанном виде как оно есть GOTO допустить можно. Начудить можно и похлеще чем с GOTO, чем «детишки» и пользуются. Я просто как пример привел.
Так в том то и дело, что может быть очень разный. А _культура_ о которой мы говорим, она не в языке а собственно в этих отличиях.
Тогда уж давайте ассемблер учить, для базовых знаний. «На каком-то уровне» это будет полезным.
Но тут опять таки, можно напороться на проблему. Помню как у меня один разработчик очень подвисал, когда я его с одной стороны ругал за то, что он полбайта ОЗУ лишних использовал (PIC10, давно это было), и в тот же день ругал что мол архив размером в 3Гб это мелочи и урезать его для экономии вовсе не надо… Думаю восьмибитки тут будут оптимальными. Пару десятков килобайт ОЗУ, столько же ПЗУ, пачку маскируемых прерываний, одно немаскируемое для разнообразия, пару мегагерц, и никаких «команд умножения». В общем что-то типа i8080 в простонародье больше известный как К580. Сегфолта здесь не будет, но накосячить можно так-же само, а вот о самой ошибке можно будет и в вики почитать, главное понимание сути…
Но если честно, то бред это. Многим такие знания будут бесполезны, а вот паттерны, алгоритмы и т.п., это нужно всем.
Помню в моем детстве был какой-то язык детский, мне кажется звался он «ЛОГО», похожий на язык управления плоттером, как если бы его писала компания 1С. Вот что-то подобное, с книжкой соответствующей, чтобы люди понимали что такое программа и алгоритм, потом блок-схемы, а дальше уже паттерны и прочие прочие…
Посмотрите исходники PHP. Теперь посмотрите исходники Postgresql. Найдите отличия. Си бывает очень разный.
Так в том то и дело, что может быть очень разный. А _культура_ о которой мы говорим, она не в языке а собственно в этих отличиях.
Как по мне знать Си на определенном уровне должен каждый уважающий себя программист. Должно быть хотя бы понимание того, как все работает на низком уровне. Хотя бы понимать что значит segmentation fault, постраничная организация памяти, да хотя бы что такое указатель и как вообще данные в памяти хранятся.
Тогда уж давайте ассемблер учить, для базовых знаний. «На каком-то уровне» это будет полезным.
Но тут опять таки, можно напороться на проблему. Помню как у меня один разработчик очень подвисал, когда я его с одной стороны ругал за то, что он полбайта ОЗУ лишних использовал (PIC10, давно это было), и в тот же день ругал что мол архив размером в 3Гб это мелочи и урезать его для экономии вовсе не надо… Думаю восьмибитки тут будут оптимальными. Пару десятков килобайт ОЗУ, столько же ПЗУ, пачку маскируемых прерываний, одно немаскируемое для разнообразия, пару мегагерц, и никаких «команд умножения». В общем что-то типа i8080 в простонародье больше известный как К580. Сегфолта здесь не будет, но накосячить можно так-же само, а вот о самой ошибке можно будет и в вики почитать, главное понимание сути…
Но если честно, то бред это. Многим такие знания будут бесполезны, а вот паттерны, алгоритмы и т.п., это нужно всем.
Помню в моем детстве был какой-то язык детский, мне кажется звался он «ЛОГО», похожий на язык управления плоттером, как если бы его писала компания 1С. Вот что-то подобное, с книжкой соответствующей, чтобы люди понимали что такое программа и алгоритм, потом блок-схемы, а дальше уже паттерны и прочие прочие…
Тогда уж давайте ассемблер учить, для базовых знаний.
Ассемблер это несколько перебор, как минимум потому что он слишком уж примитивен. Хотя знать что он есть такой, и что внутри виртуальной машины PHP выполняется нечто весьма похожее, думаю знать нужно. Ну и да, балуются же люди развлечения ради всякими брейнфаками, как по мне это лучше чем заставлять учить ассемблер при отсутствии необходимости в этом (у некоторых, в частности любителей писать на Си/Си++ такая необходимость порой случается).
Соль в том что бы понимать как работают те слои абстракций, до которых добираются руки разработчика. В частности в случае с PHP нужно понимать как работает интерпритатор. Но это уже не новичкам конечно.
а вот паттерны, алгоритмы и т.п., это нужно всем.
я могу сказать что и эти знания частенько оказываются для людей бесполезными, ибо зная все это у части из них отсутствует свое мышление, они часто не видят всей картины и не понимают зачем вообще все это нужно было изначально. Пытаются подогнать все под те самые паттерны и алгоритмы при этом упуская суть.
Знание паттернов не является культурой. Вот объяснить почему так а не иначе — это уже другое дело. Паттерны это следствие, а причин многие не понимают. А вообще, основная проблема в том, что подавляющая часть разработчиков думают что им платят за то, что бы они код писали, хотя из задача — эффективно решать задачи. И это не всегда значит «писать чистый код».
Использование паттернов, соблюдение кодинг-стайлов и прочих достаточно формализованных практик является своеобразным этикетом, вежливостью по отношению к тем, кто будет работать с твоим кодом после тебя. Как и в обычном мире надо понимать, что не всегда вежливость бывает уместна, и различать ситуации когда её применять, а когда не стоит, но лучше уж применять её неоправданно, сем не применять никогда.
Я больше о том, чтобы не допускать к программированию на PHP (да и на всем остальном) тех, кто не прошел классическую (хардкордную) школу программирования.
Думал увижу что-то интересное в статье, а оказалось что-то вроде мемуара… Автор, зачем?
Для всех по-разному. Для вас эти вещи очевидны. Но мне хотелось новичкам простыми словами донести мысль — не хотите, чтобы над вами глумились? — вникайте глубже в контекст, учите основы, общайтесь, узнавайте новое. А насчёт мемуаров — живой опыт. который сработал, почему бы им не поделиться?
Беда еще в том, что из-за ошибок новичков глумятся над всем сообществом PHP.
И при этом, с другой же стороны, обвиняют тех, кто делает код на PHP похожим на Java.
Прям в ступе не попадешь.
И при этом, с другой же стороны, обвиняют тех, кто делает код на PHP похожим на Java.
Прям в ступе не попадешь.
В PHP комьюнити наблюдается разделение. Скажем есть у меня знакомый которому приятнее велечать себя Symfony-девелопером, а не PHP девелопером. Как раз таки что бы выставить ментальну стену между ним и всеми теми кто пишет чушь на WP.
Проблема обычно не в ошибках новичков, а принятых в тех или иных субсообществах (а то и у довольно опытных разработчиков лично) практиках.
Опять сравнения с Java/C++ и т.д. Там гавнокода не меньше, просто он там обычно настолько непонятен, что все стыдливо думают «ух как круто и сложно тут написано».
Имхо правильнее на текущий момент сравнить с JavaScript. И вот по моему опыту — там все еще печальнее.
Имхо правильнее на текущий момент сравнить с JavaScript. И вот по моему опыту — там все еще печальнее.
Статья коих миллион, где один из «просвятившихся» начинает говорить давно очевидные вещи, что надо уделять время повышению скилла, читать книги, смотреть другие языки/технологии. Не убедите Вы такими статьями тех кто cms'ки подверстывает и 10 for'ов друг в друга вкладывает посмотреть на мир разработки другими глазами. Разработчики они ведь бывают разные, кто-то 2 дня думает как ему массив перебрать, чтобы данные в html вывести, а кто-то машинным обучением занимается или пишет игровые движки etc. Тут даже не вопрос ума или профессианализма, тут все проще — кто какой выбор делает для себя. Если человека удовлетворяет говнокодить и при этом называть себя гордо программистах в хвастливых беседах — то тут проблема человека, он хоть 10 книг прочитает(мы то знаем, что не прочитает; ему некогда, он ведь кулл стори травит за кружкой пива) — он все равно останется тем же самым м**ок, который найдет способ зафакапить, только уже на более высших уровнях.
А о чем собственно статья? Вряд ли я что-то упустил (она не такая большая) или что-то не понял (пишу и на PHP в том числе), но за буквами статьи так и не разглядел. Мне кажется что культура в php — это стараться по минимуму использовать всякое уродство которого там хватает, и по максимуму новые возможности языка которые приближают возможности другим нормальным инструментам. Кстати говоря, мне в результате такой код начинает напоминать Java (из последнего что смотрел — composer и slim).
Вы не одиноки. Когда я решил попробовать сделать что-то в Java, то оказалось, что код особо не отличается. Только я так широко классы и объекты не использовал. Почитал книжку «Совершенный код», попробовал пройти 10 бесплатных уроков на javarush. Сейчас решил переделать свой проект. Посмотрел на старый код и ужаснулся. С ходу понять что там происходит просто невозможно. Переписал по новой. Сам код стал сверхкомпактным и легко читаемым.
Пишу в основном ради интереса, поэтому решил остаться на PHP. Уж очень привык к отсутствию жёсткой типизации. Код получается более компактным, т.к. не нужно заботиться самому о преобразованиях типов.
Пишу в основном ради интереса, поэтому решил остаться на PHP. Уж очень привык к отсутствию жёсткой типизации. Код получается более компактным, т.к. не нужно заботиться самому о преобразованиях типов.
Дело в том, что порог вхождения в С++ ничуть не выше. Да-да. В чем-то даже PHP сложнее в начале — нужно как минимум развернуть Веб-сервер, немного знать разметку HTML, стили CSS. В плюсах вы можете поставить какую-нибудь ВижуалСтудию или Qt Creator и увидеть свой первый Hello World уже через 5 минут.
Посему, предлагаю заменить понятие «порог вхождения» на «порог востребованности». Чтобы продать свой труд как программиста С++ придется действительно постараться куда больше. А вот разработчик PHP, как было сказано, будет востребован гораздо скорее.
Я начинал в 6 классе на Лого. Потом были в школе Бэйсик и Паскаль, С в институте. Потом несколько лет настоящей работы на Delphi, еще столько же на С++. Год назад just-for-fun освоил Java+ADT чтобы попрактиковаться в Андроид. Сейчас вот пишу первый проект на PHP и знаете, это очень хороший инструмент. Некоторые вещи, вроде массивов, это просто песня.
А говнокод можно писать на любом языке. Просто не всякий поймет что это говнокод, если он написан на плюсах, например.
И записывать низкий порог вхождения и скорость разработки в минусы PHP — это жестокое и глупое заблуждение.
Посему, предлагаю заменить понятие «порог вхождения» на «порог востребованности». Чтобы продать свой труд как программиста С++ придется действительно постараться куда больше. А вот разработчик PHP, как было сказано, будет востребован гораздо скорее.
Я начинал в 6 классе на Лого. Потом были в школе Бэйсик и Паскаль, С в институте. Потом несколько лет настоящей работы на Delphi, еще столько же на С++. Год назад just-for-fun освоил Java+ADT чтобы попрактиковаться в Андроид. Сейчас вот пишу первый проект на PHP и знаете, это очень хороший инструмент. Некоторые вещи, вроде массивов, это просто песня.
А говнокод можно писать на любом языке. Просто не всякий поймет что это говнокод, если он написан на плюсах, например.
И записывать низкий порог вхождения и скорость разработки в минусы PHP — это жестокое и глупое заблуждение.
Дело в том, что на C++ надо компилировать код. Для новичка, который в программировании ничего не понимает, страшно видеть, как в консоли одна за другой лезут ошибки. Страшно ждать, пока программа соберется и сделает что-нибудь осмысленное. Или не очень осмысленное. Компилируемый язык выбивает новичка из зоны комфорта. Гораздо спокойнее мгновенно получить результат и увидеть его в браузере.
Дело даже не в компиляции кода или консоли. А в практических задачах, на которых обучаться. Поставить задачу написать какой-нибудь простенький сайтик гораздо проще, при текущем то развитии интернета, чем придумать что бы такого сделать полезного на С, например.
Лично у меня, на втором курсе универа, именно так и получилось.
Лично у меня, на втором курсе универа, именно так и получилось.
Дело в том, что на C++ надо компилировать код.от новичка это процесс скрыт за кнопкой > (run)
страшно видеть, как в консоли одна за другой лезут ошибкиНе страшнее чем просто белая страница в браузере или 404, безо всяких подсказок, что делать дальше.
PHP бы DOM нормальный (в частности, с бережным отношением к пробельным символам при разборе HTML-кода с помощью
loadHTML() и корректным сохранением с помощью saveXML() кода элементов типа script, требующих закрывающего тега) вместо кривого суррогата под названием DOMDocument.
PHP по популярности стоит рядом с JavaScript. Говнокода на JS написано ни чуть не меньше, порог вхождения тоже примерно одинаковый. Почему же такие статьи не пишут про JS? По-моему побудитель писать такие статьи — стадный инстинкт.
Потому что JS модно. А говнокода на JS в разы побольше даже будет =)
P.S. Прошу не судить столь критично, просто после эпохи php 4 я не воспринимаю код на JS, выполненный без прототипов, нормального разбиения, ну или на ES6\7 (Babel), TS или Coffee как нормального качества. Может быть это просто стереотипы.
P.S. Прошу не судить столь критично, просто после эпохи php 4 я не воспринимаю код на JS, выполненный без прототипов, нормального разбиения, ну или на ES6\7 (Babel), TS или Coffee как нормального качества. Может быть это просто стереотипы.
Полагаю, потому, что на JS довольно сложно наговнокодить в «самом начале», когда тебе просто надо по нажатию на кнопочку прятать один элемент и показывать другой. Потом приходят колбэки и асинхронный отстрел всех твоих асинхронных ног, внутри замыкания — так что твои асинхронные ноги оказываются и не твоими вовсе, вот на этот моменте больше половины и отсеивается.
Так что такого уж глобального говнокода, на мой взгляд, на JS меньше, в то время как на пыхе можнос испугу неожиданно и по инерции фреймворк свой умудриться написать как сделал я когда-то.
Так что такого уж глобального говнокода, на мой взгляд, на JS меньше, в то время как на пыхе можно
Полагаю, потому, что на JS довольно сложно наговнокодить в «самом начале»
Да нет же, вот у тебя один селектор, вот у тебя колбэк, вот у тебя в колбэке еще один колбэк, вот у тебя уже кастыли пошли и подпорки…
9/10 библиотек написанных на js из тех что я видел за последние года два — лютый трэш. Но в целом есть позитивная тенденция, раньше их было 19/20
Мне кажется, лютый треш в JavaScript объясняется тем, что в него приходят люди с других языков, с классическим наследованием. Не видя привычных классов, начинают плести спагетти-код на пластилиновой архитектуре, при том не считая в принципе JavaScript чем-то серьёзным. А в нём надо думать по-другому, «неклассически».
с классическим наследованием
Вот знаете, я крайне редко использую наследование и в PHP и в JS. Стараюсь обходиться композицией и декорацией.
Не видя привычных классов
Ну люди которые приходят из Python/Ruby тоже пописывают трэш по началу. А эти языки чуть ближе к Javascript. Ну и да, в ES2015 есть сахар для классов, который весьма приятен.
На самом деле я больше говорил о людях для которых JS был первым языком, игнорируя массу верстальщиков, только фронтэнд разработчики. Причем по моей статистике обычно сильнее оказываются люди пришедшие во фронтэнд из бэкэнда, сильных фронтэндеров среди них как-то по больше будет.
По сути до ES2015 с его модулями, с сахаром для Object.create и прочими плюшками реально легко было писать трэш. Сейчас все намного приятнее. А если в будущем введут async/await будет вообще сказка.
Я видел чат с ощутимым количеством кода на JS, в котором не использовались локальные переменные. Вообще.
А так ли они нужны? Более того, необходимы ли функции? Должно хватить меток, нескольких глобальных переменных (штук 10 скажем) и один массив. Так ведь на ассемблере всё написано и никто не жалуется :)
Так ведь на ассемблере всё написано и никто не жалуется :)
Попробуйте написать чатик с сокетами на ассемблере, я думаю вы начнете жаловаться довольно быстро.
На ассемблере активно используются локальные переменные: при вызове подпрограммы значения используемых в ней регистров сохраняется в стек, регистры используются для внутренних нужд, а потом восстанавливаются из стека перед возвратом.
project started 2003-10-06
ничего удивительного. Код то никто не переписывал особо с тех пор. Вы на wordpress посмотрите, там все примерно так же.
github.com/inktel/Vicidial — тем кому удобнее на гитхабе смотреть.
Я не так давно ресерчил опенсурсные системы управления тест кейсами, из имеющихся есть только убогий и страшный testlink, написанный на php 10 лет назад. И насколько я знаю им много кто пользуется. А так как разработчикам обычно глубоко плевать на страдания братьев наших QA, то и суппортить это дело будут не многие. При том что коммиты там появляются регулярно, но переписать все нормально — тут нужно много человекочасов и тогда это будет уже другой продукт.
В вашем случае играет роль специфичность решения. Может много кто и юзает но в количестве разработчиков это незначительное количество.
В вашем случае играет роль специфичность решения. Может много кто и юзает но в количестве разработчиков это незначительное количество.
>когда тебе просто надо по нажатию на кнопочку прятать один элемент и показывать другой
и стоит попросить реализовать тоже самое без использования jquery и все, приплыли.
и стоит попросить реализовать тоже самое без использования jquery и все, приплыли.
Не так давно стал собеседовать на должность фронтенд-разработчика. И волосы стали дыбом от того, что многие просто приходят в ужас от словосочетания «native javascript», и по их мнению javascript = jquery.
Сейчас, кстати, тем же занимаюсь — провожу собеседования на должность js кодера. Несмотря на то, что зарплата начинается от 10*2**10 баксов в месяц, большинство выдаёт код вида «var a = [[]];» (здесь подразумевается двумерный массив), а на вопрос «ну и как сделать чтобы это всё таки работало?» после нескольких минут размышлений меняют на «var a = [][];» :)
О чем вы здесь вообще говорите, вот мы на перфокартах…
ЗЫ.
Бывший руководитель.
ЗЫ.
Бывший руководитель.
Культура программирования — это архитектура ПО в первую очередь, а код уже последующая составляющая
Архитектура — это стратегия. Есть еще тактика.
Вот вам простейшая задачка на тактику — есть одномерный массив строк, нужно удалить пустые. В вашем распоряжении получение элемента по индексу, проверка его на пустоту, удаление по индексу, количество элементов массива и цикл for. Можно на псевдоязыке.
На этой задачке у меня сыпались 7 из 10 соискателей.
Вот вам простейшая задачка на тактику — есть одномерный массив строк, нужно удалить пустые. В вашем распоряжении получение элемента по индексу, проверка его на пустоту, удаление по индексу, количество элементов массива и цикл for. Можно на псевдоязыке.
На этой задачке у меня сыпались 7 из 10 соискателей.
Культура и архитектура — ортогональные вещи. Архитектура может быть отличной, но при именовании сущностей типа aa123 и xz17 ты этого не успеешь понять за разумное время.
Никогда не понимал загонов, когда постоянно какие-то книжки читают по программированию, загоняются по постоянному рефакторингу кода и т.д. Вам шашечки или ехать? Есть четкие стандарты кода, прописанные в документации к используемому фреймворку, например в той же symfony. Главное соблюдать стандарты, чтобы твой код можно было поддерживать и больше ничего не нужно. Книги читать конечно неплохо для повышения так сказать уровня осознанности, но на работе это отражается мало. Это моё мнение как php-программиста с 10-ти летним стажем. Безусловно потребуется изучать новые инструменты, но как правило это происходит не так часто (из собственного примера, долго писал на Yii1, и после выхода Yii2 потребовалось его основательно изучать, так как по сути это уже другой фреймворк).
Что там те symfony стандарты? Как скобки расставлять, да пробелы вместо табов. Не зная таких понятий как, например, SOLID, код будет красивым локально, но поддерживать его глобально будет не реально, если, например, бизнес-логику запихивать в репозиторий или репозиторий использовать в модели. А без книг (или статей) ты даже не будешь знать, что такое репозиторий, для чего его нужно использовать, а для чего не нужно. Не, можно прийти к культуре по наитию, опыту и интуиции, но, как правило, книги эффективнее.
Я не совсем верно выразился. Безусловно надо изучить так скажем best way и для этого возможно потребуется прочитать несколько книг, а может быть и достаточно изучить пару статей на эту тематику. Как правило этого достаточно, чтобы уже писать хорошо поддерживаемый код.
Тут видимо у нас непонимание исходных движимых человеком мотивов. Есть программисты, которым нравится программирование только ради программирования. Они постоянно изучают новые книги, пробуют другие языки программирования и паттерны. В этом нет ничего плохого, но время стоит дорого и в этом случае человек становится хорошим программистом, но только исполнителем, он не генерирует свои идеи стартапов, так как у него на это нет времени, он постоянно изучает новые книги по программированию. Хотя ему наверное больше ничего и не надо. Главное найти хорошую работу (в том же стартапе) и дальше оттачивать свое мастерство.
А есть программисты у которых первостепенное значение имеет идея проекта. Эдакие прожектеры. Они придумывают идею проекта, оттачивают ее, рисуют наброски интерфейса и т.д. И только потом начинают выбирать инструмент, который лучше подойдет для реализации идеи. Качество кода для них как правило на втором месте, главное это результат, главное, что проект будет реализован. Вот для меня это ближе и я не понимаю людей, которые постоянно изучают новые книги и постоянно занимаются рефакторингом, так как просто на остальное в этом случае не остается времени.
Вот Стив Возняк и Стив Джобс наглядные примеры первого и второго типа людей. Джобс генерировал идеи, а Возняк по сути их реализовывал.
Тут видимо у нас непонимание исходных движимых человеком мотивов. Есть программисты, которым нравится программирование только ради программирования. Они постоянно изучают новые книги, пробуют другие языки программирования и паттерны. В этом нет ничего плохого, но время стоит дорого и в этом случае человек становится хорошим программистом, но только исполнителем, он не генерирует свои идеи стартапов, так как у него на это нет времени, он постоянно изучает новые книги по программированию. Хотя ему наверное больше ничего и не надо. Главное найти хорошую работу (в том же стартапе) и дальше оттачивать свое мастерство.
А есть программисты у которых первостепенное значение имеет идея проекта. Эдакие прожектеры. Они придумывают идею проекта, оттачивают ее, рисуют наброски интерфейса и т.д. И только потом начинают выбирать инструмент, который лучше подойдет для реализации идеи. Качество кода для них как правило на втором месте, главное это результат, главное, что проект будет реализован. Вот для меня это ближе и я не понимаю людей, которые постоянно изучают новые книги и постоянно занимаются рефакторингом, так как просто на остальное в этом случае не остается времени.
Вот Стив Возняк и Стив Джобс наглядные примеры первого и второго типа людей. Джобс генерировал идеи, а Возняк по сути их реализовывал.
Вторые — это скорее бизнесмены, которые могут программировать, чем программисты. Даже если они сейчас занимают должность программиста, то для них это априори временный этап, программирование для них лишь средство, которое можно спихнуть на «аутсорс» подчиненным или партнерам.
И по себе сужу — не генерирую идеи стартапов не потому что на это нет времени или других ресурсов, а потому что это мне не интересно. Но если уж берусь за задачу, то главное чтобы она была реализована согласно требованиям заказчика (будь человек со стороны, начальник отдела или партнер по бизнесу), а качественный код (прежде всего нормальная декомпозиция и именование сущностей) — это мой предпочитаемый стиль работы.
И по себе сужу — не генерирую идеи стартапов не потому что на это нет времени или других ресурсов, а потому что это мне не интересно. Но если уж берусь за задачу, то главное чтобы она была реализована согласно требованиям заказчика (будь человек со стороны, начальник отдела или партнер по бизнесу), а качественный код (прежде всего нормальная декомпозиция и именование сущностей) — это мой предпочитаемый стиль работы.
Меньше ответственности, меньше рисков (как правило не только личных) взятых на себя — меньше рисков проблем с сердечно-сосудистой и нервной системами.
Методы чего? Методы — это способы достижения цели. У подавляющего большинства программистов, что я знаю лично, цели не состоят в достижении бизнес-целей собственников проектов, даже если они сами являются сособственниками. Подавляющее большинство в ситуации неопределенности успеха стартапа предпочтёт N денег без бонусов, чем 0.9*N + 1% от прибыли, не говоря о 0+50% от прибыли, если N хватает только на привычный образ жизни. Объяснение простое: программисты привыкли (чуть ли не больше чем кто бы то ни было) иметь дело с детерминированными системами.
Жизнедеятельности кого или чего? Если о разработчике речь, то его, как и любого обычного человека, жизнедеятельность обычно первая его цель — получать, как минимум, еду и жильё, крайне желательно хотя бы на троих :)
В принципе я где-то вас понимаю, сам не вполне удовлетворён финансовой составляющей своей работы, организационной во многом, но ищу в ней возможности для саморазвития и совершенствования того, над чем работаю. Некоторые (а может и многие) могут счесть мою работу (а, вернее, бизнес нашей фирмы) аморальной, но я не работаю с людьми — я реализую бизнес-требования в коде, а код не может быть аморальным. И вот сейчас в отпуске я сижу и глубоко рефакторю код нашей основной системы. Не знаю, примут ли его в продакшен, но мне нравится решать технические проблемы обслуживания бизнес-процессов. И я их решаю.
В принципе я где-то вас понимаю, сам не вполне удовлетворён финансовой составляющей своей работы, организационной во многом, но ищу в ней возможности для саморазвития и совершенствования того, над чем работаю. Некоторые (а может и многие) могут счесть мою работу (а, вернее, бизнес нашей фирмы) аморальной, но я не работаю с людьми — я реализую бизнес-требования в коде, а код не может быть аморальным. И вот сейчас в отпуске я сижу и глубоко рефакторю код нашей основной системы. Не знаю, примут ли его в продакшен, но мне нравится решать технические проблемы обслуживания бизнес-процессов. И я их решаю.
Главное соблюдать стандарты, чтобы твой код можно было поддерживать и больше ничего не нужно.
Собственно об этом и повествует статья. Для многих PHP разработчиков самое важное — кодинг стайл. Я работал как-то с чуваком который с криками «я не могу работать с этим говнокодом» поставил Php codesniffer (причем без автоматического фикса форматирования кода) и размазал очередную часть бизнес логики между сервисами и контроллерами. И там как раз таки был чувак с 10-ти летнем стажем. А писать тесты? Нееет, сам не буду, буду ждать пока кто-то за меня напишет и может тогда, под готовой инфраструктурой я уже этим буду заниматься, а пока буду ловить регрессии по 10 на дню.
Не поймите не правильно, есть разные проекты, и в мире PHP проектов где все это нафиг не надо — большинтсов. Это сайты визитки и прочая чушь вроде простеньких интернет-магазинов, там в принципе нет ничего такого что нужно было бы поддерживать годами. В итоге разработчики привыкают к определенным подходам в разработке и вообще не парятся (в прочем таких масса и среди Java разработчиков, у меня есть и на эту тему примеры).
Но вот у меня специфика такая, что проект можно сдать и через пол года он вернется. И делать его будут другие люди уже, или проект передадут отдельной команде на суппорт и т.д. Так же довольно часть проект, который по началу ничего из себя не представляет постепенно развивается и ошибки проектирования на ранних этапах сказываются огромным оверхэдом в разработке. А огромные оверхэды по времени на мелочи делают клиентов грустными и нередко оценка по внедрению новых фич вынуждает их отказываться от них, хотя фичи полезны и нужны.
Я тоже когда-то писал тупой CRUD, и начал книжки читать когда мы зафакапили один довольно сложный проект. И проблема там была как раз таки в том что люди не понимали что такое слабая связанность и количество возникающих регрессий делало разработку и тестирование адом. Прошло 3 года а я и люди с которыми я работал на этом проекте до сих пор его вспоминают.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP: культура программирования