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

E>По мне, так если язык действительно хороший (теплый взгляд в сторону C++ и Ruby), так на нем даже в Notepade (не говоря уже про vim и emacs) программировать можно.

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

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

E>>По мне, так если язык действительно хороший (теплый взгляд в сторону C++ и Ruby), так на нем даже в Notepade (не говоря уже про vim и emacs) программировать можно.

VD>А по-мне так если ты программирушь в нотпэде и тебя удовлетворяет скорость, то скорее всего скорость твоей разработки неприемлемо низка.

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

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

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

Вот-вот. Я классы в дизайнере проектрую, а ты в Нотпэде.

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

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

Это справедливо только для утилит командной строки. Продумать большую систему в голове без прототипирования, без проб и ошибок и последующего рефакторинга практически невозможно. А здесь скорость набора кода в редакторе играет не самую последнюю роль.

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

VD>Вот-вот. Я классы в дизайнере проектрую, а ты в Нотпэде.

Смешно. И грусно.

Я проектирую в уме. Результаты пытаюсь выразить на бумаге

Автор: eao197
Дата: 20.05.05

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

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

IT>Это справедливо только для утилит командной строки.

Хорошие утилиты командной строки дорогого стоят. И сделать их не проще, чем написать какое-нибудь GUI приложение.

IT> Продумать большую систему в голове без прототипирования, без проб и ошибок и последующего рефакторинга практически невозможно. А здесь скорость набора кода в редакторе играет не самую последнюю роль.

О каких системах ты говоришь?

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

E>Я проектирую в уме. Результаты пытаюсь выразить на бумаге

Автор: eao197
Дата: 20.05.05

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

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

Так мы плавно подходим к теме рефакторинга. Я опять же делаю его в мощьной IDE, а ты в снова в своем уме и Нотпэде.

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

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

E>Хорошие утилиты командной строки дорогого стоят. И сделать их не проще, чем написать какое-нибудь GUI приложение.

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

IT>> Продумать большую систему в голове без прототипирования, без проб и ошибок и последующего рефакторинга практически невозможно. А здесь скорость набора кода в редакторе играет не самую последнюю роль.

E>О каких системах ты говоришь?

О лбых сложнее тех что примитивны.

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

VD>А у меня планирование занимает минуты, от силы часы. А вот реализация почему-то дни. Причем заранее извесно, что после того, как реализация хоть как-то заработает, то после анализа (а то и в процессе разработки) будут выявлены неучтенные предпосылки которые приведут к изменению плана, а стало быть и кода.

VD>Так мы плавно подходим к теме рефакторинга. Я опять же делаю его в мощьной IDE, а ты в снова в своем уме и Нотпэде.

А почему учет неучтенных факторов должен обязательно требовать рефакторинга? Рефакторинг, если я не путаю, это изменение внутренностей кода, без изменения его функциональности. Здесь же речь идет об изменении функциональности. Далеко не факт, что это изменение потребует рефакторинга. Так же не факт, что подобные изменения не будут выявлены при предварительном проектировании.

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

И еще, я пользуюсь gvim -- это далеко не Notepad

VD>Эффективность такой экстенсиной разработки стримительно стремится к нулю. Не прийми это на свой счет, но ты даже не осознашь насколько не эффективно ты трудишся.

Главное, что это не осознает мой работодатель.

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

E>О каких системах ты говоришь?

Кто-то мне тут недавно приводил в качестве примеров Вижуал Студии, MS Офисы и прочие IE, Мазилы и Оперы Но я бы оценил это проще — если система предполагает затрат хотя бы в несколько человеко-месяцев, то продумать и удеражать её такую продуманную в голове крайне сложно. Да и не нужно. Очень часто всё это умножается ещё на неясные по началу функциональные требования.

Одним из реально работающих механизмов, позволяющих бороться со сложностью, является рефакторинг, который при больших объёмах кода немыслим без поддержки IDE.

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

IT>Кто-то мне тут недавно приводил в качестве примеров Вижуал Студии, MS Офисы и прочие IE, Мазилы и Оперы


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

IT> Но я бы оценил это проще — если система предполагает затрат хотя бы в несколько человеко-месяцев, то продумать и удеражать её такую продуманную в голове крайне сложно. Да и не нужно.

