Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 11 [12] 13 14 15   вперед  Ctrl
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
mayton
Member

Откуда: loopback
Сообщений: 41006
казинак
mayton
пропущено...

Рад что у вас есть главный архитектор. Но я надеюсь что вы его не дёргаете по пустякам.
В противном случае я ему очень сочувствую.
само слово "архитектор" - это как пук в лужу
за ним ничего не стоит
только пузырьки и недолгая вонь...

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

если для вас ето слово имеет магический смысл, то сочувствую...

Да кто-же ты? В какой эпохе ты живешь?

Зайди в LinkedIn! Там есть вакансии и должности с названием
Software Architect!

Зайди прочти-жеж!
16 апр 19, 19:58    [21864253]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3247
Озверин
Андрей Панфилов, я понимаю, о чем вы говорили изначально, но я отвечал именно на то, что выделил в отдельную вашу цитату. В остальном, да, надо нанимать грамотных специалистов, поднимать культуру кодирования, проводить код ревью, учить людей палкой писать понятные именования переменных и все такое. Но в итоге все проекты приходят все равно к тому, что рефакторить надо.
Я все равно вас решительно не понимаю. Вот смотрите, любое управляющее воздействие можно разделить на "реактивное" и "проактивное" - разница примерно как между "разгребать последствия пожара" и "предотвратить пожар" (если хотите, то могу примеры привести, но думаю смысла не имеет). Вот ревью кода, очевидно, относится к проактивному управлению, а рефакторинг - в большинстве случаев это уже тушение пожара. Более того, не понятен вот какой момент: ревьювер "пропустил" (т.е. после ревью не осталось никаких артефактов) стремный код, что в свою очередь означает, что каким образом можно сделать код лучше ревьювер не знает, откуда тогда вообще возникает тогда идея сделать рефакторинг?
17 апр 19, 09:13    [21864429]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
mayton
Member

Откуда: loopback
Сообщений: 41006
Андрей Панфилов
Озверин
Андрей Панфилов, я понимаю, о чем вы говорили изначально, но я отвечал именно на то, что выделил в отдельную вашу цитату. В остальном, да, надо нанимать грамотных специалистов, поднимать культуру кодирования, проводить код ревью, учить людей палкой писать понятные именования переменных и все такое. Но в итоге все проекты приходят все равно к тому, что рефакторить надо.
Я все равно вас решительно не понимаю. Вот смотрите, любое управляющее воздействие можно разделить на "реактивное" и "проактивное" - разница примерно как между "разгребать последствия пожара" и "предотвратить пожар" (если хотите, то могу примеры привести, но думаю смысла не имеет). Вот ревью кода, очевидно, относится к проактивному управлению, а рефакторинг - в большинстве случаев это уже тушение пожара. Более того, не понятен вот какой момент: ревьювер "пропустил" (т.е. после ревью не осталось никаких артефактов) стремный код, что в свою очередь означает, что каким образом можно сделать код лучше ревьювер не знает, откуда тогда вообще возникает тогда идея сделать рефакторинг?

Добавлю что самие жёсткие рефакторинги мы проводили просто после того как прилетали
дополнительные BR от заказчика. Яркий пример - Биржевая система состоит из трех уровней.
Балансировщик нагрузки. Процессинг. И связи с торговыми площадками. Изначально новый
функционал мы внедрили в уровень связей с площадками. Но когда поняли что нужен
доступ к справочникам - потребовался перенос части логики в уровень процессинга.
Перено повлёк за собой изменение кода + рефакторинг. Такой был дизайн.

Иногда просто переделать код без рефакторинга невозможно. Комплексити высок.

Вообще лично для меня 80% активности разработки - это борьба со сложностью.
17 апр 19, 10:06    [21864506]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3247
mayton
Добавлю что самие жёсткие рефакторинги мы проводили просто после того как прилетали
дополнительные BR от заказчика. Яркий пример - Биржевая система состоит из трех уровней.
Балансировщик нагрузки. Процессинг. И связи с торговыми площадками. Изначально новый
функционал мы внедрили в уровень связей с площадками. Но когда поняли что нужен
доступ к справочникам - потребовался перенос части логики в уровень процессинга.
Перено повлёк за собой изменение кода + рефакторинг. Такой был дизайн.

Иногда просто переделать код без рефакторинга невозможно. Комплексити высок.

Вообще лично для меня 80% активности разработки - это борьба со сложностью.
Я вас тоже не понимаю. Вы, конечно, не особо любитель выкладывать код, но давайте, покажите что там да как было и стало, мы посмотрим (по пути обоссым архитектора )
17 апр 19, 10:43    [21864568]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
mayton
Member

