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

И им нужно сайтики на вп клепать

так устроено большинство компаний

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

вот слова работающего человека

так устроено большинство компаний

В аутсорсе может быть и есть такая помойка) Там даже один челик весь сайт будет клепать

Идешь в продуктовую и такой проблемы не будет ))

а где нету?

а где нету?

В сказочной стране.

вот слова работающего человека

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

В сказочной стране.

именно, вон человек от туда

но как только ты пошел в беспощадный Ынтерпрайз или екомерс все, ехала)

Миямирок или как там)

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

или ты не видишь косяки

или ты не видишь косяки

конечно, я не отрицаю)

я потому и написал что относительно)

поэтому нет ничего идеального

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

чтобы его можно было переписывать

и выкидывать в случае чего

а для этого надо понимать зависимости

для этого нужен скилл большой

вроде так просто всего 2 критерия, удовлетворить хотелки бизнеса и сохранить поддерживаемость)

и от чего зависит код

Все равное твой код выкину и перепишут.

а пока моя работа выполняется как то так: пишу как могу, что бы это работало

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

это збс

ха, еще более збс если код отвязан от фреймворка)

поэтому я и говорю solid, grasp, и зависимости

модульность форева

ха, еще более збс если код отвязан от фреймворка)

не везде это надо

вообщем никогда не бывает идеально

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

intellectsoft к Сереге :D

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

В каком плане? XD Где все с сапогом в жопе бегают?)

В каком плане? XD Где все с сапогом в жопе бегают?)

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

нежели выполнить хотелку быстрее паровоза

а там дальше фиксить баги

навыки команды

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

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

это как прочность цепи

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

я ж не говорю сейчас

прочность цепи равна прочности самого слабого звена

я говорю в перспективе

ну да

когда все по стандарту, это збс

так же и с командой

методологии можно юзать если вся команда их понимает или большинство

но такие строгие требования наверн только в софтверных компаниях

но у всех разные стандарты

посмотрите в россии про agile

каждый второй работает по agile

проходит курсы по agile

и тд

и у всех он свой

каждый второй работает по agile

это скорее шутка)

также и у разработчиков

а есть команды адекватные

http://macode.ru/

но его воспринимают новички как шутку

но во всех методологиях самое главное это писать норм код

но во всех методологиях самое главное это писать норм код

Так это ж сампое простое писать норм код, берешь и пишешь!

это приходит с опытом

А еще тебе ставят задачи и ты их выполняешь.

ERROR: S client not available

посмотри свой код написанный год назад

А еще тебе ставят задачи и ты их выполняешь.

?

изи

ладно это холиварненько)

там со второго раза обычно доходит, но суть в том что прочитать всеравно надо хотя бы один раз

ну хз на счет со второго)

потому что оно сложное и куча трактовок

вообще это трэйдмарк Эрика Эванса, а куча трактовок от людей которые даже его книгу не читали.

ну хз на счет со второго)

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

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

ага

я до сих пор не понимаю, мне кажется

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

это нужно только для проектов которы относятся к "сложным" (где между причиной и следствием много чего происходит)

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

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

аминь

вообще это трэйдмарк Эрика Эванса, а куча трактовок от людей которые даже его книгу не читали.

+++++

я понял одно надо читать оригиналы

это всегда правильнее

и эффективней

http://c2.com/

вот еще рекомендую почитать

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

ну и там тусят всякие Ворды Канингхемы, Кенты Бэки, Мартины Фаулеры и Дяди Бобы периодически заглядывают даже.

сразу видно сайт програмисты делали

по дизайну

ламповый

не просто программисты - это WIKI чувака который придумал WIKI

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

Верно. Что бы код домена был по своей сути отражением бизнес процессов. А вся инфраструктура была сквозная и/или вынесена из домена

Следующая ступень - dsl :)

А вообще bounded contexts нужно и можно в повседневной разработке использовать. Так же как и cqrs.

Во всяком случае, объяснить пользу этих концепций проще чем аггр рут и то что pojo это не про геттеры и сеттеры))

bounded contexts да, а вот про cqrs так однозначно не скажу