Все время не нужно. Только на момент проектирования. А это не так уж и сложно. Особенно, если нарезать систему на слои и не смешивать их без лишней надобности.

IT>Очень часто всё это умножается ещё на неясные по началу функциональные требования.

Но ведь нельзя же начать писать программу не зная, что именно она будет делать. Всегда ты представляешь себе, что требуется в данный момент. И вот здесь можно либо засесть за клавиатуру (чего тут думать, трясти нужно), а можно за бумагу. Я предпочитаю второй вариант.

IT>Одним из реально работающих механизмов, позволяющих бороться со сложностью, является рефакторинг, который при больших объёмах кода немыслим без поддержки IDE.

Всегда ли требуется рефакторинг, к примеру, 200 тысяч строк кода?

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

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

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

E>Более того, если ты будешь делать рефакторинг не думая, то есть очень большая вероятность, что ты будешь делать его неоднократно.

Именно неоднократно и со 100% вероятностью.

E>Вместо того, чтобы подумать и изменить только то, что действительно нужно.

А я и буду менять только то, что нужно. Впрочем, возможно у нас разное понимание 'нужно'.

В подходе "всё досканально продумать и реализовать" я уже давно разочаровался. Плохо он работает из-за того, что всё досканально продумать практически никогда не получается. Особенно в исследовательских проектах или проектах с неясными начальными требованиями. В таких проектах много приходится менять уже по ходу дела, и рефакторинг является незаменимой вещью и основным инструментом подхода, где мы не пытаемся минимизировать последующие изменения, а автоматизируем их, делаем этот процесс простым. Но, без поддержки IDE это не работает.

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

E>>Более того, если ты будешь делать рефакторинг не думая, то есть очень большая вероятность, что ты будешь делать его неоднократно.

IT>Именно неоднократно и со 100% вероятностью.

E>>Вместо того, чтобы подумать и изменить только то, что действительно нужно.

IT>А я и буду менять только то, что нужно. Впрочем, возможно у нас разное понимание 'нужно'.

Я не зря у тебя спращивал, о каких системах идет речь. Если дело касается каких-то GUI вещей, да еще разрабатываемых под конкретного заказчика со своими прибабахами, то здесь я с тобой соглашусь на 100%. Хотя у меня был опыт разработки специализированного векторного редактора, там так же пришлось сначала много чего спроектировать, прежде чем приступить к кодированию (например, как при выделении нескольких объектов в одну группу сделать диалог изменения свойств, который бы позволил изменять только те свойства, которые есть у всех объектов в группе).

Тем не менее, есть и другие системы (черные ящики, которые с пользователем не работают, а выполняю свою задачу). Из того, что лично я делал, вот пример

Автор: eao197
Дата: 24.01.05

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

IT>В подходе "всё досканально продумать и реализовать" я уже давно разочаровался. Плохо он работает из-за того, что всё досканально продумать практически никогда не получается. Особенно в исследовательских проектах или проектах с неясными начальными требованиями. В таких проектах много приходится менять уже по ходу дела, и рефакторинг является незаменимой вещью и основным инструментом подхода, где мы не пытаемся минимизировать последующие изменения, а автоматизируем их, делаем этот процесс простым. Но, без поддержки IDE это не работает.

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

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

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

IT>> Но я бы оценил это проще — если система предполагает затрат хотя бы в несколько человеко-месяцев, то продумать и удеражать её такую продуманную в голове крайне сложно. Да и не нужно.

E>Все время не нужно. Только на момент проектирования. А это не так уж и сложно. Особенно, если нарезать систему на слои и не смешивать их без лишней надобности.

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

IT>>Очень часто всё это умножается ещё на неясные по началу функциональные требования.

E>Но ведь нельзя же начать писать программу не зная, что именно она будет делать. Всегда ты представляешь себе, что требуется в данный момент. И вот здесь можно либо засесть за клавиатуру (чего тут думать, трясти нужно), а можно за бумагу. Я предпочитаю второй вариант.

Я, с некоторых пор, первый. Сажусь и начинаю писать код