Откуда: loopback
Сообщений: 41006
Я вас умоляю... Я нарушу кучу соглашений.
17 апр 19, 11:12    [21864620]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3247
mayton
Я вас умоляю... Я нарушу кучу соглашений.
Ну а как мы тогда узнаем, действительно там рефакторинг нужен или просто у вас команда про IoC не в курсе?
17 апр 19, 11:31    [21864660]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
mayton
Member

Откуда: loopback
Сообщений: 41006
Андрей Панфилов
mayton
Я вас умоляю... Я нарушу кучу соглашений.
Ну а как мы тогда узнаем, действительно там рефакторинг нужен или просто у вас команда про IoC не в курсе?

Каким образом IoC избавляет от рефакторинга?
17 апр 19, 11:47    [21864699]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3247
mayton
Каким образом IoC избавляет от рефакторинга?
Я даже слов не могу подобрать чтобы ответить.
17 апр 19, 11:55    [21864719]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
mayton
Member

Откуда: loopback
Сообщений: 41006
Тоесть... тема исчерпана.
17 апр 19, 11:56    [21864720]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3247
mayton
Тоесть... тема исчерпана.
Для себя можете считать что исчерпана, поскольку вы "включили индуса". Объясняю:
- ваш код ничего не стоит, просто потому что он никому не нужен
- умение набросать простенький код, указывающий на проблему - это тоже своего рода показатель зрелости разработчика (у индюков в большинстве случаев дела обстоят примерно так: они вендору описать проблему нормально не могут, потому что весь код показывать не хотят, а набросать тестовый сценарий не в состоянии, в итоге у вендора такие обращения висят либо годами, либо проактивно закрываются, а код индусов обрастает костылями, а потом начинается рефакторинг и все что вы проповедуете ), время на это несоизмеримо мало в сравнении с тем, сколько вы здесь просиживаете постя бессмысленные комментарии
17 апр 19, 12:26    [21864785]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
mayton
Member

Откуда: loopback
Сообщений: 41006
Это капец какой-то. Яже тебе намекнул на NDA. Что ты хотел увидеть? Что мы неправильно разбили софт
на компоненты? Да мы и не делали этого. Ибо не знали что ТАК БУДТЕТ. Да дорогой мой друг. Мы наперед
не знали какие будут дополнения к BR.

И я конечно же внутренне тебе завидую и восхищаюсь что у тебя таких ситуаций не бывает. У тебя всё
всегда правильно задизайнено. Дай бох.
17 апр 19, 12:36    [21864803]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3247
mayton
Это капец какой-то. Яже тебе намекнул на NDA. Что ты хотел увидеть? Что мы неправильно разбили софт
на компоненты? Да мы и не делали этого. Ибо не знали что ТАК БУДТЕТ. Да дорогой мой друг. Мы наперед
не знали какие будут дополнения к BR.
Ну почему вы считаете что я намеков не понимаю? я прекрасно понял что набросать пару строк кода вы не в состоянии, здесь все понятно. Дальше, например, Sergunka пишет в защиту рефакторинга:
Sergunka
Maintainable code is code that exhibits high cohesion and low coupling. Cohesion is a measure of how related, readable and understandable code is. ... Maintainability is itself a measure of the ease to modify code, higher maintainability means less time to make a change.
Не знаю как насчет "high cohesion", но "low coupling" - это непосредственная фича IoC/DI, и после этого вы меня спрашиваете какое отношение IoC имеет к ненужности рефакторинга? самому не стыдно?
mayton
И я конечно же внутренне тебе завидую и восхищаюсь что у тебя таких ситуаций не бывает. У тебя всё
всегда правильно задизайнено. Дай бох.
Работа разработчика заключается первым делом в применении мозга, а не в бездумном кодинге, в следствие чего мне, к примеру, не свойственно принимать все безумные идеи на веру.
17 апр 19, 12:55    [21864836]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
alex55555
Member

Откуда:
Сообщений: 2129
mayton
Приведите пример.

Заказчик:
автор
А вот здесь сделайте кнопочку, что бы она отправляла все данные в налоговую.
17 апр 19, 13:00    [21864844]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
alex55555
Member

Откуда:
Сообщений: 2129
казинак
некомпетентость всегда победит

Можно выстраивать многоуровневую систему.
17 апр 19, 13:01    [21864848]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
alex55555
Member

Откуда:
Сообщений: 2129
казинак
если для вас ето слово имеет магический смысл, то сочувствую...

Ну понятно, для тебя только твои мысли умные.
17 апр 19, 13:02    [21864851]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
alex55555
Member

