Здравствуйте, IT, Вы писали:
IT>Что это даёт? Во-первых, к повторно используемому коду должны предъявляться повышенные требования.
Моя проблема в том, что я предъявляю повышенные требования ко всему коду. И сразу не отходя от кассы. В результате получается что треть проекта пишется как бы с нуля, а остальная треть — это подключение и расширения классов. Никогда не поймешь, понадобится или не понадобится то или иное место во второй раз. А когда оно уже полностью подготовлено к расширению, то где-то через треть проекта начинаешь пользоваться готовыми конструкциями, которые и уже не нужно продумывать.
Здравствуйте, Павел Кузнецов, Вы писали:
GZ>>Хотелось бы намекнуть, что рефакторинг — это улучшение кода не влияя на функциональность. И он мало зависит от процесса разработки. Просто в ХП она обязательная дисциплина.
ПК>XP не отвергает выделенного этапа проектирования и планирования, и даже наоборот, в классике предполагает наличие в начале каждой итерации выделенное планирование, iteration planning meeting, и выделенный этап проектирования, основанный на использовании CRC Cards.
Проектирование и планирование совершенно различается у жестких и мягких процессов программирования(я имею ввиду RUP и XP). В XP нет ничего постоянного. Ни в планировании, ни тем более в архитектуре. Даже те же CRC карты — это всего лишь некоторые намерения которые вполне могут измениться. ПК>Как мы уже разобрались выше и ранее, режим "постоянного рефакторинга" в трактовке Влада (т.е. произвольные модификации кода с помощью инструментальных средств IDE, обычно без unit tests) принципиально отличается от рефакторинга в трактовке XP, который, действительно, принципиально не изменяет функциональность.
Он собственно сильно отличается и от моего рефакторинга. В отличие от принятых норм в XP, я не выделяю для него время в виде итераций. Он делается постоянно в каждой процедуре, и тесты я делаю после того как написал первую версию того или иного блока.
GZ>>Нет. По случаям глюков могу сказать что ХП дает менее глючный код. <...> ПК>Ну началось... XP и прочие модные итерационные процессы как раз построены по схеме, упомянутой выше (полные, но короткие циклы, включающие в т.ч. (коллективное) планирование и проектирование ближайшей итерации).
Проблема в том, что XP хорошо защищен на предмет изменений(которые в любом случае вносятся). Он защищает от изменений чужих разработчиков. И он защищает те места, которые не определяются функциональными тестами. Которые во многом дебильны и слишком неполны.
ПК>P.S. Интересно, на основании чего ты воспринял метафору "серии маленьких водопадиков" как противоречащую XP и т.п.? Уж не из-за того, что встретил слово "водопадик"?
Ключевым словом здесь было дизайн кода.
PS. Пока писал код, позвонили, узнал что стал уже дважды отцом.
Здравствуйте, Павел Кузнецов, Вы писали:
GZ>> . . . могу сказать что ХП . . . GZ>>Для тестирования и documentation writers в основном полезны прецеденты написанные аналитиками а не архитекторами. ПК>О, кстати, а как XP и выделенные аналитики и архитекторы сочетаются между собой? По моему представлению это вещи, не вполне совместимые...
Архитекторов как таковых нет. А аналитики(или представители клиента) используются в большей степени консультативно. Вобщем хаос управляемый одним человеком обязанности которого только в одном: чтобы друг другу морды не набили. Почти полное отрицания документации влияет и на documentation writers. Я очень сомневаюсь что писатели будут разбирать функциональные тесты. Что касается тестирования, то они предлагают именно автоматизированное тестирование притом сделанная клиентами. Во первых, задолбаешься с граничными условиями разбираться(что я не видел ни одной книжке по XP ). Во вторых, все равно все придется делать с аналитиками. Программисты не всегда хорошие помошники потому как для тестеров они люди заинтересованные, а для техписателей, люди не от мира сего.
Здравствуйте, vitaly_spb, Вы писали:
_>IT, отличный рассказ и я практически со всем согласен. С чем не согласен — проекты бывают разных масштабов и на них меняются разработчики (проект на 2-3 года скажем, люди могут уходить-приходить). Чтобы проект развивался обязательно должны быть зафиксированы структура проекта и т.п., это все забывается, не успевается передать и т.д.
Бывают такие проекты. А бывают ещё и бесконечные проекты. Бывают где взаимодействуют много команд. Но об этом я оговорился выше. Если необходима передача знаний, что наличие проектной документации и спецификаций (особенно на внешние интерфейсы) становится отдельным вопросом. Это с одной стороны. С другой — соревнования по тому, кто больше произведёт бумаги тоже не имеют никакого смысла. Вреда от 150 страниц на модуль, в которых смысл содержит только название и то уже давно устарело, даже больше, чем если бы их вообще не было.
Всегда нужна актуальная схема базы данных (если есть БД), схема объектной модели тоже полезна. Если схема БД близка к объектной модели, то достаточно первой. Описание какой-нибудь общей концепции. Разъяснение неочевидных мест и алгоритмов. Этого в большинстве случаев более чем достаточно и чем меньше бумаги, тем легче поддерживать её в актуальном состоянии.
_>Потом еще бывают ситуации с (мягко говоря) не самыми умными разработчиками, код которых приходится дорабатывать. Например, у меня была ситуация, когда я пришел в проект, половина которого была написана человеком за месяц до увольнения. Можно себе представить что там написал человек, котор. И сколько я промучался разбираясь в его коде (не было проектирования как такового по тому проекту, было только задание: сделать то-то и то-то).
Про одноклеточных лучше никаких аргументов не приводить. Если бы он тебе оставил документация, то, поверь мне, было бы ещё хуже.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[19]: Философический вопрос про автоматический вывод типов
Здравствуйте, vdimas, Вы писали:
V>Не все, а многие, юзающие "удобные" технологии. Что не так? В этом Гена был прав, а акцент-то был в другом: "не получится ли так, что я, как специалист хорошими навыками, перестану выделяться на общем фоне... и если да, зачем мне это надо?".
Если твоя задача выделиться, то у нас разные задачи. Моя задача быть более продуктивным и сделать более продуктивными остальных. Отсюда если для повышения продуктивности нужно перестроиться, то значит нужно перестраиваться.
V>Действительно, представь, что некий экскаваторщик виртуозно владел своим экскаватором и в бригаде экскаваторщиков легко делал, предположим 500% плана. Потом привезли автоматические экскаваторы, где роль экскаваторщика стала заключаться в нажатии кнопки "пуск" утром в начале работы. Разумеется, все его прежние навыки стали ненужны.
Как человек общавшийся с ЧПУ скажу тебе, что влючить кнопку недостаточно. Еще нужно ввести программу и обслуживать станок (менять фрезы, вносить поправки и т.п.). Думаю в твоем гипотетическом эксповаторе тоже будет что-то подобное. Так что место где можно отличиться будет. Надо только вовремя перестроиться. Ну, а уж захочешь ли ты перестроиться или нет — это твои проблемы.
V>Гена утрирует, но что-то в этом есть. Действительно, на многих "популярных" задачах достаточно ныне нажать кнопку "пуск" и все работает само в этом дотнете. Единственно что потребуется изучать — это расположение самой этой кнопки.
Мечат о зеленой факсовой кнопке решающей все задачи так и останется мечтой. Я в этом уверн. Так что не убдем обсуждать эту утопию.
V>Просто настало интересное время, чтобы начать искать себе более интересные задачи, чем всякие технические подробности, которые мы раньше виртуозно решали и которые ныне решать не нужно.
Именно. Причем искать то в общем-то нечего. Все под ногами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Философический вопрос про автоматический вывод типов
Здравствуйте, VladD2, Вы писали:
VD>Если твоя задача выделиться, то у нас разные задачи. Моя задача быть более продуктивным и сделать более продуктивными остальных.
А чем еще, по-твоему, можно выделиться? Именно быть более продуктивным в какой-то области.
VD>Отсюда если для повышения продуктивности нужно перестроиться, то значит нужно перестраиваться.
Пока еще есть рынок С++ приложений и С++ рабочих мест, речь все еще может вестись о повышении продуктивности на нем.
VD>Как человек общавшийся с ЧПУ скажу тебе, что влючить кнопку недостаточно. Еще нужно ввести программу и обслуживать станок (менять фрезы, вносить поправки и т.п.). Думаю в твоем гипотетическом эксповаторе тоже будет что-то подобное. Так что место где можно отличиться будет.
Ты привел очень хороший пример, показывающий, что отличиться будет нечем. Эту несложную работу будут делать все одинаково.
VD>Мечат о зеленой факсовой кнопке решающей все задачи так и останется мечтой. Я в этом уверн. Так что не убдем обсуждать эту утопию.
Да ну почему же? Ты просто привык к тоннам халявного функционала и наверно, не представляешь, как мог обходиться раньше без него. И это действительно — ожившая утопия. Неплохие либы, розничной стоимостью как минимум в многие тысячи баксов, достаются совершенно бесплатно. Ты бы хоть поинтересовался стоимостью либ под те же С++ или Дельфи или что угодно. Там вшивая библиотека контролов от $500. Сначала Sun удивил мир своей бесплатностью, затем ему вторит MS, вернее, даже переплюнул. И ты пытаешься сказать, что утопий не бывает, хе-хе...
V>>Просто настало интересное время, чтобы начать искать себе более интересные задачи, чем всякие технические подробности, которые мы раньше виртуозно решали и которые ныне решать не нужно.
VD>Именно. Причем искать то в общем-то нечего. Все под ногами.
Например? Покажи мне ИНТЕРЕСНЫЕ задачи под дотнет, за которые платят нормальные деньги. Твое "под ногами" — чистой воды утопия и есть. Сейчас деньги платят за... кодирование бизнес-приложений. Можно называть это все громко, типа "бла-бла-разработка N-уровневой распределенной системы", суть не меняется: формочки, отчеты, SQL и некая прослойка м/у ними (громко называющаяся сервером этого бизнес-приложения) которая уже давно не является интересной задачей.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, GlebZ, Вы писали:
GZ>>PS. Пока писал код, позвонили, узнал что стал уже дважды отцом.
IT>Мои поздравления! Мальчик, девочка?
Девочка 3700x51
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, GlebZ, Вы писали: GZ>>PS. Пока писал код, позвонили, узнал что стал уже дважды отцом. S>Двойняшки?
Типун тебе на язык. Второй.
Здравствуйте, AndrewVK, Вы писали:
AVK>use cases это здорово и круто, когда исходные требования заранее известны. А на практике это частенько не так.
Для этого сейчас и отделяют аналитиков от проектировщиков, чтобы путаницы не было
Если четких требований нет, то их необходимо изобрести, предложить... Причем конечный набор этих требований должен диктоваться лишь полезностью для заказчика (или нишевого пользователя), а не выводиться из экспериментов программиста как результат рефакторинга кода. Последнее работает только для каких-нибудь вещей, типа неординарных/исследовательских проектов, чаще всего из области разработки инструментария (то бишь системного софта/библиотек).
V>>Признайтесь, вы все часто используете пошаговую отладку на дотнете...
AVK>Правда есть одна область, где действительно приходится отладчиком часто пользоваться — при разработке расширения студии. Только вот проблема при этом не в дотнете, а в крайней убогости документации.
В принципе, по большинству прикладных классов документация не ахти. Не так уж много публичных классов имеют развернутую доку, с опсианием целей и задач этого класса, его взаимодействия с другими и т.д. Но это никак не мешает пользоваться остальными, где такой доки нет. Потому что есть внятные именования типов и методов. А для студии да, IServiceProvider и подобные ему — как голый QueryInterface в COM, аналог черной дыры в космосе.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[17]: Философический вопрос про автоматический вывод типов
Здравствуйте, vdimas, Вы писали:
V>Если четких требований нет, то их необходимо изобрести, предложить...
Зачем? Чтобы лишнюю работу сделать?
V> Причем конечный набор этих требований должен диктоваться лишь полезностью для заказчика (или нишевого пользователя), а не выводиться из экспериментов программиста как результат рефакторинга кода.
Это эксперименты не только программиста. В них заказчик тоже участвует.
V> Последнее работает только для каких-нибудь вещей, типа неординарных/исследовательских проектов, чаще всего из области разработки инструментария (то бишь системного софта/библиотек).
Последнее работает даже на самых рядовых проектах, проверено.
AVK>>Правда есть одна область, где действительно приходится отладчиком часто пользоваться — при разработке расширения студии. Только вот проблема при этом не в дотнете, а в крайней убогости документации.
V>В принципе, по большинству прикладных классов документация не ахти.
В случае .NET документация по фреймворку на 2 головы выше. Кроме того фреймворк всегда можно декомпилировать.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ещё раз: проектирование как раз и предполагает, что большая часть трудностей будет выловлена на его этапе.
Цель грамотного проектирования — создать архитектуру, которая позволит легко (относительно) исправить любые вероятные проблемы, которые могут появиться в дальнейшем. Под проблемами я здесь понимаю непонимание требований к системе (со стороны программистов иил самого заказчика), изменение требований к системе (по объективным причинам, или просто по капризу заказчика), несовершенство используемых средств, лицензионные проблемы и т.п.
Проектирование, которое решает все проблемы до их появления — это из области фантастики. Любые реальные проблемы, которые возникают во время развития проекта, предсказать просто невозможно. Потому что техника гадания на кофейной гуще еще очень далека от промышленного применения
Максимум, что можно сделать — это составить список вероятных проблем, и подготовить почву для их решения, когда какие-то из них станут реальностью. Это и есть сверхзадача грамотного проектирования. Мастерство же архитектора состоит в основном в умении грамотно расставить приоритеты грядущих проблем, и в умении спроектировать систему в соответствии с этими приоритетами.
То же самое касается и вопроса скорости будущего продукта. Грамотный архитектор должен всегда закладывать возможность увеличить скорость работы — с помощью кэширования, распределения нагрузки, переписывания некоторых модулей на язык более низкого уровня (именно так, этот пункт — на последнем месте). НО! Если архитектор на этапе проектирования говорит "мы будем использовать здесь X, чтобы увеличить скорость" — за шиворот его, и отправлять гальюны чистить. Зубной щеткой. Потому что правильное высказывание должно звучать так: "Мы сделаем Y, чтобы иметь возможность увеличить скорость потом, если это понадобится"
ЗЫ желающие расставить минусы — в очередь!
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[17]: Философический вопрос про автоматический вывод типов
Здравствуйте, vdimas, Вы писали: V>Для этого сейчас и отделяют аналитиков от проектировщиков, чтобы путаницы не было V>Если четких требований нет, то их необходимо изобрести, предложить... Причем конечный набор этих требований должен диктоваться лишь полезностью для заказчика (или нишевого пользователя), а не выводиться из экспериментов программиста как результат рефакторинга кода. Последнее работает только для каких-нибудь вещей, типа неординарных/исследовательских проектов, чаще всего из области разработки инструментария (то бишь системного софта/библиотек).
Можно я эту цитату на стенку повешу?
( Для напоминания кое-кому из коллег... )
Что касается тестирования, то они предлагают именно автоматизированное тестирование притом сделанная клиентами. Во первых, задолбаешься с граничными условиями разбираться(что я не видел ни одной книжке по XP 
). Во вторых, все равно все придется делать с аналитиками. Программисты не всегда хорошие помошники потому как для тестеров они люди заинтересованные, а для техписателей, люди не от мира сего.
Если нам не помогут, то мы тоже никого не пощадим.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
1.1.4 stable rev. 510