E>Всегда ли требуется рефакторинг, к примеру, 200 тысяч строк кода?

Откуда я знаю? Надо хотя бы взглянуть на эти 200к строк

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

IT>А всегда ли всё уже ясно на момент проектирования? И всегда ли то, что напроектировано оказывается окончательным вариантом удовлетворяющим абсолютно всех?

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

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

IT>Я, с некоторых пор, первый. Сажусь и начинаю писать код

Может и я к тому же приду
Кстати, недавно писал на RubyOnRails, мне показалось, что там по другому вообще нельзя (по крайней мере, если не знаешь этот RoR в мельчайших деталях).

E>>Всегда ли требуется рефакторинг, к примеру, 200 тысяч строк кода?

IT>Откуда я знаю? Надо хотя бы взглянуть на эти 200к строк

Дык в том-то и дело, что 200k никогда и не требуется изменять. Обычно дело 1k-2k ограничивается. А на таких объемах можно и ручками обойтись (особенно, если вот так

Автор: eao197
Дата: 25.01.06

). Нужно только понять, какую именно тысячу строк выбросить

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

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

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

Вот пример из будквально того что было только что.

В RE (Rsdn.Editor) реализована работа со шрифтами. Вроде бы как все пашет, но есть проблема. Шрифт задается дотнетным объектом Font который не позволяет задать отдельные атрибуты шрифта. К тому же трудно организовать масштабирование шрифта (то есть сделать конечно можно, то при этом будет не очень красивое решение).

Заранее продумать такие мелкие подробности было конечно можно, но наличие столь мелких деталей резко усложняет сам план. По этому сначало все было реализовано в лоб, на базе дотнетных шрифтов, а потом был произведен рефакторинг/модификация кода цель которой замена System.Drawing.Font на более сложное решение, а именно на набор классов позволяющих задать срифт частично, комбинировать настройки шрифта и в итоге поулчить некую сущьность которую я назвал ZoomedFont которая прозрачно используется для конечных рассчетов и вывода на экран.

Изменения затронилу большую часть проекта.
http://rsdn.ru/projects/VcsStatus.aspx?project=Rsdn.Editor (версия 46-52)
Если бы я производил рефакторинг вручную и темболее если бы я писал на скриптовом языке, то столь масштабный рефакторин был бы или вообще не возможен, или крайне затруден. Наличие кучи юнит-тестов здесь во-первых скорее помешало бы, так как их сами пришлось бы переписывать, а во-вторых было бы довольно бессмысленно, так как речь идет о динамике ГУИ и тесты сделать крайне не просто.

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

Что же мне позволило это сделать? Две вещи. Автоматизированный рефакторинг, и дизайнер классов. Без них бы я просто не решился на столь масштабные изменения или делал бы их очень долго.

E> Далеко не факт, что это изменение потребует рефакторинга. Так же не факт, что подобные изменения не будут выявлены при предварительном проектировании.

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

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

Никто не говорит о том, что не надо думать. Я веду речь о том, что объем информации которую мне нужно держать в голове и которую нужно отслеживать значительно меньше за счет применения средств автоматизации.

E>И еще, я пользуюсь gvim -- это далеко не Notepad

Это не имеет значения. Главное, что ты занимашся закатом солнца вручную и твоя эффективность во много раз ниже.

E>Главное, что это не осознает мой работодатель.

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

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

E>Тем не менее, есть и другие системы (черные ящики, которые с пользователем не работают, а выполняю свою задачу). Из того, что лично я делал, вот пример

Автор: eao197
Дата: 24.01.05

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

Без разницы. Для тебя инструментом продумывания является бумажка, для меня код. Вот и всё. Только я результат уже вижу, а ты о нём только догадываешься.

E>Досканально действительно не получается. Но я замечал другое -- измения, как правило затрагивают одну или несколько подсистем, а не весь проект. Поэтому они не такие масштабные, как кажется.

Тогда тем более о чём мы спорим.

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

Это тоже всё без разницы. Я занимался и гуями, и серверами, и базами данными, разными вебами, включая rsdn'ами, компиляторами, визуальными редакторами ресурсов, библиотеками и прочими BLToolkit'ами. Большой разницы в подходах к проектированию не заметил.

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

