Фреймворки, что, где, когда?

[AnrDaemon]

Затем, что в инструкции может быть написан любой бред.
А когда ты своими глазами видишь, по каким направляющим скользит затвор, и где у него триггер - мысль работает совсем в других направлениях.

 

[Lionishy]

инструкции может быть написан любой бред.
А когда ты своими глазами видишь

То есть, Вы предлагаете использовать заведомо непригодный инструмент?

 

[Absinthe]

Возникает справедливый вопрос: "Зачем?"

Чтобы понимать, как оно работает, что увеличит скорость использования данного инструмента, а так же появится возможность исправить баги в нем (или понять, что бага нет).

У фреймворка тоже есть инструкция.
Зачем лазить внутрь с отладчиком?

Инструкции очень скудные.
Посмотри на документацию Doctrine или Laravel - очень яркие примеры.

 

[Absinthe]

То есть, Вы предлагаете использовать заведомо непригодный инструмент?

Инструмент пригодный, просто документация рассчитана на быстрое вхождение и самые распространенные варианты использования.

 

[Lionishy]

Absinthe, плохая инструкция -- плохой инструмент, как мне кажется.
В постановке: "Я не знаю, что вообще это за инструмент", -- лучше, действительно, писать свой на основе, скажем, регрессивного анализа негодного инструмента. А то потом там новую версию без документации выпустят и... Опять двадцать пять.

-------
Использую я, например, Boost. Я доверяю документации. В инструкции есть различные use cases, для которых инструмент предназначен. Если там нет чего-то, значит так инструмент использовать и не следует. А в исходные коды Boost я лезу только из личного интереса, но не в ущерб проекту.

 

[Absinthe]

Absinthe, плохая инструкция -- плохой инструмент, как мне кажется.
В постановке: "Я не знаю, что вообще это за инструмент", -- лучше, действительно, писать свой на основе, скажем, регрессивного анализа негодного инструмента. А то потом там новую версию без документации выпустят и... Опять двадцать пять.

А кто сказал, что инструкция плохая? Инструкция хорошая.
Она краткая, и показывает основные приемы использования инструмента.
Если расписывать все подробно, то это снизит ценность инструкции для новичков, ведь большая часть для них будет излишней, что сделает чтение документации неудобным, в результате читать ее никто не будет.
А когда нужна подробная информация - читайте код. Это к тому же и меньше времени займет.

Я считаю документацию по Laravel хорошей.

 

[MiksIr]

Имхо, у laravel отвратная документация. В сравнении, например, с Yii1.

 

[c0dex]

Что вы спорите то? Есть масса примеров, когда документация просто не покрывает того, что надо сделать и тогда приходится гуглить/изобретать велосипед.

 

[Absinthe]

Что вы спорите то? Есть масса примеров, когда документация просто не покрывает того, что надо сделать и тогда приходится гуглить/изобретать велосипед.

Вопрос в том, что некоторые люди считают, что с фреймворком надо обращаться как с черным ящиком и не лезть внутрь.

 

[c0dex]

Рано или поздно или из интереса, или из надобности, но подсмотреть придется.

 

[Lionishy]

с фреймворком надо обращаться как с черным ящиком

Разве в этом не цель фреймворка?
Пусть у нас есть некоторый проект, который реализуется на базе некоторого фреймворка.
Благодаря тому, что фреймворк определяет некоторые абстракции и ограничения, новый член команды, Алиса, может очень быстро приступить к выполнению тикетов, опираясь на документацию к фреймворку. Ей не нужно знать, что там внутри, она уже делает работу.
Любой приличный проект всегда строится на абстракциях, которые инкапсулируют свою реализацию, т. е. нам нет нужды узнавать как они работают, главное знать что они представляют.

По-моему так.

 

[c0dex]

Это все хорошо на словах на какой-нибудь конфе. Реалии жестче.

 

[fixxxer]

Lionishy, это в вашем boost-е, небось, в документации шик и блеск, кругом расписаны сложности используемых алгоритмов, узкие места и так далее. Потому что это то, о чем должен думать разработчик на низкоуровневых языках - и, соответственно, наличие такой информации в документации считается обязательным.

В высокоуровневых фреймворках все совсем не так, и не посмотрев внутрь - не узнаешь узких мест.

 

[MiksIr]

Наверно поиск узких мест начинают не в начале разработки на новом фреймворке... и даже не в середине =)

 

[fixxxer]

Ты так говоришь, как будто не понимаешь, о чем речь.

В начале надо вообще приблизительно понимать, как там внутри что работает в целом - на уровне "как бы я сам такое написал". Скажем, зачем нужен тот же eager load - это понятно не читая код вообще.

А когда надо искать узкие места - уметь понять код фреймворка, не изучая его целиком, а только в нужных местах.

 

[MiksIr]

Да не, это я даже не тебе, это я так Тут просто все понимают по-разному "заглядывать внутрь". Глядь, а у кого-то может уже и документация для фреймоврка вред, ибо мешает заглядывать внутрь с самого начала А по мне - чем позже полезу внутрь или хотя бы в гугль из-за нехватки доки, тем лучше.