Здравствуйте, Alexander Polyakov, Вы писали:

0>>Лично я по этому опыту пришел к отказу от предварительного дизайна деревьев абстракции, а выращивании их путем рефакторинга кода, написанного без введения абстракций. ...
AP>А для языков с динамической типизацией такой подход работает?
Не вижу причин ему не работать, хотя в большом масштабе только на статически типизированных языках применял.
Возможно, что без статического контроля агрессивный рефакторинг становится более рискованным делом.

Здравствуйте, Alexander Polyakov, Вы писали:

AP>Вопрос задал, потому что хочется лучше понять, о чем говорит 0x7be.
AP>Ок, пусть для динамических языков тоже работает. Тогда следующий вопрос. Как осуществляется рефакторинг? Рассмотрим ситуацию. Пусть прошло много времени, достаточно, чтобы детали задачи исчезли из головы разработчика, или пришел другой разработчик. Встала новая задача. Для ее реализации требуется нарастить/обрезать текущие абстракции. Тесты написаны. Как разработчик будет загружать к себе в голову необходимый минимум информации для выполнения наращивания/обрезания абстракций? В случае статических языков есть навигация. Что в случае динамических языков?
Я не думаю, что навигация по типам — это game changer в вопросах "загрузки" знаний в мозг программиста. Плохой и/или непокрытый тестами код на статически типизированном языке тоже сложно понять и безопасно изменить.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, akava, Вы писали:

A>>https://freelance.ru/projects/335505/
A>>https://freelance.ru/projects/342878/
A>>https://freelance.ru/projects/342844/

E>А в каком из этих примеров тянет ввести вредную с будущем абстракцию?
Разговор вышел из контекста абстракций и перешел в контекст неопределенности в начале проекта. Именно это я и привел.
Но, например, при разработке интернет магазина можно захотеть сделать абстракцию мета-товар или "универсальный интерфейс к платежной системе". Да мало ли что можно надизайнить.

СУВ, akava

Здравствуйте, __kot2, Вы писали:

__>Здравствуйте, akava, Вы писали:
A>>Пример чего? Неопределенности в начале проекта? Вы издеваетесь???
__>пример того, как по первоначальным условиям было спроектировано грамотное решение (с примером условия и решения), затем задача изменилась всвязи с бизнес-требованиями и теперь грамотное решение, которое было разработано вначале оказалось ну вообще не в тему и пришлось все перекраивать
Так вот я об этом и говорю. Как можно спроектировать грамотное решение, если ты не до конца представляешь все тонкости задачи, а то что "очевидно еще в самом начале разработки" не соответствует реальности?

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

СУВ, akava

Здравствуйте, akava, Вы писали:
A>Когда все с самого начала понятно проектировать не сложно. Сложно проектировать с учетом изменения и уточнения требований. Вот это сложно.
мой опыт говорит о том, что нород умудряется проектировать даже простые вещи очень криво

A>Из-за этого даже целая группа методологий возникла, agile. И не только в нем, в больших и формальных методологиях тоже заклвдываются циклы обратной связи.
и тогда школьники регили "нам говорят сначала думать, потом делать, а у нас не получается, давайте мы будем делать, потом переделывать, потом еще переделывать и так пока мы всех не задолбаем и нас не пристрелят"

Здравствуйте, akava, Вы писали:

A>Но, например, при разработке интернет магазина можно захотеть сделать абстракцию мета-товар или "универсальный интерфейс к платежной системе". Да мало ли что можно надизайнить.

Дык можно, не не нужно. То, что сдуру можно накосячить с архитектурой, вовсе и не значит, что проектиовать систему не надо...

Здравствуйте, 0x7be, Вы писали:

0>Возможно, что без статического контроля агрессивный рефакторинг становится более рискованным делом.
Да. Как ты писал, подход опирается на рефакторинг. Какие средства, поддерживающие преобразования кода у нас есть:
1. человеческий мозг,
2. автоматизированное тестирование,
3. средства, основанные на статической типизиции.

Первый пункт. Человеческий мозг сильно ограничен по объему обрабатываемой информации.
Второй пункт. Полное покрытие требует экспоненциального количества тестов в зависимости от числа входных параметров.