IT>Тогда тем более о чём мы спорим.




А разве мы спорим? Я думал мы просто впечатлениями о собственном стиле работы обменивамся.

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

IT>Я, с некоторых пор, первый. Сажусь и начинаю писать код

Проблема в том, что все кому мы тут что-то пытаемся объяснить просто не могут поверить в описываемые прицыпы. Они привыкли, что это невозможно. Отсюда им кажется многое не вероятным.

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

Так что похоже все эти попытки бесполезны. Вот Паша у нас до сих пор придумывает себе аутотренинг на тему "почему мне не нравится C#". Это все потому, что он подсознательно понимает, что не прав, но боится себе в этом признаться. Вот и ищет оправдания чтобы бороться со своими внутренними страхами. Вот Вольфхаунд попробовл новый путь и уже от него что-то не слышно огульного отрицаиня. Так что тут важен личный опыт. Без него они останутся теми самыми программистами на Абапе которые смотрят на мир с более низкоуровневой позиции и просто не в силах оценить смысл более высокоуровневых технологий.

Вот такая получается фрэйдистская фигня.

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

E>Дык в том-то и дело, что 200k никогда и не требуется изменять. Обычно дело 1k-2k ограничивается. А на таких объемах можно и ручками обойтись (особенно, если вот так

Автор: eao197
Дата: 25.01.06

). Нужно только понять, какую именно тысячу строк выбросить

Измерил объем файлов исправленных мной (между делом) в проекте Rsdn.Editor за последнюю неделю. Получилось 30 файлов общим объемом 455 килобайт. Вот их список:

\Rsdn.Editor.Test\MainForm.cs
\Rsdn.Editor.Test\MainForm.Designer.cs
\Rsdn.Editor\Formatter\breakline.cs
\Rsdn.Editor\Formatter\DefaultStyler\RsdnStyler.cs
\Rsdn.Editor\ObjectModel\Edit.cs
\Rsdn.Editor\ObjectModel\Row\Row.cs
\Rsdn.Editor\ObjectModel\Styles\CombinedStyle.cs
\Rsdn.Editor\ObjectModel\Styles\CompleteStyle.cs
\Rsdn.Editor\ObjectModel\Styles\SimpleStyle.cs
\Rsdn.Editor\ObjectModel\Styles\Style.cs
\Rsdn.Editor\ObjectModel\Styles\StyledRange.cs
\Rsdn.Editor\ObjectModel\View\IView.cs
\Rsdn.Editor\ObjectModel\View\iviewowner.cs
\Rsdn.Editor\ObjectModel\View\PaintInfo.cs
\Rsdn.Editor\ObjectModel\View\view.displayrowscalculations.cs
\Rsdn.Editor\ObjectModel\View\View.Paint.cs
\Rsdn.Editor\ObjectModel\View\view.properties.cs
\Rsdn.Editor\ObjectModel\View\View.State.cs
\Rsdn.Editor\ObjectModel\View\View.Translate.cs
\Rsdn.Editor\Utils\RsdnGraphics\DoubleBuffering.cs
\Rsdn.Editor\Utils\RsdnGraphics\FontEx\CompleteFont.cs
\Rsdn.Editor\Utils\RsdnGraphics\FontEx\FontEx.cs
\Rsdn.Editor\Utils\RsdnGraphics\FontEx\FontExComparer.cs
\Rsdn.Editor\Utils\RsdnGraphics\FontEx\FontExField.cs
\Rsdn.Editor\Utils\RsdnGraphics\FontEx\FontHelper.cs
\Rsdn.Editor\Utils\RsdnGraphics\FontEx\IFont.cs
\Rsdn.Editor\Utils\RsdnGraphics\FontEx\ZoomedFont.cs
\Rsdn.Editor\Utils\RsdnGraphics\RsdnGraphics.cs
\Rsdn.Editor\Utils\utils.cs

Можно махать, что называется "не глядя" 500 кил исходников и получать очень даже работающее приложение причем без юнит-тестов и даже без серьезной отладки. 99% ошибок или не делается вовсе, или устраняются на стадии компиляции.

Можешь не верить в это, но это факт подтвержденный нашим SVN-ом.