Откуда:
Сообщений: 2129
Андрей Панфилов
mayton
Каким образом IoC избавляет от рефакторинга?
Я даже слов не могу подобрать чтобы ответить.

Вообще было бы хорошо, если слова сумели бы подобраться.
17 апр 19, 13:05    [21864855]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3247
alex55555
Вообще было бы хорошо, если слова сумели бы подобраться.
зачем? из прочитанного я понял, что народ IoC использует просто потому что так модно (когда-то давно было модно apache-commons пихать во все щели), а то на самом деле какие возможности он предоставляет никому не интересно.
17 апр 19, 13:08    [21864859]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
alex55555
Member

Откуда:
Сообщений: 2129
Андрей Панфилов
Не знаю как насчет "high cohesion", но "low coupling" - это непосредственная фича IoC/DI, и после этого вы меня спрашиваете какое отношение IoC имеет к ненужности рефакторинга?

Любую фичу можно применить ограниченно. Например вставить IoC в одном уровне, что всё равно не позволит задействовать этот принцип из другого, банально библиотеки разные, возможно даже проекты разделены.

Архитектура же пытается минимизировать подобные издержки в будущем, но поскольку будущее весьма расплывчато, нередко можно промахнуться. Опыт позволяет учитывать больше, но и он не идеал. И уж тем более если мы будем концентрироваться на "качестве кода", а не архитектуре (то есть станем обсуждать простейшие паттерны вместо общих архитектурных решений), то мы и получим "качественный" уровень, а вот сумма уровней будет некачественной.

IoC это уровень не самый высокий, где-то средний между проектом и классом. Важнее, безусловно, проект. Класс - на самом последнем месте. Но концентрироваться любят на качестве кода именно в классах.
17 апр 19, 13:16    [21864873]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
alex55555
Member

Откуда:
Сообщений: 2129
Андрей Панфилов
зачем?

Ну да, уровень читателе не всегда высокий, но как-то коротко сформулировать возражение - это правильная практика. А уход от формулировки "по делу" обычно означает либо игнор оппонента, либо отсутствие умения кратко сформулировать. Вы ведь не игнорируете Майтона? Способны кратко сформулировать? Значит в вашем случае вариант номер три - лень. Нет?
17 апр 19, 13:19    [21864880]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3247
alex55555
Любую фичу можно применить ограниченно. Например вставить IoC в одном уровне, что всё равно не позволит задействовать этот принцип из другого, банально библиотеки разные, возможно даже проекты разделены...
Вы тезис о том, что IoC снижает потребности в рефакторинге хотите дополнить или оспорить?

alex55555
Ну да, уровень читателе не всегда высокий, но как-то коротко сформулировать возражение - это правильная практика. А уход от формулировки "по делу" обычно означает либо игнор оппонента, либо отсутствие умения кратко сформулировать. Вы ведь не игнорируете Майтона? Способны кратко сформулировать? Значит в вашем случае вариант номер три - лень. Нет?
Я в первую очередь пытаюсь получитьстроить свое мнение на каких-то более-менее измеримых вещах, т.е.:
- рефакторинг нужно делать тогда, когда команда проголосовала - это изменить нельзя (читайте про шлюх)
- а у нас вот в проекте под NDA (наверное делаем его для NSA) постоянно происходит особо жесткий рефакторинг - это тоже измерить нельзя

когда мы не можем что-либо измерить вместо нормального диалога получается спор, подобный тому, как спорят дети в песочнице: а у меня папа боксер, попробуй что-то возразить.
17 апр 19, 13:36    [21864916]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
alex55555
Member

Откуда:
Сообщений: 2129
Андрей Панфилов
Вы тезис о том, что IoC снижает потребности в рефакторинге хотите дополнить или оспорить?

Если непосредственно о данном паттерне, то иногда он просто мешает. Для его эффективной работы нужно сочетание таких факторов, как простота вызывающей стороны, качество её реализации, качество её документирования, качество обучения пользователей (программистов, "оборачиваемых" предлагаемой средой), качество коммуникаций как в отдельных командах (среда/обработчики событий), так и между ними. В общем рефакторингом здесь можно заниматься, но если не решены выше показанные проблемы, то весь рефакторинг уйдёт в свисток.
Андрей Панфилов
Я в первую очередь пытаюсь получитьстроить свое мнение на каких-то более-менее измеримых вещах

Вот китайцы тоже умеют измерять. Они давно этому научились. Считают по головам - этот кодит? Хорошо. А этот? Этот думает. Так он лентяй! Все кодят, а он, понимаете ли, думает (бездельничает)! В итоге китайское качество нам всем хорошо известно.

