Какое поведение вы ожидаете/используете при инициализации объектов?

[Yoskaldyr]

@kudashevs если $options это 100% опциональные параметры, то будет что-то типа

public function __construct(string $filename, ParameterBag $options)

где ParameterBag это иммутабельный класс со строгой структурой. И всегда есть автокомплит и ошибиться очень трудно, а не то как с массивом в котором что угодно может быть и надо постоянно проверить существование ключей

 

[AnrDaemon]

С интересом наблюдаю как трактуется казалось бы подробно расписанный вопрос.

Предположите, что люди уже сталкивались с подобными вопросами и знают, почему их задают чаще всего.
И, да, согласен с предыдущим оратором - предполагаю, что такого г… не будет.

 

[grigori]

Программирование не оперирует вопросами. У нас есть функциональные и нефункциональные требования. Если в нефункциональных требованиях указано, что при реализации надо использовать некую стороннюю библиотеку - OK, смотрим API библиотеки, и пишем адаптер.
Наблюдать лучше в театре, там работают специально обученные этому люди.

 

[kudashevs]

Программирование не оперирует вопросами. У нас есть функциональные и нефункциональные требования. Если в нефункциональных требованиях указано, что при реализации надо использовать некую стороннюю библиотеку - OK, смотрим API библиотеки, и пишем адаптер.
Наблюдать лучше в театре, там работают специально обученные этому люди. А мы знаем.

Вот мы решили написать какой-то Open Source проект. Какие у него могут быть требования?

 

[grigori]

очевидно, если нет требований - это будет ни для чего не нужный проект

 

[kudashevs]

очевидно, если нет требований - это будет ни для чего не нужный проект

Так требования откуда возьмутся? Вот вы пишите: "Программирование не оперирует вопросами. У нас есть функциональные и нефункциональные требования. Если в нефункциональных требованиях указано, что при реализации надо использовать некую стороннюю библиотеку - OK, смотрим API библиотеки, и пишем адаптер. " и это прекрасно когда ты сидишь в теплом кресле, тебе их приносят и ты по ним кодишь. Не жизнь, а красота.

Если же требования никто не принесет, их где брать? Из головы это будет несколько однобоко и субъективно. Тогда их надо собрать. Вот этим и занимаюсь.

 

[grigori]

да, да, Вы все правильно пишите, бизнес-требования - как урожай, объективная реальность, от нас не зависят, надо пойти собрать, требования - от Бога )))

 

[kudashevs]

да, да, Вы все правильно пишите, бизнес-требования - как урожай, объективная реальность, от нас не зависят, надо пойти собрать, требования - от Бога )))

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

 

[grigori]

нет, не от пользователей,
требования в разработку передают product owner, аналитики и stakeholder - они медитируют, и в просветлении пишут,
а с пользователями разработчики общаются только на саппорте

разработчик, product owner, аналитик и stakeholder - это роли, не профессии

 

[kudashevs]

нет, не от пользователей,
требования в разработку передают product owner, аналитики и stakeholder - они медитируют, и в просветлении пишут,
а с пользователями разработчики общаются только на саппорте

Ага, работал я на проектах разных, где подобное практиковалось. Помню был один прекрасный проект, где требования исходили только от большого босса. Который к слову еще и застрял где-то в начале 90-х. Несмотря на все увещевания, что гостевая книга это не самая важная часть на сайте, что дизайн должен быть хотя бы в трендах, а не выглядеть как среднестатистический сайт на narod.ru, ну и т.д. решения им принимались решительно и единолично Судьба проекта думаю всем очевидна, потому что решают эту судьбу в итоге пользователи.

Подитоживая, да вы правы, часто требования в разработку передают product owner, аналитики и stakeholder. Однако если у последних нет обратной связи с пользователями или они оторваны от реальности, то ничем хорошим это не заканчивается (можно вспомнить Windows Phone, например). Поэтому обратная связь с пользователями должна как-то учитываться при сборе требований и дальше собираться в процессе поддержки продукта.

 

[fixxxer]

"Работал я как-то на проекте, где программисты писали код, так вот такой говнокод писали".

Если выполнять роль взялся человек профессионально непригодный, это не проблема роли

можно вспомнить Windows Phone, например

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

 

[kudashevs]

"Работал я как-то на проекте, где программисты писали код, так вот такой говнокод писали".

Если выполнять роль взялся человек профессионально непригодный, это не проблема роли

Если вы пишете про свой опыт, то позвольте поинтересовать, почему вы их не остановили от написания говнокода?

Если вы пишете с легким намеком, что профессеонально непригодным является рассказчик из предыдущего поста, то есть,то позвольте уточнить чего именно вы добиваетесь и какой именно реакции ожидаете?

 

[fixxxer]

Я не намекаю, я прямо говорю про "большого босса" из рассказа выше. Даже не знаю, как можно было воспринять иначе, какое-то уязвленное ЧСВ что ли

 

[kudashevs]

Я не намекаю, я прямо говорю про "большого босса" из рассказа выше. Даже не знаю, как можно было воспринять иначе, какое-то уязвленное ЧСВ что ли

Прошу прощения, излишняя моя мнительность сыграла злую шутку

 

[grigori]

я тоже

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

сходство предпосылок провел слияние с Oracle, и остался вице-президентом Oracle, corp. Вполне так успешно, должен сказать, вывел продукт в правый верхний квадрант Гартнера на корпоративном рынке на всех континентах в возрасте лет за 60.
Такие разные судьбы.

 

[fixxxer]

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

 

[AmdY]

Во-первых, все параметры важны. Если пользователь передаёт опцию, он должен быть уверен, что она сработает.
Во-вторых логичнее и проще проверять параметр один раз во время установки, а не каждый раз когда дёргаешь метод завязанный на этом параметре. Это экономит дергание проверки и гарантирует, что ты в другом методе не забудешь проверить.
В -третьих важна транзакционность, если программист начал работать с сервисом, то надо по максимуму гарантировать, что он не упадёт посреди работы. Те же транзакции бд хороший пример, если ты открыл транзакцию, то УЖЕ должен быть уверен, что роллбэк поддерживается и ты не запишешь мусор, который не сможешь откатить.

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

 

[kudashevs]

Спасибо за развернутый ответ

 

[grigori]

Во-первых, все параметры важны. Если пользователь передаёт опцию, он должен быть уверен, что она сработает.

это упрощение, не всегда так

Во-вторых логичнее и проще проверять параметр один раз во время установки, а не каждый раз когда дёргаешь метод завязанный на этом параметре. Это экономит дергание проверки и гарантирует, что ты в другом методе не забудешь проверить.

конечно

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

вот тут я вообще не согласен

Те же транзакции бд хороший пример, если ты открыл транзакцию, то УЖЕ должен быть уверен, что роллбэк поддерживается и ты не запишешь мусор, который не сможешь откатить.

обратный пример: saga patern

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

в рамках класса или библиотеки нельзя делать обработку ошибок в зависимости от конфигов, это будет нарушение контекстов