Здравствуйте, WolfHound, Вы писали:
IT>>Круто! И почему эту крутизну нужно писать неделями не компилируя? WH>Тут есть две причины: WH>1) Основное время занимала медитация над всем этим делом. WH>2) Держать в согласованном состоянии куски системы которая находится в стадии активного медетирования накладно. Отвлекает от медитации.
Так ты код писал без компиляции или медитировал без компиляции?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>Неважно рисовать — не рисовать, главное начинать с прототипов. Продумать интерфейсы, потом мясо. WH>Вот прототип две недели и занял. Ибо продумать нужно было очень много. И основное время уходило не столько на сам код сколько на медетацию над ним.
АХ>>Я бы использовал Mock Objects. WH>Ну и зачем на эту фигню отвлекатся?
чтобы скорее получить тесты
АХ>>Ну и слишком большая зависимость между классами и методами — тоже плохо. WH>Зависимость то не большая. Да и кода в конце концов получилось не много но вот только написать такие вещи с ходу не получается...
АХ>>Я думаю, что разумнее добавлять функциональность инкрементально. WH>Дык функциональности то не много... вот только сложная она...
Это другое дело. Ты в основном не программировал, а архитектурой занимался.
Так что не совсем корректно говорить "две недели писал не компилируя".
Скорее "две недели думал, не компилируя" .
Здравствуйте, eao197, Вы писали:
E>Так что может сложиться впечатление, что интерес Sun-а в Jython, JRuby, Groovy в том, что уж если народ начнет отворачиваться от Java в пользу скриптовых языков, так пусть делают это на платформе JVM
По-моему это очевидно (то же самое для MS с .NET и IronPython, RubyCLR, а теперь
IT>Т.е. если дробить задачу на более мелкие части, то проблем не будет. Уже теплее Тогда ещё вопрос. Почему у тебя на форте получается, а на классах не получается писать задачу более мелкими кусочками? В чём проблема?
В декомпозиции задач по по прикладным классам, ИМХО. Разработать готовую взаимодейтсвующую систему классов сложнее, но пользоваться и развивать потом — легче. В любой классике ООП говорится, что ОО-подход требует гораздо больше времени на начальном этапе, но дает бенефиты в плане понимания устройства и работы прикладных сущностей.
И дело не только в уровне декомпозиции. Дело еще в организации труда. В С++, даже если создать класс — это вызвать по правой кнопке мыши пункт меню New->Class, то это потом все-равно надо решать, насколько он должен быть виден вне проекта, а не стоит ли его тут же разбить еще на пару классов — одну часть для внутренних задач, доступ к которым не хочется открывать, и другую часть — общедоступную. А общедоступную надо вынести в другой файл, который должен лежать в другом месте (возимся пару мин с файлами вне студии — через файл-менеджеры), потом надо добавить этот файл в проект в другой подпапке проекта (а они независимы от структуры файловой системы, если помнишь) потом везде надо не забыть проставить инклюды, а в h-файлах придумать уникальные макро-имена для классичесского #ifdef SOME_HEADER_INCLUDED, включить в свою очередь кучу инклюдов во вновь созданные файлы и т.д. и т.п.
В результате, я обычно не отрывался от написания текущего метода текущего класса, чтобы банально не рассеивать свое внимание на эту пургу организационного плана.
В C# намного легче, публичная видимость не зависит от расположения файла, зачастую и делить ничего не надо, да еще решарпер сам заглушки создает, т.е. разрабатывая методы неких классов мы как бы автоматически создаем ТЗ для функциональности других. К тому же решарпер показывает ошибки и без компиляции. Потом все это компилируется без ошибок, разумеется.
Здравствуйте, vdimas, Вы писали:
V>Ничью квалификацию я обсуждать не собираюсь, тем более, что сейчас разделов IT в котором можно быть квалифицированным вагон и маленькая тележка.
Однако безосновательно пытаешься обобщить свой опыт в своих конкретных разделах на все задачи вобще. Я такого делать не пытаюсь. Я вполне допускаю, что такие задачи есть (более того, сам иногда сталкиваюсь). Но точно так же знаю, что есть масса задач, где от интерактивности и возможности быстро запустить микросниппеты пользы практически нет.
V> Просто считаю, что осознанный выбор можно сделать только потратив очень много времени на предметы сравнения. Много — это до появления устоявшихся привычек.
Ну вот, опять. Не надо делать предположения, что я знаю, а что нет. Это никакого отношения к конструктивной части диалога не имеет.
AVK>>Отладка требуется обычно в таких ситуациях, когда скриптовое окошко помочь неспособно.
V>Это окошко может помочь быстро воссоздавать сложные отладочные ситуации.
В любых случаях? Опять ты пытаешься спроецировать свои конкретные задачи на все.
V> В общем, отладочное окно — это нормальный такой полезный инструмент.
Отладочное окно как таковое было в куче продуктов бог знает когда.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, FR, Вы писали:
FR>>Я конечно понимаю что вы с vdimas монстры, но все равно мне очень тяжело представить что именно можно в течени двух недель без компиляции вколачивать, может подкинете примерчики?
V>У меня такое было во время разработки GUI-библиотеки на основе MFC. Нужен был ремотинг для С++, + простой с т.з. программиста биндинг для физуальных форм + простая с т.з. программиста валидация и т.д. Там туча взаимодейтсвующих типов, протоколов, сценариев и т.д. Один дата-грид с кучей типов колонок и для него дата-соурс чего стоили.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, IT, Вы писали:
IT>>И не говори. Я без компиляции и трёх строчек не напишу Оно у меня фактически вместо кнопки Save, а сохраняюсь я часто. WH>Давно писал на С++ под линух через SSH? Ну ладно пишу я в студии через самбу но компилить всеравно нужно через SSH.
Да ну, проще или cygwin или вообще VirtualPC.
Уже отлаженное на этом потом компилировать удаленно.
Здравствуйте, vdimas, Вы писали:
V>Любые места, где надо не просто что-то раздизайнить, а накидать кучу алгоритмов, выигрывают.
Ну, вот простой пример. Есть у меня среда (IDE) которая предоставляет кучу фукнций и пишу я к ней некий код. Пока среда не перейдет в некое состояние "играться" с ней просто не выйдет. Никакие игря непомогут. Если есть хоят бы юнит-тесты, в них можно реализовать эмуляцию поведения IDE. И то это очень не просто. А уж о том, чтобы просто где-то в интерпретаторе получить все это и речи не идет.
Все это как-то плохо сходится с твоими утверждениями.
V>Сейчас для "игр" и исследования/сравнения технологий/библиотек мы используем NUnit, но это все суррогат и лишние приседания.
А что не сурогат? Объясни, плиз.
V> Просто одно время сидел на Fort-е, после этого прекрасно понимаю смолтокеров, которые не нахвалят свой язык, хотя хвалить надо среду разработки и принятый подход, если быть объективным (просто технология языка позволяет легко организовать подбный подход).
Подобный подход в примитивных случаях организуется созданием банальных консольных тестовых приложений. Вот только АВК прав. Не во всех случаях это приемлемо.
V> В общем, написал метод, поиграл с ним вдоволь тут же, отладил, пошел дальше и забыл навсегда — это надо прочувствовать.
Я это чувствовал всегда. И когда писал на С++ и когда писал на C# и когда писал на чем нибудь еще. Так что не надо тут выделять что-то особенное. Плюсы по причине томознутости процесса компиляции конечно могут выделиться. Но тоже не факт.
V> Такой скорости разработки качественного кода в компилируемых средах не получается,
Откровенно ошибочное утвержднеие. Как раз качество кода нереально получить в интерпретаторах. Вместо того чтобы получить большинство ошибко еще на стадии компиляции ты вынужден вылавливать их делая тучу (для качественно компилируемых языов) ненужных тестов.
Вот только что писал алгоритм выделения диапазона текста по координатам задающимся в виде двух координат каждая из которых состоит из строки и символа. Компилятор (правда надо заметить, что это Nemerle с просто паронаидальноми проверками) отловил 99% ошибок еще на стадии компиляции. Причем отловленные ошибки это далеко не только опечатки. Он отловил 10 штук логических ошибок (выдавая предупреждения). Оставшыеся пару ошибок я доловил отладчиком запущенным на тех самых юнит-тестах.
Ну, и что я получил бы в этом случае от интерпретатора? Мой ответ — только проблемы и тормоза.
Единственно что мне мешало при этом — это качество отладки. Для Nemerle оно пока что оставляет желать лучшего (потом исправим). Для C# таких проблем нет.
V> не взирая ни на какой опыт.
Ну, ну. Это вообще очень чрезвычайно самоуверенное утверждение. Нехочу ничего говорить о твоем личном опыте. Но я сто раз наблюдал как дни ти те же проблемы решают умелые и одаренные люди и новички и бездари. Это земля и небо. Причем не взирая на используемые средства и технологии.
V> Например на С++ я мог неделями только писать код даже не компилируя (если участвует большая система взаимодействующих типов).
Очень тебе сочувствую. Лично я считаю, что объем кодирования без компиляции определяется только одинм факторм — качеством разбиения задачи на подзадачи. Если задача описана как огромный монолит, то конечно можно неделю писать ее без возмоности скомпилироваться и отладиться. А если подумать головой, то все обычно разбивается на вполне миниатюрные подзадачи для каждой из кторых можно сделать краткий цикл написание/комиляция/отладка.
V> В C# этот срок сократился,
Скажи чеснее — почти не олтичается от скриптов. Особенно если учесть что в окне Immidiate можно без проблем отладить отедьную функцию. И единственное что лично меня останавливает от этого — это то, что большинство функций требуют некого инициализирвоанного окружения. А его проще создать в запущенном приложении или юнит-тестах.
V> но похожие преценденты были, т.е. несколько дней писанины без отладки.
Опять же — это твои личные проблемы. Я никогда не писал код дольше нескольких частов.
V>Самое сложное в нашей работе — это не технически сложности (говорю о себе). Самое сложное, от чего можно потерять интерес к концу дня — это многократное переключение внимания на абсолютно несвязанные вещи.
А я почему-то единственно сложным считаю именно те самые технические сложности. Самой болшой проблемой для меня является высокий уровень косвенности и наложения множества абстракций. А вот возвращаться к пдоробностям мне проблемы не составляет.
Может дело в выбранных подходах?
V> Чем лучше сосредоточишься, т.е. чем больше попытаешься удержать в голове прямо или косвенно связанных моментов относительно целевого, тем качествене получится итоговый код и меньше вероятность, что потом опять к этому участку вернешься.
Хм. А я как раз придерживаюсь ровно обратного мнения. Чем меньше в голове тем качесвтеннее результат.
V> Это не проблема до тех пор, пока в течении дня не приходится сосредотачиваться на десятках несвязанных моментов, прыгая по ним аки кенгуру.
Прыгать вообще плохо. Я вот по роду работы (не программиской) все время переключаюсь. И знаю, что это очень сильно выматывает психологически. Так что программист вообще по-моему просто обязан планировать свою работу и ни в коем случае не прыгать от задачи к задаче.
V> А в случае итеративной разработки-отладки ты сосредотачиваешься на одной мини-задачке, решаешь ее так, чтобы потом никогда к ней не возвращатья. От того и скорость и качество.
По мне так процесс разработки и есть переход от одной маленькой (относительно конечно) задачи к другой. Но вот "никогда к ней не возвращатья" это коенчо ерунда. Наоборот надо четко понимать, что вероятность возрвата к задаче очень велика. Ведь принятое проектное решение может быть изменено. Да и ошибки еще никто не отменял. Наоброт нужно уметь выбрасывать код. Не держаться за него. Сегодня написали так. Завтро перерефакторили по другому. Это нормально!
V>И еще. Непередаваемое чувство уверенности в результате своего труда, если был возможен описанный подход.
Невероятня самоуверенность в следствии самовнушения. Вот что это такое. Как раз пукть скриптов — это путь к люкодрому. Путь когда никогда нельзя гарантировать что вся программа работает.
V> Не буду описывать эмоции — не поэт. Но включаешь, а оно работает, и так работает и эдак работает, как часы.
Пока не упадет.
V>------------- V>Заметил. Почти всегда, если язык и технология позволяет, в среды разработки обязательно вставляют итерактивные возможности. Случайно?
Если ххх позволяет, то бывает что встраивают:
1. Рефактринг.
2. Юнит-тестирование.
3. Отладку.
4. ... подставить по вкусу.
Возможность интерактивно отладки из среды это коенчо же не плохо. Но реальной потребнсти лично я в ней не испытываю. Вот в C# и VB она есть, но я предпочитают банальную отладку.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Дудки, у всех кто пробовал оба подхода на серьезных задачах. Fort, Smalltalk, Lisp и даже MS Access и т.д. — это все одного поля ягоды, многие спецы и фанаты этих сред являются прекрасными спецами по различным мейнстримовым джавам, С++ или C#.
Ага. Творчество таких "спетцов" уже достало. Когда формочки могут в самом непредсказуемом месте вывалиться без объявления войны.
На фиг, на фиг. А уж спецы по MS Access это вообще практически синоним ламеров.
V> Люди думают, что они являются фанатами языков/технологий, на самом деле они являются фанатами контроллируемого процесса кодирования.
Не контролируемого если быть более точным. Просто у них создается иллюзия работоспособности отнюдь не работоспособного софта.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Я конечно понимаю что вы с vdimas монстры, но все равно мне очень тяжело представить что именно можно в течени двух недель без компиляции вколачивать, может подкинете примерчики?
Огромный монолитный алгоритм.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Пара недель — это потому что по задумке участвует много типов и у них много методов. И вся эта кухня взаимодействует.
Я понимаю почему такой фигней занимаетс Вольфахун. У него враждебная среда — SSH с Линуксом. Проще один раз усилием воли сформировать все, а потом разбираться. Но в люом деле всегда можно выделить под дела. И сначала отладить их. Пусть на юнит-тестах. Пусть не польностью. Но все же.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>И почему тогда не было бы проблем на Форте? Или там типов меньше и они не взаимодействуют?
А ты что-то серьезное на Форте видел?
Я вот тоже когда пишу консольные тесты, то особо не страдают от монументальности кода.
А вот когда берусь за ту же интеграцию со студией, то проблемы возинкают. Ведь чтобы сделать А нужно сделать Б, а для б нужно В и так далее. Приходится подумать головй как же все таки сделать так чтобы хотя бы В написать и отладить по отдельности. Ну, а многим влом думать. Проще залудить все сразу. Две недели колбасит код, а потом еще месяц от этого кода колсбасит его и окружающих.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gajdalager, Вы писали:
G>Ну... А это?... Правда, макросов нет и хорошей IDE....
Скала идеологически перспективна. Но ее авторы что называется теоретики. Руки у них далеко не те что у немерловцев. Так что лично я ставлю на Немерле. Плюс к тому же дотнет мне в принципе больше нравится. Да и скорость работы получаемого кода несравнимо выше у Немрла.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Но точно так же знаю, что есть масса задач, где от интерактивности и возможности быстро запустить микросниппеты пользы практически нет.
Например? Учитывая что микросниппет может вызывать вещи произвольно высокого или низкого уровня.
AVK>Ну вот, опять. Не надо делать предположения, что я знаю, а что нет. Это никакого отношения к конструктивной части диалога не имеет.
Если собеседник занимает позицию загадочного незнакомца на пятый год участия в этом форуме, то приходится делать предположения. По крайней мере я эти предположения делаю в вопросительной форме, а не утвердительной. Ответа так и не услышал.
V>>Это окошко может помочь быстро воссоздавать сложные отладочные ситуации.
AVK>В любых случаях? Опять ты пытаешься спроецировать свои конкретные задачи на все.
Ну как сказать, когда речь о тысячах задач/подзадач, то назвать их конкретными рука не поднимается. В общем, мне все же интересно, где отладочное окно не способно воссоздать отладочную ситуацию? (интересный факт: у нас тестирование сервера производится с клиента, т.е. большинство автоматизированных тестов — со стороны клиента)
AVK>Отладочное окно как таковое было в куче продуктов бог знает когда.
Здравствуйте, FR, Вы писали:
V>>У меня такое было во время разработки GUI-библиотеки на основе MFC. Нужен был ремотинг для С++, + простой с т.з. программиста биндинг для физуальных форм + простая с т.з. программиста валидация и т.д. Там туча взаимодейтсвующих типов, протоколов, сценариев и т.д. Один дата-грид с кучей типов колонок и для него дата-соурс чего стоили.
FR>А не проще было через кодогенерацию?
Тут эта, такой проект есть "виртуал грид". Им только грид надо сделать, все остальные биндинг-прелести уже есть в дотнете. Ты бы им предложил кодогенерацию, чтобы проект сам писался, а то они чегой-то встряли годик назад.
Здравствуйте, VladD2, Вы писали:
V>>Пара недель — это потому что по задумке участвует много типов и у них много методов. И вся эта кухня взаимодействует.
VD>Я понимаю почему такой фигней занимаетс Вольфахун. У него враждебная среда — SSH с Линуксом. Проще один раз усилием воли сформировать все, а потом разбираться. Но в люом деле всегда можно выделить под дела. И сначала отладить их. Пусть на юнит-тестах. Пусть не польностью. Но все же.
Ну возьми в дотнете дата-биндинг, компонентную модель, тайп/проперти/евент/дескрипторы/конвертеры и сделай пол-дела чтобы все это совместно закрутилось. Там одного пол-дела на месяцы проектирования.
Ты думаешь, что спустя эти две недели я сделал целых пол-дела? Ага блин, если бы... Первая версия была лишь для одного типа данных текстового, и соответственно только одного обычного edit-контрола и одного текстового типа колонки. (Это же С++, не забывай, хрен порефакторишь, так что разрабатывал сразу на 2 направления, дабы получить универсальную сущность — источник данных, подходящий для гридов и для форм).
Тем более, что у меня не было перед глазами стройной системы для подражания, мне лишь нравилось удобство биндинга данных в VB, и хотелось для своего проекта сделать так же удобно для разработчиков прикладных форм. (А интерфейсы и алгоритмы среды VB6.0 в рефлекторе не посмотришь )
И вообще, это было в районе 2000-го года, еще буста толком не было и некое окружение всей этой кухни тоже писать пришлось, что добавило общего времени, ибо вся эта кухня писалась методом спуска сверху, ибо не было цели разработать окружение ради окружения.
V>>Любые места, где надо не просто что-то раздизайнить, а накидать кучу алгоритмов, выигрывают.
VD>Ну, вот простой пример. Есть у меня среда (IDE) которая предоставляет кучу фукнций и пишу я к ней некий код. Пока среда не перейдет в некое состояние "играться" с ней просто не выйдет. Никакие игря непомогут. Если есть хоят бы юнит-тесты, в них можно реализовать эмуляцию поведения IDE. И то это очень не просто. А уж о том, чтобы просто где-то в интерпретаторе получить все это и речи не идет.
VD>Все это как-то плохо сходится с твоими утверждениями.
Ну ты же можешь в качестве дебаг-таргета запустить среду. Поставить где-нить у себя брейк-поинт, получить рутовый инстанс чего-нить, и играй наздоровье. Хотя согласен, VS-unmanaged приложение, поэтому сложности.
Но если стоит, например, задача поиграть с разработкой своих дизайнеров, то можно использовать SharpDevelop, он полностью поддерживает все сервисы, нужные для разработки и отладки дизайнеров типов.
VD>А что не сурогат? Объясни, плиз.
Иногда я создаю "временные" тесты, нужные только для того, чтобы несколько раз прогнать какой-либо участок кода в процессе отладки, или поиграть с каким-либо окружением. По-сути, это даже не тест, а способ запуска необходимого участка кода.
V>> Просто одно время сидел на Fort-е, после этого прекрасно понимаю смолтокеров, которые не нахвалят свой язык, хотя хвалить надо среду разработки и принятый подход, если быть объективным (просто технология языка позволяет легко организовать подбный подход).
VD>Подобный подход в примитивных случаях организуется созданием банальных консольных тестовых приложений. Вот только АВК прав. Не во всех случаях это приемлемо.
Вообще-то GUI IDE для смалтолков, писанные на смолтолке, раньше (до JIDEA/Решарпера) считались самыми удобными.
VD>Вот только что писал алгоритм выделения диапазона текста по координатам задающимся в виде двух координат каждая из которых состоит из строки и символа. Компилятор (правда надо заметить, что это Nemerle с просто паронаидальноми проверками) отловил 99% ошибок еще на стадии компиляции.
В дробях я не силен, но чтобы получить 99% отлова, надо как минимум 100 ошибок иметь.
VD>Ну, и что я получил бы в этом случае от интерпретатора? Мой ответ — только проблемы и тормоза.
Я тоже потихонечку разучиваюсь писать без решарпера. Вон знакомому студенту недавно в Turbo C помогал с лабой, блин, давлю на знакомые кнопки — а код сам не пишется, просто ступор...
VD>Ну, ну. Это вообще очень чрезвычайно самоуверенное утверждение. Нехочу ничего говорить о твоем личном опыте. Но я сто раз наблюдал как дни ти те же проблемы решают умелые и одаренные люди и новички и бездари. Это земля и небо. Причем не взирая на используемые средства и технологии.
Поверь, кучи ошибок и ляпов делают даже самые одаренные спецы. Просто характер ляпов отличается от оных у бездарей. Еще на порядки отличается время, необходимое на понимание и исправление причин ошибок. Ускорение о котором я говорил, не зависит от квалификации, в том смысле, что ускорение получают все — каждый в меру своей квалификации.
И замечание насчет компиллируемости. В MS Access, например, тоже требуется компиллируемость класса для использования. Т.е., если класс не используется — не требуется его безошибочная компиллируемость. Если используется, т.е. написал в окошке отладки set a = new SomeClass, то выдается ошибка, открывается этот файл и ты можешь исправлять код класса, пока он не скомпиллируется, потом без потери вернешься к своему окошку и продолжишь далее. Весьма дружественно, должен заметить. А возможность во время останова вообще хрена дописать в класс и потом продолжить — вообще без комментария. На одних только переходах из дебага в написание экономишь по часу и более в день суммарно. Хотя, если у тебя 2 гига памяти, то пара открытых студий с решарперами тебя не напрягут и так, а вот меня напрягают временем перехода из одного состояния в другое.
VD>Очень тебе сочувствую. Лично я считаю, что объем кодирования без компиляции определяется только одинм факторм — качеством разбиения задачи на подзадачи. Если задача описана как огромный монолит, то конечно можно неделю писать ее без возмоности скомпилироваться и отладиться. А если подумать головой, то все обычно разбивается на вполне миниатюрные подзадачи для каждой из кторых можно сделать краткий цикл написание/комиляция/отладка.
Краткий цикл можно сделать, до компилируемости, например. Но смысл какой бросаться искать мух и сбивать себя с мысли, если все-равно отладить пока не получится? Я в другом посте привел пример с системой дата биндинга, дизайнеров, тайп/проперти/евент дескрипторов/конвертеров и соответсвующих служб и провайдеров. Эта система работает совместно, там нечего отлаживать без остальных частей, тем более в период разработки.
Считай, что я кодировал одновременно с дизайном подобной кухни. И у меня не было образца перед глазами. Как ТЗ шло именно представление кода, ведь цель была — предоставить удобную систему для использования в коде. Вот от внешнего представления в коде и отталкивался, к тому же завязывался на MFC.
V>> Чем лучше сосредоточишься, т.е. чем больше попытаешься удержать в голове прямо или косвенно связанных моментов относительно целевого, тем качествене получится итоговый код и меньше вероятность, что потом опять к этому участку вернешься.
VD>Хм. А я как раз придерживаюсь ровно обратного мнения. Чем меньше в голове тем качесвтеннее результат.
Это если удается избегать побочных эффектов. Я когда с ремотингом, управлением веременем жизни и транзакциями возился на серверной стороне, то побочных эффектов наелся нехочу. Чем меньше в голове было на момент написания, тем больше пришлось править потом.
V>> Это не проблема до тех пор, пока в течении дня не приходится сосредотачиваться на десятках несвязанных моментов, прыгая по ним аки кенгуру.
VD>Прыгать вообще плохо. Я вот по роду работы (не программиской) все время переключаюсь. И знаю, что это очень сильно выматывает психологически. Так что программист вообще по-моему просто обязан планировать свою работу и ни в коем случае не прыгать от задачи к задаче.
При чем тут планирование? При разработке и отладке одной из вещей понимаешь, что ошибка в другой зависимой. Прыгаешь как кенгуру на зависимую ибо без нее некуда дальше двигаться. Я об этом.
V>> А в случае итеративной разработки-отладки ты сосредотачиваешься на одной мини-задачке, решаешь ее так, чтобы потом никогда к ней не возвращатья. От того и скорость и качество.
VD>По мне так процесс разработки и есть переход от одной маленькой (относительно конечно) задачи к другой. Но вот "никогда к ней не возвращатья" это коенчо ерунда. Наоборот надо четко понимать, что вероятность возрвата к задаче очень велика. Ведь принятое проектное решение может быть изменено. Да и ошибки еще никто не отменял. Наоброт нужно уметь выбрасывать код. Не держаться за него. Сегодня написали так. Завтро перерефакторили по другому. Это нормально!
Эх Влад, твои бы слова да на хлеб мазать. Когда количество типов идет на сотни и тысячи, то начинаешь повнимательнее относиться к тенденциям, и пофиг становятся конкретные ситуации. Когда надо — код летит в топку не задумываясь, не волнуйся. Но если это становится тенденцией...
V>>И еще. Непередаваемое чувство уверенности в результате своего труда, если был возможен описанный подход.
VD>Невероятня самоуверенность в следствии самовнушения. Вот что это такое. Как раз пукть скриптов — это путь к люкодрому. Путь когда никогда нельзя гарантировать что вся программа работает.
Я на Форте писал, а это гораздо хуже, чем скрипты. Но программы на Форте традиционно самые надежные. Разумеется не из-за св-в языка, а из-за подхода к разработке. К тому же существет невероятно высокий процент декларативного в Форт-программах, из-за возможности создавать определяющие слова, т.е. процент автоматической кодогенерации в реальных программах может сравниться только с лисповой на сегодняшний день... как там немерль, кстати
VD>Возможность интерактивно отладки из среды это коенчо же не плохо. Но реальной потребнсти лично я в ней не испытываю. Вот в C# и VB она есть, но я предпочитают банальную отладку.
В C# можно считать что нету. С возможностями из проекта VB и близко не сравнится (странно, не находишь ).
VD>А вот когда берусь за ту же интеграцию со студией, то проблемы возинкают. Ведь чтобы сделать А нужно сделать Б, а для б нужно В и так далее. Приходится подумать головй как же все таки сделать так чтобы хотя бы В написать и отладить по отдельности. Ну, а многим влом думать. Проще залудить все сразу.
Вот ты зря выделенное пишешь. Это ты такой смелый от возможностей автоматического рефакторинга. Реально на С++ приходилось столько думать, чтобы правильно залудить все сразу, что сейчас на C# мне спинного мозга достаточно, ну максимум мозжечка, в сравнении с теми по-настоящему боевыми временами.
Сейчас в студии с решарпером писанина кода — это курорт и еще раз курорт, и тут не фиг сравнивать.
-----------
Сейчас в системе один из проектов на С++. В принципе — не объемный, да и буст весьма помог. Решили как полагается использовать CppUnit, так теперь дополнительно я всегда думаю как бы это все залудить так, чтобы еще и в CppUnit отлаживать можно было.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, FR, Вы писали:
V>>>У меня такое было во время разработки GUI-библиотеки на основе MFC. Нужен был ремотинг для С++, + простой с т.з. программиста биндинг для физуальных форм + простая с т.з. программиста валидация и т.д. Там туча взаимодейтсвующих типов, протоколов, сценариев и т.д. Один дата-грид с кучей типов колонок и для него дата-соурс чего стоили.
FR>>А не проще было через кодогенерацию?
V>Тут эта, такой проект есть "виртуал грид". Им только грид надо сделать, все остальные биндинг-прелести уже есть в дотнете. Ты бы им предложил кодогенерацию, чтобы проект сам писался, а то они чегой-то встряли годик назад.
Если нам не помогут, то мы тоже никого не пощадим.
.
Оно у меня фактически вместо кнопки Save, а сохраняюсь я часто.
Первая версия была лишь для одного типа данных текстового, и соответственно только одного обычного edit-контрола и одного текстового типа колонки. (Это же С++, не забывай, хрен порефакторишь, так что разрабатывал сразу на 2 направления, дабы получить универсальную сущность — источник данных, подходящий для гридов и для форм).
