Comments 32
Блин, обидно, что такие хорошие статьи до главки так туго добираются. Нужно поправлять…
это трындец, первая симфони была фреймворком ради конфигов а вторая походу войдет в историю
смотрелось бы лучше с подсвеченным кодом, а то читать не все удобно =)
Да, согласен. К сожалению на хабре нет инструментов для подсветки кода, либо я их не нашел.
Постараюсь в дальнейшем предусмотреть это и предварительно отформатировать текст где-нибудь в другом месте.
Постараюсь в дальнейшем предусмотреть это и предварительно отформатировать текст где-нибудь в другом месте.
попробуйте поискать в поисковиках «хабраредактор» или «инструмент для подсветки кода»
от себя могу посоветовать:
www.bankinform.ru/habraeditor/
www.softcoder.ru/blogeditor/
там конечно не все идеально, но авторам за них респект =)
от себя могу посоветовать:
www.bankinform.ru/habraeditor/
www.softcoder.ru/blogeditor/
там конечно не все идеально, но авторам за них респект =)
UFO just landed and posted this here
UFO just landed and posted this here
с таким php фреймворком лучше мигрировать на python+django, слишком уж далеко повернули от простоты и скорости разработки. это уже разработка ради «красивой» архитектуры. в студенческом говнокоде гибкость добавить и то легче, но чаще она даже не нужна.
Мне тоже очень нравится Python вообще и Django в частности.
Однако я не соглашусь, Symfony не поворачивал от простоты и скорости разработки, они просто повернули в сторону гибкости, а точнее продолжили путь. Многие ругают full-stack фреймворки за недостаточную гибкость, за невозможность отключить тяжелую артиллерию для простых проектов, за невозможность заменить какую-либо часть фреймворка своей любимой и супер удобной библиотекой, Symfony дает возможность это сделать.
Можно начать простой проект отключив все ненужное и если проект решит разрастить до более крупных размеров, то это не вызовет проблем, так как он сделан все на том же привычном фреймворке и надо будет лишь подключить необходимые части дающие требуемое расширение функционала.
А в плане удобства, простоты и скорости разработки я не увидел ухудшений.
Судя по всему вы используете в разработке Django? Что ж это хороший выбор, Django — отличный фреймворк.
Однако я не соглашусь, Symfony не поворачивал от простоты и скорости разработки, они просто повернули в сторону гибкости, а точнее продолжили путь. Многие ругают full-stack фреймворки за недостаточную гибкость, за невозможность отключить тяжелую артиллерию для простых проектов, за невозможность заменить какую-либо часть фреймворка своей любимой и супер удобной библиотекой, Symfony дает возможность это сделать.
Можно начать простой проект отключив все ненужное и если проект решит разрастить до более крупных размеров, то это не вызовет проблем, так как он сделан все на том же привычном фреймворке и надо будет лишь подключить необходимые части дающие требуемое расширение функционала.
А в плане удобства, простоты и скорости разработки я не увидел ухудшений.
Судя по всему вы используете в разработке Django? Что ж это хороший выбор, Django — отличный фреймворк.
Ну это вы загнули. Скорее в симфони отказались от централизации и от костылей над РНР. И так они плавно шли от Rails on PHP до Symfony 2. Впрочем опять таки, удобство и существование единой конецпции программирования будет зависеть от входящих в поддержку бандлов. Но главное их теперь легко добавлять и отключать.
тоесть вы предлагаете сразу создавать кучу избыточного функционала, а затем дать возможность его отключать.
таким образом теряется то, что отличало php от java, asp.net. у нас всегда был простой функционал, а гибкость обеспечивалась наличием точек pre и post обработки, которых при веб разработке не так уж много: в фронт контроллере, в модели и во вьюхе значительно реже.
в условиях толстого фреймворка php проиграет python, в котором гибкость заложено в реализации ООП.
Сейчас делаю диплом девочке, заодно выложу исходники лёгкого фреймворка, там осталось немного ядро дописать и сделать пару примеров. И такая элементарщина даёт гибкости не меньше, но при этом в разы легче.
У меня уже давно есть монстр с ORM и программированием на конфигах, это удобно, но я понимаю, что можно упростить, но оставить почти тот же функционал и гибкость.
Путь Symfony 2 тупиковый, он тяжёл для начинающих, а для профессионалов проще написать под проект.
Универсальность — это отсутствие избыточности в первую очередь и точки входа во вторую. А здесь вмето точе входа делают точки выхода.
таким образом теряется то, что отличало php от java, asp.net. у нас всегда был простой функционал, а гибкость обеспечивалась наличием точек pre и post обработки, которых при веб разработке не так уж много: в фронт контроллере, в модели и во вьюхе значительно реже.
в условиях толстого фреймворка php проиграет python, в котором гибкость заложено в реализации ООП.
Сейчас делаю диплом девочке, заодно выложу исходники лёгкого фреймворка, там осталось немного ядро дописать и сделать пару примеров. И такая элементарщина даёт гибкости не меньше, но при этом в разы легче.
У меня уже давно есть монстр с ORM и программированием на конфигах, это удобно, но я понимаю, что можно упростить, но оставить почти тот же функционал и гибкость.
Путь Symfony 2 тупиковый, он тяжёл для начинающих, а для профессионалов проще написать под проект.
Универсальность — это отсутствие избыточности в первую очередь и точки входа во вторую. А здесь вмето точе входа делают точки выхода.
> тоесть вы предлагаете сразу создавать кучу избыточного функционала, а затем дать возможность его отключать.
Конечно же нет. Symfony — full-stack фреймворк, который предоставляет весь необходимый функционал для разработки веб приложений охватывая все его аспекты. Но в некоторых случаях некоторая функциональность не нужна, либо есть желание заменить какую либо функциональность тем к чему больше привык, что больше подходит и т.д. Symfony предоставляет эти возможности.
> Путь Symfony 2 тупиковый, он тяжёл для начинающих, а для профессионалов проще написать под проект.
Время рассудит. Если этот путь тупиковый, то проект Symfony как фреймворка загнется, если нет, то он будет набирать обороты и кол-во пользователей будет расти. Пока судя по всему Symfony не подает признаков вымирания.
> У меня уже давно есть монстр с ORM и программированием на конфигах, это удобно, но я понимаю, что можно упростить, но оставить почти тот же функционал и гибкость.
Это замечательно. Возможно когда Symfony наконец дойдет до тупика вы поделитесь своим творением с общественностью и все будут в выигрыше.
Конечно же нет. Symfony — full-stack фреймворк, который предоставляет весь необходимый функционал для разработки веб приложений охватывая все его аспекты. Но в некоторых случаях некоторая функциональность не нужна, либо есть желание заменить какую либо функциональность тем к чему больше привык, что больше подходит и т.д. Symfony предоставляет эти возможности.
> Путь Symfony 2 тупиковый, он тяжёл для начинающих, а для профессионалов проще написать под проект.
Время рассудит. Если этот путь тупиковый, то проект Symfony как фреймворка загнется, если нет, то он будет набирать обороты и кол-во пользователей будет расти. Пока судя по всему Symfony не подает признаков вымирания.
> У меня уже давно есть монстр с ORM и программированием на конфигах, это удобно, но я понимаю, что можно упростить, но оставить почти тот же функционал и гибкость.
Это замечательно. Возможно когда Symfony наконец дойдет до тупика вы поделитесь своим творением с общественностью и все будут в выигрыше.
повторюсь, основная идея
>>в условиях толстого фреймворка php проиграет python
все фичи делают его сложность равной java, .net, но при этом нет стольких лет разработки и проверки временем.
ИМХО, Symfony для тех кто дорос до потолка php, но не решается перейти на другие языки, которые лучше подходят под его задачи.
я — php-шник, но вижу, когда вместо смены архитектуры следует сменить язык. в русской версии мануала была хорошая фраза о том, что php не предназначен для расшифровки генов.
>>в условиях толстого фреймворка php проиграет python
все фичи делают его сложность равной java, .net, но при этом нет стольких лет разработки и проверки временем.
ИМХО, Symfony для тех кто дорос до потолка php, но не решается перейти на другие языки, которые лучше подходят под его задачи.
я — php-шник, но вижу, когда вместо смены архитектуры следует сменить язык. в русской версии мануала была хорошая фраза о том, что php не предназначен для расшифровки генов.
UFO just landed and posted this here
Да что ж вы все про сложность Symfony то рассказываете. Не сложный он вовсе, не пугайте людей. У нас разработчики с ним осваиваются очень быстро и остаются довольны.
> ИМХО, Symfony для тех кто дорос до потолка php
Ну что вы, я видел как с ним лихо осваиваются весьма еще середнячки и при этом остаются довольны и расширяют собственные познания и учатся на хороших примерах.
>>в условиях толстого фреймворка php проиграет python
Знаете, я разрабатываю как на PHP + Symfony, так и на Python + Django и мне лично Python нравится больше, чем PHP, но это мое сугубо личное мнение и я не хотел бы здесь разводить холивары по поводу сравнения кто кому и где проиграет. Symfony — отличный фрейворк, очень хороший и гибкий инструмент и во-многих случаях оценивая по многим критериям я выбираю для проектов PHP + Symfony.
> ИМХО, Symfony для тех кто дорос до потолка php
Ну что вы, я видел как с ним лихо осваиваются весьма еще середнячки и при этом остаются довольны и расширяют собственные познания и учатся на хороших примерах.
>>в условиях толстого фреймворка php проиграет python
Знаете, я разрабатываю как на PHP + Symfony, так и на Python + Django и мне лично Python нравится больше, чем PHP, но это мое сугубо личное мнение и я не хотел бы здесь разводить холивары по поводу сравнения кто кому и где проиграет. Symfony — отличный фрейворк, очень хороший и гибкий инструмент и во-многих случаях оценивая по многим критериям я выбираю для проектов PHP + Symfony.
UFO just landed and posted this here
очень давно работаю с доктриной и точно на ней не стал бы делать проект даже с 6-нулями. Последний кусок счастья был с игнорированием части where для поджойненой таблицы. в свежей версии всё работает. тоже капитальное переписывание symfony, показывает неустойчивость позиций автора. вы доверите деньги годами отточенным компонентом java или свежепереписанному Symfony. К сожалению, из-за отсутствия стабильного флагмана приходится всё писать самим, на агиле, надеясь что пронесёт или тесты выручат.
Гибкость это возможность добавления функционала или его изменения, когда от простого к сложному. Когда от сложного к простому, то это уже избыточность. Вот данный компонент точно избыточный.
Гибкость это возможность добавления функционала или его изменения, когда от простого к сложному. Когда от сложного к простому, то это уже избыточность. Вот данный компонент точно избыточный.
Сопоставляя
> очень давно работаю с доктриной
и
> и точно на ней не стал бы делать проект даже с 6-нулями
Ну вот правда в этой ситуации я могу вам только посочувствовать. Очень не хорошо, когда работа, которую делаешь настолько неприятна.
> тоже капитальное переписывание symfony, показывает неустойчивость позиций автора
Вы просто не в курсе, но делаете выводы, жаль. Это не совсем просто капитальное переписывание, в данном случае это развитие и развитие в сторону большей гибкости, развитие с учетом прошлого опыта и пожеланий, развитие с учетом серьезных изменений в языке программирования на котором написан фреймворк.
> доверите деньги годами отточенным компонентом java или свежепереписанному Symfony
Symfony доверяют такие гиганты как Yahoo, Dailymotion и др.
> К сожалению, из-за отсутствия стабильного флагмана приходится всё писать самим, на агиле, надеясь что пронесёт или тесты выручат.
Мы уже долгое время разрабатываем в том числе и на Symfony и не надеемся на «пронесёт» и при этом спим спокойно :)
А вот этап «приходится всё писать самим» к счастью остался далеко в прошлом и знаете это позволяет разрабатывать быстрее и стабильнее и не тратить время и силы на изобретение не нужных велосипедов.
> Гибкость это возможность добавления функционала или его изменения, когда от простого к сложному.
По-моему Symfony вполне соответствует этому определению.
> Вот данный компонент точно избыточный.
Какой конкретно?
> очень давно работаю с доктриной
и
> и точно на ней не стал бы делать проект даже с 6-нулями
Ну вот правда в этой ситуации я могу вам только посочувствовать. Очень не хорошо, когда работа, которую делаешь настолько неприятна.
> тоже капитальное переписывание symfony, показывает неустойчивость позиций автора
Вы просто не в курсе, но делаете выводы, жаль. Это не совсем просто капитальное переписывание, в данном случае это развитие и развитие в сторону большей гибкости, развитие с учетом прошлого опыта и пожеланий, развитие с учетом серьезных изменений в языке программирования на котором написан фреймворк.
> доверите деньги годами отточенным компонентом java или свежепереписанному Symfony
Symfony доверяют такие гиганты как Yahoo, Dailymotion и др.
> К сожалению, из-за отсутствия стабильного флагмана приходится всё писать самим, на агиле, надеясь что пронесёт или тесты выручат.
Мы уже долгое время разрабатываем в том числе и на Symfony и не надеемся на «пронесёт» и при этом спим спокойно :)
А вот этап «приходится всё писать самим» к счастью остался далеко в прошлом и знаете это позволяет разрабатывать быстрее и стабильнее и не тратить время и силы на изобретение не нужных велосипедов.
> Гибкость это возможность добавления функционала или его изменения, когда от простого к сложному.
По-моему Symfony вполне соответствует этому определению.
> Вот данный компонент точно избыточный.
Какой конкретно?
UFO just landed and posted this here
мы живём в ужасное время, когда качеством считается не отсутствие багов, а скорость их устранения, причём чужими руками. о каких нулях вы говорите, если баги всплывают???
Мне безумно нравится архитектура доктрины, я сам популяризирую её, даже на прошлом месте работы прикупили домен для страницы фреймворка в by. Но я не могу на неё расчитывать в критически важных проектах, там нужно проще и надёжнее, чтобы знать как действует каждый критически важный кусок.
Что это за архитектура, которую нужно переписывать из-за новинок языка, просто автор пробует новые подходы, я так делаю, когда берусь за дешёвую сайт-визитку. Или как сейчас ставлю эксперимент на дипломном проекте.
>>ереобуться на ходу из сапог в тапочки — это не гибкость, выходит? и пофиг, >>что сапоги прочнее и теплее, а тапочки нужно менять каждые 100км?
а вот это прекрасное сравнение, если мне нужно пробежать стометровку, я одену красовки, а не прочные и удобные сапоги. Я не вижу сферу применения Symfony, для визиток она тяжеловата, для серьёзных проектов много багов, это гугл или яшка могут ставить эксперименты на людях, а у меня нет таких денег.
Я думал мы находимся в посте о RequestHandler, странно что оба мои собеседника забыли сабж, поэтому повторусь и о том, что мне нравится архитектура симфони и доктрины, но я считаю, что она слишком избыточна ради универсальности.
Мне безумно нравится архитектура доктрины, я сам популяризирую её, даже на прошлом месте работы прикупили домен для страницы фреймворка в by. Но я не могу на неё расчитывать в критически важных проектах, там нужно проще и надёжнее, чтобы знать как действует каждый критически важный кусок.
Что это за архитектура, которую нужно переписывать из-за новинок языка, просто автор пробует новые подходы, я так делаю, когда берусь за дешёвую сайт-визитку. Или как сейчас ставлю эксперимент на дипломном проекте.
>>ереобуться на ходу из сапог в тапочки — это не гибкость, выходит? и пофиг, >>что сапоги прочнее и теплее, а тапочки нужно менять каждые 100км?
а вот это прекрасное сравнение, если мне нужно пробежать стометровку, я одену красовки, а не прочные и удобные сапоги. Я не вижу сферу применения Symfony, для визиток она тяжеловата, для серьёзных проектов много багов, это гугл или яшка могут ставить эксперименты на людях, а у меня нет таких денег.
Я думал мы находимся в посте о RequestHandler, странно что оба мои собеседника забыли сабж, поэтому повторусь и о том, что мне нравится архитектура симфони и доктрины, но я считаю, что она слишком избыточна ради универсальности.
> о каких нулях вы говорите, если баги всплывают?
Вы смеетесь что-ли? Нет, правда, может покажете инструмент или продукт в которых не всплывают баги? Правда, просто интересно очень.
Конечно же отсутствие багов — это просто супер как хорошо, но способность их быстро устранять — это очень ценно!
> Что это за архитектура, которую нужно переписывать из-за новинок языка
Вас удивляет, что многие проекты переписывали для перехода с php4 на php5? Вас удивляет когда разработчики используют новые возможности появившиеся в языке программирования? Вас удивляет, что проект развивается? Вы реально считаете, что лучший показатель, когда проект не изменяется и это говорит об идеальной архитектуре выбранной изначально?
Наверное у нас очень разный опыт.
> Я не вижу сферу применения Symfony, для визиток она тяжеловата
Знаете как оно иногда бывает, вы начинаете проект, простенький, он очень небольшой. Но потом у заказчика появляются новые идеи и что самое главное деньги на их реализацию и проект вырастает уже до средних размеров. Так вот Symfony дает возможность начать простенький проект отключив ненужный функционал, но и при его развитии у вас не возникнет проблем, так как в основе лежит гибкость предоставляемая фреймворком, которая позволит подключить недостающий функционал, либо заменить какие-то его части.
> для серьёзных проектов много багов
Я использую Symfony еще с версии 0.6, вот когда можно было говорить о приводящем в замешательство кол-ве багов, но сейчас уже исходя из опыта я могу сказать — Symfony зрелый, стабильный и очень достойный инструмент в том числе и для серьезных проектов.
> мы находимся в посте о RequestHandler
Поверьте, лично я помню :) и как раз на примере RequestHandler можно рассмотреть как можно использовать Symfony, если не для сайтов-визиток, так как обычно для этого есть готовые типовые решения, которые кстати могут быть также разработаны на Symfony, ну а хотя бы для очень простеньких проектов и при этом Symfony не будет как вы сказали «тяжеловата».
> но я считаю, что она слишком избыточна ради универсальности
Что ж возможно для вас архитектура Symfony избыточна, каждый имеет право на собственное мнение.
Было бы интересно узнать о вашем подходе к разработке об инструментах, которые вы используете и которые я так понимаю:
1) не менее гибки
2) менее избыточны
3) проще
4) позволяют писать меньше кода
5) более надежны для серьезных проектов
Уверен многие будут вам благодарны если вы напишете пост с рассказом о используемых вами инструментах.
В любом случае спасибо за ваше мнение.
Вы смеетесь что-ли? Нет, правда, может покажете инструмент или продукт в которых не всплывают баги? Правда, просто интересно очень.
Конечно же отсутствие багов — это просто супер как хорошо, но способность их быстро устранять — это очень ценно!
> Что это за архитектура, которую нужно переписывать из-за новинок языка
Вас удивляет, что многие проекты переписывали для перехода с php4 на php5? Вас удивляет когда разработчики используют новые возможности появившиеся в языке программирования? Вас удивляет, что проект развивается? Вы реально считаете, что лучший показатель, когда проект не изменяется и это говорит об идеальной архитектуре выбранной изначально?
Наверное у нас очень разный опыт.
> Я не вижу сферу применения Symfony, для визиток она тяжеловата
Знаете как оно иногда бывает, вы начинаете проект, простенький, он очень небольшой. Но потом у заказчика появляются новые идеи и что самое главное деньги на их реализацию и проект вырастает уже до средних размеров. Так вот Symfony дает возможность начать простенький проект отключив ненужный функционал, но и при его развитии у вас не возникнет проблем, так как в основе лежит гибкость предоставляемая фреймворком, которая позволит подключить недостающий функционал, либо заменить какие-то его части.
> для серьёзных проектов много багов
Я использую Symfony еще с версии 0.6, вот когда можно было говорить о приводящем в замешательство кол-ве багов, но сейчас уже исходя из опыта я могу сказать — Symfony зрелый, стабильный и очень достойный инструмент в том числе и для серьезных проектов.
> мы находимся в посте о RequestHandler
Поверьте, лично я помню :) и как раз на примере RequestHandler можно рассмотреть как можно использовать Symfony, если не для сайтов-визиток, так как обычно для этого есть готовые типовые решения, которые кстати могут быть также разработаны на Symfony, ну а хотя бы для очень простеньких проектов и при этом Symfony не будет как вы сказали «тяжеловата».
> но я считаю, что она слишком избыточна ради универсальности
Что ж возможно для вас архитектура Symfony избыточна, каждый имеет право на собственное мнение.
Было бы интересно узнать о вашем подходе к разработке об инструментах, которые вы используете и которые я так понимаю:
1) не менее гибки
2) менее избыточны
3) проще
4) позволяют писать меньше кода
5) более надежны для серьезных проектов
Уверен многие будут вам благодарны если вы напишете пост с рассказом о используемых вами инструментах.
В любом случае спасибо за ваше мнение.
тьфу-тьфу-тьфу, но начиная с трёх месяцев опыта, я столкнулся с проектами, где нельзя допускать ни одного логического бага, т.к. это ОЧЕНЬ дорого. ладно, вёрстка где-то поехала, но когда становится видимой закрытая категория, это может иметь страшные последствия.
я работал с seagull, которому при переходе на php5 ничего не пришлось переписывать.
отвечу на вопросы:
1. почти любой говнокод-спагетти является не менее гибким.
2. любой говнокод не страдает избыточностью.
3. любой говнокод.
4. Symfony и корпоративные наработки
5. Здесь всё плохо, но лучше свой код, чем сторонний.
Ты, как и мы. программируешь на агиле, надеясь, что твой коллега, фреймворк и т.д. не подведут, это СТРАШНО. А авторы на нас тренируют свои идеи, хороший код, это такой. который не меняет архитектуры со временем, даже если она не была совсем удачной. Важно стабильное качество, а не красота архитектуры.
я работал с seagull, которому при переходе на php5 ничего не пришлось переписывать.
отвечу на вопросы:
1. почти любой говнокод-спагетти является не менее гибким.
2. любой говнокод не страдает избыточностью.
3. любой говнокод.
4. Symfony и корпоративные наработки
5. Здесь всё плохо, но лучше свой код, чем сторонний.
Ты, как и мы. программируешь на агиле, надеясь, что твой коллега, фреймворк и т.д. не подведут, это СТРАШНО. А авторы на нас тренируют свои идеи, хороший код, это такой. который не меняет архитектуры со временем, даже если она не была совсем удачной. Важно стабильное качество, а не красота архитектуры.
UFO just landed and posted this here
> я столкнулся с проектами, где нельзя допускать ни одного логического бага
У нас ни на одном проекте нельзя допускать логических багов, любой баг нам может обойтись в копеечку (это очень большие копеечки), так как мы даем гарантию. Тесты, несколько уровней перед появлением в production, дают нам гарантию спокойствия, но даже в этой ситуации мы очень высоко ценим возможность быстро исправлять баги.
Если стала видимой закрытая категория, то скорее всего функционал попал в production не проверенным, тут фреймворк не причем, если честно.
> отвечу на вопросы:
Спасибо, но это были не вопросы, это были критерии, которым с ваших слов соответствуют ваши инструменты, о них то я (думаю и многие другие) и хотел бы услышать и более чем уверен что «любой говнокод-спагетти» вы не используете, так зачем приводить его в пример.
Тем более, что с утверждением что «любой говнокод-спагетти» является столь же гибким — я категорически не согласен, но спор на эту тему мне совсем не интересен.
> Ты, как и мы. программируешь на агиле
Нет, я программирую на PHP и Python в основном :) (это шутка).
> надеясь, что твой коллега, фреймворк и т.д. не подведут, это СТРАШНО
Это совсем не страшно. Про это можно написать целый пост, но думаю до меня это делали сотни людей.
Во многом фреймворк сильно выручает, когда несколько проектов разрабатывают на одном проверенном фреймворке я могу быть уверен, что программисту не придется неделю разбираться в проекте, я знаю, что подключая к работе менее опытного программиста фреймворк и принятые правила будут помогать ему не сбиться с пути и не нагородить огород изобретая свои велосипеды.
А если я не доверяю коллеге — то я с ним не работаю, если я не доверяю инструменту — то я его не использую.
> хороший код, это такой. который не меняет архитектуры со временем
Хороший код — код который делает именно то что надо и при этом легко читается и готов к изменениям. Но этим пожалуй не ограничивается, можно еще привести кучу параметров.
> Важно стабильное качество, а не красота архитектуры.
Для меня важно стабильное качество, красота архитектуры и общая успешность проекта. И на мой взгляд это не взаимоисключающие моменты.
При этом я согласен с тем, что архитектура может меняться, если это даст преимущества стоящие этих изменений.
У нас ни на одном проекте нельзя допускать логических багов, любой баг нам может обойтись в копеечку (это очень большие копеечки), так как мы даем гарантию. Тесты, несколько уровней перед появлением в production, дают нам гарантию спокойствия, но даже в этой ситуации мы очень высоко ценим возможность быстро исправлять баги.
Если стала видимой закрытая категория, то скорее всего функционал попал в production не проверенным, тут фреймворк не причем, если честно.
> отвечу на вопросы:
Спасибо, но это были не вопросы, это были критерии, которым с ваших слов соответствуют ваши инструменты, о них то я (думаю и многие другие) и хотел бы услышать и более чем уверен что «любой говнокод-спагетти» вы не используете, так зачем приводить его в пример.
Тем более, что с утверждением что «любой говнокод-спагетти» является столь же гибким — я категорически не согласен, но спор на эту тему мне совсем не интересен.
> Ты, как и мы. программируешь на агиле
Нет, я программирую на PHP и Python в основном :) (это шутка).
> надеясь, что твой коллега, фреймворк и т.д. не подведут, это СТРАШНО
Это совсем не страшно. Про это можно написать целый пост, но думаю до меня это делали сотни людей.
Во многом фреймворк сильно выручает, когда несколько проектов разрабатывают на одном проверенном фреймворке я могу быть уверен, что программисту не придется неделю разбираться в проекте, я знаю, что подключая к работе менее опытного программиста фреймворк и принятые правила будут помогать ему не сбиться с пути и не нагородить огород изобретая свои велосипеды.
А если я не доверяю коллеге — то я с ним не работаю, если я не доверяю инструменту — то я его не использую.
> хороший код, это такой. который не меняет архитектуры со временем
Хороший код — код который делает именно то что надо и при этом легко читается и готов к изменениям. Но этим пожалуй не ограничивается, можно еще привести кучу параметров.
> Важно стабильное качество, а не красота архитектуры.
Для меня важно стабильное качество, красота архитектуры и общая успешность проекта. И на мой взгляд это не взаимоисключающие моменты.
При этом я согласен с тем, что архитектура может меняться, если это даст преимущества стоящие этих изменений.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Sign up to leave a comment.
Symfony 2.0, RequestHandler Component