На разработку влияют много факторов. Можно править измеримые "по простому", но тогда опять пар движется больше в направлении свистка. И можно работать со сложной системой, что-то измеряя, и что-то просто направляя примерно в сторону хорошего результата. В первом случае измерения скатываются в аджайл-скачки и китайский подход "некогда думать, прыгать надо".
18 апр 19, 11:51    [21865904]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Андрей Панфилов
Озверин
Андрей Панфилов, я понимаю, о чем вы говорили изначально, но я отвечал именно на то, что выделил в отдельную вашу цитату. В остальном, да, надо нанимать грамотных специалистов, поднимать культуру кодирования, проводить код ревью, учить людей палкой писать понятные именования переменных и все такое. Но в итоге все проекты приходят все равно к тому, что рефакторить надо.
Я все равно вас решительно не понимаю. Вот смотрите, любое управляющее воздействие можно разделить на "реактивное" и "проактивное" - разница примерно как между "разгребать последствия пожара" и "предотвратить пожар" (если хотите, то могу примеры привести, но думаю смысла не имеет). Вот ревью кода, очевидно, относится к проактивному управлению, а рефакторинг - в большинстве случаев это уже тушение пожара. Более того, не понятен вот какой момент: ревьювер "пропустил" (т.е. после ревью не осталось никаких артефактов) стремный код, что в свою очередь означает, что каким образом можно сделать код лучше ревьювер не знает, откуда тогда вообще возникает тогда идея сделать рефакторинг?


а я решительно не понимаю вас, потому что вы пишите вещи как-будто и правильные, но и одновременно как-будто живете на поляне с единорогами. Все знают, что код ревью, архитектор и все такое и ВСЕ РАВНО нет НИ ОДНОГО проекта, длительностью от 1 года, ГДЕ НЕ ТРЕБОВАЛСЯ бы рефакторинг.

У вас есть примеры? У меня, лично, нет. Из чего я делаю вывод, что ваши слова да -правильные, но что-то не так с ними, раз не работает?
18 апр 19, 11:57    [21865913]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
chpasha
Member

Откуда:
Сообщений: 7980
Озверин
Все знают, что код ревью, архитектор

и что живут они примерно там же, где единороги Картинка с другого сайта.
18 апр 19, 12:15    [21865939]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Андрей Панфилов,
Вы тезис о том, что IoC снижает потребности в рефакторинге хотите дополнить или оспорить?


Давайте посмотрим, как нам помогает ioc в проектах.

До ioc код выглядит вот так:

public class A {
 private B b = new BImpl();
}


После возмущений отдела тестирования код выглядит так:

public class A {
 private B b;

 public A(B b) {
  this.b = b;
}
}



public class A {
 @Autowired
 private B b;
}


После код ревью и проверки на чек стайл код выгляди так:

public class A {

 private B b;
 
 @Autowired
 public A(B b) {
  this.b = b;
 }
}


Внимание, вопрос!?
18 апр 19, 12:29    [21865957]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
mayton
Member

Откуда: loopback
Сообщений: 41006
Озверин
Андрей Панфилов
пропущено...
Я все равно вас решительно не понимаю. Вот смотрите, любое управляющее воздействие можно разделить на "реактивное" и "проактивное" - разница примерно как между "разгребать последствия пожара" и "предотвратить пожар" (если хотите, то могу примеры привести, но думаю смысла не имеет). Вот ревью кода, очевидно, относится к проактивному управлению, а рефакторинг - в большинстве случаев это уже тушение пожара. Более того, не понятен вот какой момент: ревьювер "пропустил" (т.е. после ревью не осталось никаких артефактов) стремный код, что в свою очередь означает, что каким образом можно сделать код лучше ревьювер не знает, откуда тогда вообще возникает тогда идея сделать рефакторинг?


а я решительно не понимаю вас, потому что вы пишите вещи как-будто и правильные, но и одновременно как-будто живете на поляне с единорогами. Все знают, что код ревью, архитектор и все такое и ВСЕ РАВНО нет НИ ОДНОГО проекта, длительностью от 1 года, ГДЕ НЕ ТРЕБОВАЛСЯ бы рефакторинг.

У вас есть примеры? У меня, лично, нет. Из чего я делаю вывод, что ваши слова да -правильные, но что-то не так с ними, раз не работает?

Я-бы просто добавил что нет единой точки зрения на рефакторинг даже среди двух синьоров.
Да и нельзя обсуждать сферический рефакторинг. Это всегда - в контексте задачи и будущих
возможных изменений. И как можно вообще "со слов" сделать суждение о качестве кода.
18 апр 19, 12:40    [21865969]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 11 [12] 13 14 15   вперед  Ctrl
Все форумы / Java Ответить