Получается, "выращивание" правильных структур кода может опираться только на третий пункт.

Odersky похожую мысль высказывает: Great designs are often discovered, not invented.
http://www.infoq.com/presentations/data-types-issues

Здравствуйте, Erop, Вы писали:

A>>Но, например, при разработке интернет магазина можно захотеть сделать абстракцию мета-товар или "универсальный интерфейс к платежной системе". Да мало ли что можно надизайнить.

E>Дык можно, не не нужно. То, что сдуру можно накосячить с архитектурой, вовсе и не значит, что проектиовать систему не надо...
Отвечу тем же То что знания о задаче и требования к ней могут менятся, вовсе и не значит, что проектировать не нужно...

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

СУВ, akava

Здравствуйте, Alexander Polyakov, Вы писали:

AP>Второй пункт. Полное покрытие требует экспоненциального количества тестов в зависимости от числа входных параметров.
По моему опыту, не нужно 100% покрытие (всех веток вычислений), чтобы достаточно безопасно проведести рефакторинг. А уж ляпы, связанные с типизацией, ловятся еще меньшим количеством тестов.
С другой стороны, 100% покрытие не гарантирует отсутствие багов.

СУВ, akava

Здравствуйте, Alexander Polyakov, Вы писали:
AP>Первый пункт. Человеческий мозг сильно ограничен по объему обрабатываемой информации.
поэтому стоит избегать связности между компонентами

AP>Второй пункт. Полное покрытие требует экспоненциального количества тестов в зависимости от числа входных параметров.
тесты надо уметь писать

Здравствуйте, akava, Вы писали:

E>>Дык можно, не не нужно. То, что сдуру можно накосячить с архитектурой, вовсе и не значит, что проектиовать систему не надо...
A>Отвечу тем же То что знания о задаче и требования к ней могут менятся, вовсе и не значит, что проектировать не нужно...

A>Но нужно быть готовым выкинуть и переделать, когда ситуация (или ее понимание) сильно изменится.
A>А чтобы понимание пришло раньше, а не позже, существуют техники. Например, прототипирование и ранняя обратная связь от пользователя.

А я с этим полностью согласен. И грамотная архитектура тут очень в тему будет, так как позволит выикинуть не всё, а только то, что устареет. И тут абстракции на пользу, а не во вред, обычно...

Здравствуйте, Eternity, Вы писали:

E>От использования абстракций в программировании у меня осталось впечатление об их большем вреде,
то есть fopen во вашему вред, а программирование НГМД на асме через порты ввода-вывода по вашему благо?

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

E> С другой стороны, писать конкретный прямолинейный код может быть еще более разрушительно,
вы путаете абстракцию с декомпозицией. это разные вещи.

E> что абстракции были сделаны не в тех местах, недостаточны или просто не подходят под новую задачу,
это нужно обсуждать на конкретных примерах. хорошим примером абстракции является файловая система. "хорошим" в плохом смысле этого слова. работа с большим кол-вом мелких файлов на хардах ужасно тормозит, но если натянуть поверх фс еще один уровень абстракции, сложив мелкие файлы в tar-подобный формат и упорядочив их в том порядке в каком к ним осуществляется доступ -- получаем колоссальный выигрыш (десятки, а то и сотни раз). конечно, не без ограничений. произвольный доступ к tarу будет ничуть не быстрее. это и есть проблема абстракций. популярные фс не позволяют создать группу файлов с последовательным доступом.

Здравствуйте, Erop, Вы писали:

A>>Но нужно быть готовым выкинуть и переделать, когда ситуация (или ее понимание) сильно изменится.
A>>А чтобы понимание пришло раньше, а не позже, существуют техники. Например, прототипирование и ранняя обратная связь от пользователя.

E>А я с этим полностью согласен. И грамотная архитектура тут очень в тему будет, так как позволит выикинуть не всё, а только то, что устареет. И тут абстракции на пользу, а не во вред, обычно...
Ну тогда мирдружбажвачка и, конечно же,

СУВ, akava