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

Yoskaldyr

"Спамер"
Партнер клуба
@kudashevs если $options это 100% опциональные параметры, то будет что-то типа
PHP:
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

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

grigori

( ͡° ͜ʖ ͡°)
Команда форума
я тоже
Ага, работал я на проектах разных, где подобное практиковалось. Помню был один прекрасный проект, где требования исходили только от большого босса. Который к слову еще и застрял где-то в начале 90-х. Несмотря на ...
сходство предпосылок провел слияние с Oracle, и остался вице-президентом Oracle, corp. Вполне так успешно, должен сказать, вывел продукт в правый верхний квадрант Гартнера на корпоративном рынке на всех континентах в возрасте лет за 60.
Такие разные судьбы.
 

fixxxer

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

AmdY

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

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

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Во-первых, все параметры важны. Если пользователь передаёт опцию, он должен быть уверен, что она сработает.
это упрощение, не всегда так
Во-вторых логичнее и проще проверять параметр один раз во время установки, а не каждый раз когда дёргаешь метод завязанный на этом параметре. Это экономит дергание проверки и гарантирует, что ты в другом методе не забудешь проверить.
конечно

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

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

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