Игорь, тебя обидели в Мэйле что ли?
Странно видеть такие серьезные нападки через многие месяцы после ухода. Тем более, что прекрасно осознаешь, что большая часть аудитории что Яндекса, что русского Гугла, что Мэйла чихать хотела и на подобные статьи, и на отношение группки гиков с Хабра к какой-либо компании.
Че огород-то городить на пустом месте? Ну и картинку зачем-то привел. Смысл-то ее в чем? Показать, что среди миллионов аудитории Мэйла нашлись придурки? Ну так придурков везде хватает. Даже на таком проекте, как Хабр, нашлись свои дятлы с «черным властелином». Думаю, их и на ВауЯндексе хватает.
Зацепило, что на детище Футурико пишут про Мэйл?
Ну пишут, да. А чем это хуже размышлений программистов-неумех о том, чего они добились, прочитав впопыхах страницу мануала? Или переводов с западных статей о западных компаниях, которые нафиг никому не упали, кроме автора перевода?
А то, что навыки применить не удалось, чего обижаться?
Компании разные бывают — какая-то набивает шишки на инициативах, какая-то выбирает консервативный путь. Одним людям этот путь подходит, другим нет. Тебе не подошел, ты не реализовался в Мэйле. Кому-то подошел. Кому-то удалось защитить свои инициативы перед менеджерами и реализовать что-то интересное в рамках своих проектов, кому-то нет. Зато сейчас и ты, и они на своем месте. И вроде все довольны, нет? Ну так смысл критиковать путь других? Не понимаю.
Пишу на perl и php, и даже под настроения на С. Прекрасно знаю Oracle и MySQL.
Куча лет опыта. В том числе, последние годы — в "трех кнопках".
Могу спроектировать систему абсолютно любой сложности.
15 килобаксов и я ваш.
Какой ужас с позиции архитектора аналогичного проекта читать ваши комменты.
Проблема подобных проектов совсем не в скорости php или perl
Ну какой выигрыш даст фреймфорк, если чистого кода на php/perl в каждой процедуре не более 50 строк?... И то - сплошные выводы курсоров из БД.
Скорость разработки? Да бросьте...
Оценить сколько строк кода у меня получится я не могу. Как вы этим оперируете не знаю.
Опыт не пропьешь.
Не факт что завтра этот сайт не будет расти, не добавятся статьи, галереи, форумы и т.п.
Ну и что? И какая связь между объектами Статья и Галерея, чтобы один из этих модулей был наследуем от другого?
Вообще говоря про ООП я предполагаю что собеседник занимается крупными и сложными системами
Ну я занимаюсь. Без ООП. И в Яндексе занимаются.
А в итоге проект МойКруг пишут несколько десятков человек.
Зато там ООП.
Количество строк кода никак не влияет на целесообразность использования ООП.
Да ладно? Вот, например, надо написать стандартную системку публикации новостей на сайте. Это можно сделать в сто строк кода (да-да, не больше — из расчёта 20 строк кода на функцию. А их всего четыре — добавление, удаление, изменение, вывод).
Вы, правда, считаете, что для этого нужно использовать ООП? Неужели будете ради такого писать целый класс myNews с методами →list(), →add() и так далее? А так же вписывать в текущую иерархию классов итп? Если да, то я сильно удивлен и подозреваю, что Вы не понимаете, зачем вообще люди придумали ООП.
А 100 строк кода или 10-20 тысяч — разницы нет. Для большинства отдельновзятых проектов.
какое отношение хиты имеют к размерам проектов?
Исходя из названной цифры хитов несложно догадаться где я примерно работаю и какого плана проекты могу с большой долей точности оценить в объёме кода. Только и всего.
Не знаю с чем вы имели дело... С совсем крошечными проектиками?
Ага. С совсем крошечными. С такими, которые не дают больше 5–30 миллионов хитов в день. Ну, правда, там, конечно, не только и не столько php, но всё же.
Покажите мне хотя бы 2–3 рунетовских проекта, где, как Вам кажется, больше 20 тысяч строк? Не обязательно Ваш.
20000 строк не ОО пхп кода держать в голове?
Не 20 тысяч строк кода, а проект, в котором 20 тысяч строк. Эт немного разные вещи, не?
20к не больше сотни?
Да, представьте себе.
20k в вебе на php или perl — это достаточно большой проект. Либо проект с сильно избыточным кодом. Возможно, из-за использования ООП ;)
Это шутка юмора, да?
Проекты до 20 тысяч строк легко держатся в голове.
Хоть Тутубалина спросите.
Проектов свыше 20 тысяч строк в Рунете не больше сотни.
Вы какие из них имеете ввиду?
Каждый скрипт для каждой отдельной страницы - изолирован, ничего не знает о других страницах
И так может быть
Вот выдержка с сайта CakePHP
И что, это истина в последней инстанции? Или всего лишь еще одно мнение?
Reduces development costs and helps developers write less code
Я тоже самое могу сказать о коде тех проектов, которыми занимаюсь.
Без использования ООП.
Вопрос не в том, какая парадигма лучше.
Любой веб-проект можно написать и с ООП, и без оного.
И разница между объемами кода в этих случаях может отличаться как в одну, так и в другую сторону.
Вопрос в том зачем это обязательно нужно на собеседовании и нужно ли этот подход принудительно насаждать. «Мы проповедуем объекто-ориентированный стиль программирования и прочие лузеры нам не нужны»? Ну так кто еще лузер — человек с таким подходом или человек, понимающий где ООП нужно, а где без него можно и нужно вполне обойтись.
Какие паттерны, какая организация кода?
Десяток SQL запросов теперь иначе как с помощью классов не выполнить и вместе не собрать? Много лично Вы видели проектов, где число строк больше 10-20 тысяч? Зачем в таком небольшом объеме лишние сложности с ООП? Keep It Simple Stupid ;)
Какие паттерны, какая организация кода?
Десяток SQL запросов теперь иначе как с помощью классов не выполнить и вместе не собрать? Много лично Вы видели проектов, где число строк больше 10-20 тысяч? Зачем в таком небольшом объеме лишние сложности с ООП? Keep It Simple Stupid ;)
А то совсем страшно за страну станет :)
Странно видеть такие серьезные нападки через многие месяцы после ухода. Тем более, что прекрасно осознаешь, что большая часть аудитории что Яндекса, что русского Гугла, что Мэйла чихать хотела и на подобные статьи, и на отношение группки гиков с Хабра к какой-либо компании.
Че огород-то городить на пустом месте? Ну и картинку зачем-то привел. Смысл-то ее в чем? Показать, что среди миллионов аудитории Мэйла нашлись придурки? Ну так придурков везде хватает. Даже на таком проекте, как Хабр, нашлись свои дятлы с «черным властелином». Думаю, их и на ВауЯндексе хватает.
Зацепило, что на детище Футурико пишут про Мэйл?
Ну пишут, да. А чем это хуже размышлений программистов-неумех о том, чего они добились, прочитав впопыхах страницу мануала? Или переводов с западных статей о западных компаниях, которые нафиг никому не упали, кроме автора перевода?
А то, что навыки применить не удалось, чего обижаться?
Компании разные бывают — какая-то набивает шишки на инициативах, какая-то выбирает консервативный путь. Одним людям этот путь подходит, другим нет. Тебе не подошел, ты не реализовался в Мэйле. Кому-то подошел. Кому-то удалось защитить свои инициативы перед менеджерами и реализовать что-то интересное в рамках своих проектов, кому-то нет. Зато сейчас и ты, и они на своем месте. И вроде все довольны, нет? Ну так смысл критиковать путь других? Не понимаю.
Куча лет опыта. В том числе, последние годы — в "трех кнопках".
Могу спроектировать систему абсолютно любой сложности.
15 килобаксов и я ваш.
%-)
Проблема подобных проектов совсем не в скорости php или perl
Ну какой выигрыш даст фреймфорк, если чистого кода на php/perl в каждой процедуре не более 50 строк?... И то - сплошные выводы курсоров из БД.
Скорость разработки? Да бросьте...
Опыт не пропьешь.
Не факт что завтра этот сайт не будет расти, не добавятся статьи, галереи, форумы и т.п.
Ну и что? И какая связь между объектами Статья и Галерея, чтобы один из этих модулей был наследуем от другого?
Вообще говоря про ООП я предполагаю что собеседник занимается крупными и сложными системами
Ну я занимаюсь. Без ООП. И в Яндексе занимаются.
А в итоге проект МойКруг пишут несколько десятков человек.
Зато там ООП.
Да ладно? Вот, например, надо написать стандартную системку публикации новостей на сайте. Это можно сделать в сто строк кода (да-да, не больше — из расчёта 20 строк кода на функцию. А их всего четыре — добавление, удаление, изменение, вывод).
Вы, правда, считаете, что для этого нужно использовать ООП? Неужели будете ради такого писать целый класс myNews с методами →list(), →add() и так далее? А так же вписывать в текущую иерархию классов итп? Если да, то я сильно удивлен и подозреваю, что Вы не понимаете, зачем вообще люди придумали ООП.
А 100 строк кода или 10-20 тысяч — разницы нет. Для большинства отдельновзятых проектов.
Я чуть младше Вас.
Тем более, открою секрет — поисковики не пишутся на php. ;)
Исходя из названной цифры хитов несложно догадаться где я примерно работаю и какого плана проекты могу с большой долей точности оценить в объёме кода. Только и всего.
Ага. С совсем крошечными. С такими, которые не дают больше 5–30 миллионов хитов в день. Ну, правда, там, конечно, не только и не столько php, но всё же.
Покажите мне хотя бы 2–3 рунетовских проекта, где, как Вам кажется, больше 20 тысяч строк? Не обязательно Ваш.
Не 20 тысяч строк кода, а проект, в котором 20 тысяч строк. Эт немного разные вещи, не?
20к не больше сотни?
Да, представьте себе.
20k в вебе на php или perl — это достаточно большой проект. Либо проект с сильно избыточным кодом. Возможно, из-за использования ООП ;)
Проекты до 20 тысяч строк легко держатся в голове.
Хоть Тутубалина спросите.
Проектов свыше 20 тысяч строк в Рунете не больше сотни.
Вы какие из них имеете ввиду?
может быть
Каждый скрипт для каждой отдельной страницы - изолирован, ничего не знает о других страницах
И так может быть
Вот выдержка с сайта CakePHP
И что, это истина в последней инстанции? Или всего лишь еще одно мнение?
Reduces development costs and helps developers write less code
Я тоже самое могу сказать о коде тех проектов, которыми занимаюсь.
Без использования ООП.
Вопрос не в том, какая парадигма лучше.
Любой веб-проект можно написать и с ООП, и без оного.
И разница между объемами кода в этих случаях может отличаться как в одну, так и в другую сторону.
Вопрос в том зачем это обязательно нужно на собеседовании и нужно ли этот подход принудительно насаждать. «Мы проповедуем объекто-ориентированный стиль программирования и прочие лузеры нам не нужны»? Ну так кто еще лузер — человек с таким подходом или человек, понимающий где ООП нужно, а где без него можно и нужно вполне обойтись.
Кстати, вот вам ссылочка на интересную дискуссию:
http://gornal.livejournal.com/55794.html
Десяток SQL запросов теперь иначе как с помощью классов не выполнить и вместе не собрать? Много лично Вы видели проектов, где число строк больше 10-20 тысяч? Зачем в таком небольшом объеме лишние сложности с ООП? Keep It Simple Stupid ;)
Десяток SQL запросов теперь иначе как с помощью классов не выполнить и вместе не собрать? Много лично Вы видели проектов, где число строк больше 10-20 тысяч? Зачем в таком небольшом объеме лишние сложности с ООП? Keep It Simple Stupid ;)