хороший код - мало боли, плохой код - много боли. Возможно боль не для разработчика а для пользователей (есть разработчики которым норм и в самом таком трешачке) или для менеджеров или для qa

это субъективная метрика оценивающая комфорт работы с проектом

*других людей, ремарка;

да, пожалуй так лучше)

тогда хороший код не нужен)

Я бы сказал не комфорт, а прогнозируемость

Я бы сказал не комфорт, а прогнозируемость

ну хз для меня прогназируемость это одна из составляющих комфорта

мне не комфортно когда я чего-то не знаю

Бизнесу важно планировать. "Точно" зачастую важнее, чем "быстро".

"точно" нужно, если "быстро" срывается)

и ушли в срач)

бизнесу надо даром и максимально быстро, желательно сразу

кто знаком с сборками ява л2

и чтобы один раз заплатил (заказал) и потом работало само

бизнесу надо даром и максимально быстро, желательно сразу

а лучше настолько сразу, что прям внезапно </оффтоп>

Бизнесу важно планировать. "Точно" зачастую важнее, чем "быстро".

а еще у бизнеса есть такая штука как управление рисками. Если бизнесу нужно знать точно и они не учитывают риски - ну так себе

ага

ну там свое веселье

смысл в том что если пишешь код который простой и понятный и поддерживаемый

то могут сменить типо что нам платить company1 ltd

давайте платить company2 ltd у них 1 час на 20$ дешевле

ну и что что они из индии

там индусы работают ?

они мамой клянутся что смогут делать также и даже лучше

и как бонус дарят 100 часов если выберем их

так реальность работает и демпинг

и первое время он работает, потом низкое качество даст о себе знать

усложнится код, усложнится поддержка

и станет дороже в итоге

при этом стоймость часа работы не изменится

до 3-ей версии так и было. Логику писали на Си, а PHP отвечал только за view.

ну да, я тоже помню те старые добрые вермена, когда я вызывал ассемблер из программ на бейсике

хороший код - мало боли, плохой код - много боли. Возможно боль не для разработчика а для пользователей (есть разработчики которым норм и в самом таком трешачке) или для менеджеров или для qa

у меня в тяпницу возникло ощущение полного удовлетворения архитектурой разработанного мной модуля авторизации через соц сети для одной ecommerce платформы

у меня в тяпницу возникло ощущение полного удовлетворения архитектурой разработанного мной модуля авторизации через соц сети для одной ecommerce платформы

понадобилось всего 2 недели то

ну да, я тоже помню те старые добрые вермена, когда я вызывал ассемблер из программ на бейсике

ты про ассемблервые вставки?

у меня в тяпницу возникло ощущение полного удовлетворения архитектурой разработанного мной модуля авторизации через соц сети для одной ecommerce платформы

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

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

если ты пилишь что-то одноразовое - париться об архитектуре смысла нет.

ну и далее надо анализировать и предсказывать возможные изменения

ну и далее надо анализировать и предсказывать возможные изменения

Нуууу

Зачем?

Предсказывать

ну потому что если ты хочешь использовать SOLID то тебе нужен палантир

с возможностью предсказывать веротность изменений по тем или иным причинам

естественно что предсказывать возможно только если разработчик хорошо понимает что он делает и предметную область.

Всем ку

с тебя 3 кц

ну потому что если ты хочешь использовать SOLID то тебе нужен палантир

Пока не вижу связи

Ну мол а как же принцип 1 раз прощаем коду, второй раз рефакторим

естественно что предсказывать возможно только если разработчик хорошо понимает что он делает и предметную область.

в это хотят верить менеджеры

в предсказывать возможно

Ну мол а как же принцип 1 раз прощаем коду, второй раз рефакторим

можно так когда совсем непонятно)

в предсказывать возможно

мы говорим про разный уровень предсказаний)

а ок)

если ты пилишь модуль формирования стоимости ты вполне можешь допускать "эти чуваки могут потом еще попросить скидки прикрутить"

просто есть 3 вида лжи, ложь, наглая ложь и оценка трудозатрат

если ты пилишь модуль формирования стоимости ты вполне можешь допускать "эти чуваки могут потом еще попросить скидки прикрутить"

kiss же )

kiss же )

yagni скорее

kiss вообще о другом

если ты пилишь модуль формирования стоимости ты вполне можешь допускать "эти чуваки могут потом еще попросить скидки прикрутить"

Имея это предположение, что ты будешь делать?

достаточно делать нормально

без лишних штук

а потом свистелки можно добавить

опять же не костылями а нормально

и будет нормально

Имея это предположение, что ты будешь делать?

а это уже тебе решать. По хорошему мы таким образом определяем не нарушили ли мы SRP ну и на O/C это влияет. Можем забить, можем не забить. Тут уже надо думать) Ну мол если ты знаешь что "в следующем спринте это будем делать" - то наверное забивать не над

ERROR: S client not available

ну и есть очевидные вещи которые не стоят дополнительного эфорта (например дизайнер может захотеть улучшить ux а мой лид может попросить меня переделать запрос в базу... наверное за UI и за выборки из базы должны разные штуки отвечать)

без лишних штук

это про yagni

kiss - это ты должен стараться делать вещи так, что бы ими было удобно пользоваться

это не значит что ты должен все делать влоб

вообще ниразу я бы так даже сказал

это очень холиварно

я обычно делаю как получится)

:D

))

это очень холиварно

ну вот можем похоливарить) Для меня KISS это когда ты думаешь над интерфейсами и инкапсуляцией. Что бы снаружи у тебя было просто и удобно. Но это не значит что сделать просто и удобно легко.

то есть тупое simple vs easy

я согласен)

пойду лучше допишу psr/container имплементацию в свой выходной)

вот во вторник зарелижусь и пойду бездельничать (контрибьютить опенсурс) на дня 3-4

куда контрибьютить будешь?

вообще думал свои проекты доделать

json matcher дописать

(оказалось что им пользуются не только чуваки которые у меня в команде)))

перепилить request-objects мои

доктрину может попилю чутка

ой, туда соваться - себе дороже

ну у меня уже есть на треть реализованная фича

надо денек посидеть допилить

ну мол что бы можно было в SELECT new Foo(u) сущности и embeddable передавать а не только скаляры

а

ну и как оказалось если это будет сделано то вложенные new автоматом подтянутся

хз.... может и не стоит... может стоит лучше подумать над хелперами для упрощения написания своих гидраторов

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

Ага, я вот в тайпскрипт залез, думал в парсере немного поправить, чтобы спеке соответствовал, зарылся ваще капец)

тебе еще потом свой код вливать )))