Здравствуйте, PhantomIvan, Вы писали:
M>>кратко — цепочка (архитектор-программист-тестер) длиннее чем (программист) или (архитектор-программист). Поэтому рискну дать "совет космического масштаба" и возможно "космической же глупости". При возможности, цепочку общения необходимо сокращать.
PI>в огромных проектах там из архитекторов цепочка, потом из программеров цепочка, тестеры сбоку и т.п. PI>нужно не цепочки сокращать, нужно, по мнению Брукса, четче разделение функций между специалистами проводить
Разделение функций можно проводить по разному. Можно горизонтально — когда вся задача разбивается, например, на UI, DB и бизнеслогику. А можно веритикально — по функционалу. Тебе какой больше нравится?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, FR, Вы писали:
FR>Бумага по моему тоже лишнее.
Да, это основная моя мысль
FR> Но в случае если надо разбиратся с большим количеством чужого кода то IDE по моему тоже не лучший вариант.
Смотря с какими возможностями (см. ниже)
FR> Лично для меня самое удобное это сгенерированная с полным листингом и со всеми включенными фичами (типа диаграмм классов и вызовов) doxygen документация. Даже если нет спец. комментариев то за счет удобства навигации (все на гиперссылках) и катологизации гораздо удобнее чем IDE.
Да, я сам пользуюсь doxygen.
Проблема тут только в том, что листинги оторваны от самого кода. И документация устаревает по мере изменения кода и требуются дополнительные усилия для ее изменения. И при просмотре кода мы лишаемся многих прелестей доступных в IDE.
Начиная даже с того, что так мы не можем его править.
Мое мнение — в IDE должна быть возможность просматривать файлы в режиме документации (активизируешь такой режим и из исходников со спецкомментариями генерируется HTML а-ля doxygen или MSDN). Но существенным отличием будет то, что вместо листингов ссылки будут вести на настоящий код. А соответственно при изменении кода и док-комментариев будет автоматически меняться и эта генерируемая документация.
Я так подумал, что наверное может быть в перспективе это можно и в нашу Nemerle-интеграцию прикрутить.
VS2005 позволяет иметь несколько View для каждого документа — обычно это код и дизайнер (для классов, унаследованных от форм), но можно и добавлять свои. Так что достаточно будет иметь (1) html/xml-генератор по док-комментам (для диаграмм можно какой-нибудь dot задействовать) и (2) html/xml + css -вьюер компонент.
Кое-какие заготовки по первому уже есть, в качестве второго можно насколько я понимаю взять стандартный компонент.
P.S. Мне кажется модераторы здесь не достаточно активно выделяют отдельные темы.
Здравствуйте, netch80, Вы писали:
N>Этой траты в сотни раз меньше, чем печатать Донцову А пользы — больше.
Ну смысл распечатывания Донцовой я даже обсуждать не хочу .
N>Впрочем, я подозреваю, что Вы никогда по-серьёзному и не пробовали работать с кодом на бумаге.
В школе и на первом курсе приходилось распечатывать то что писал дома, чтобы набить в комп. классе, т.к. либо дискетами пользоваться не разрешали (из соображений безопасности и чтобы игры не приносили), а на 1 курсе у нас был древний VAX, который стоял где-то далеко, а в комп. классе были только терминалы — мониторы с клавиатурами. В общем никаких положительных впечатлений.
Да, в общем то и желания не возникало. Слишком неудобно по-моему.
А вот с правкой/корректурой/редактурой текста приходилось работать как в электронном так и в бумажном виде.
Первое мне понравилось значительно больше, что и не удивительно, т.к. компьютер дает намного больше средств для работы с информацией
(особенно текстовой)
N> Дело ведь не во всяких средствах типа "вызвать код", которые Вы рекламируете ниже. Дело в первую очередь в возможности писать на бумаге пометки.
А на компьютере пометки нельзя делать? По-моему, гораздо удобнее.
Собственно компьютеры и придумали для удобства работы с информацией (прежде всего текстовой), так что я не понимаю смысл возвращаться к технологиям вчерашнего дня (ну только ради исторических переживаний).
N> А что писать в пометки — можно и через эти суперкодобраузеры посмотреть.
Проще гиперссылку скопировать drag-and-dropом (и она потом работает!), чем ее на бумажку переписывать.
N>>>- взять ручку и писать рядом с текстом свои замечания N>>>- что-то вписывать, вычёркивать, обводить и рисовать стрелочки для перестановки... АХ>>то же самое можно делать с помощью TabletPC/планшета, текст вбивать удобнее с клавиатуры.
N>А мне удобнее ручкой писать в таких случаях
Ужас .
N> А Вы тот текст куда втиснете? Он мешать будет.
А на бумаге он мешать не будет? В компьютере часто его вообще можно спокойно двигать, да и вообще менять представление как угодно.
Я уж не говорю что в компьютере "бумага" имеет неограниченные размеры
N> А тут — чётко видно — вот это напечатано, а вот это — ручкой написано.
А на компьютере видимо цвета/изменение шрифтов уже отменили?
N>Это всё понятно, но это внешние связи кода. А я про внутренние. В моей практике они важнее. Вообще, перечисленный Вами список сильно специфичен для всяких C++. А я уже не помню, когда в последний раз на нём что-то писал
А на чем ты пишешь?
Ну и все равно, в любом языке программирования из тех что я знаю (а ну да, в J/K по-моему не так ) есть некие именованные сущности (переменные, классы, функции, модули...) которые потом используются в других местах. Так что переход из места использования к месту объявления/документации — достаточно общая концепция.
N>Но и таких кошмаров как C++ практически не было.
Lisp, Smalltalk? Но на железе того времени они боюсь совсем небыстро работали. Да и памяти маловато было для GC.
FR>Только не понятно что именно там имеется в виду под "покер". FR>Каждый поток играет в карты за себя?
Угу, именно так. Плюс какие-то потоки периодически вылетают с исключениями, нагрузку посмотреть, еще чего-то.
Хотелось просто более менее реальную задачу, чтобы посмотреть, как различные языки будут вести себя на ней, насколько понятен код, насколько легко можно будет расширять функционал и т.п.
FR>Может стоит начать с каких-нибудь более простых хоть синтетических тестов?
Да я не против, просто нужно их предложить
Здравствуйте, FR, Вы писали:
FR>Вот пристал, наверно совсем делать нечего FR>А я не выносил, я объяснял человеку почему я не использую немерле.
Просто мне стало очень интересно, почему взрослый вроде бы человек применяет аргументацию на уровне "сниму шапку, пусть назло бабушке у меня уши отмерзнут нахрен"
Здравствуйте, FR, Вы писали:
VD>>Вот это уже точно фигня. Попробуй напирмер реализовать мета-код аналогичный моему макросы SupportRelocation: VD>>http://nemerle.org/svn/nemerle/trunk/macros/compiler.n
FR>Спасибо, но времени разбиратся в таком достаточно приличном объеме кода у меня нет. Вот если бы ты на словах объяснил или дал ссылку на документацию я мог бы сказать можно сделать подобное или нет.
Как я понимаю речь идёт о макросе SupportRelocation. Если на словах, то его работа заключается в переборе всех типов в проекте, поиска в них полей типа Location и добавления кода, отвечающего за изменение этих полей по определённым правилам. По пути делаются некоторые проверки и анализ кода. Так, например, если программист сделает поле типа Location не-mutable и его нельзя будет изменять, то компилятор выдаст ошибку с соответствующим предупреждением.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, netch80, Вы писали:
N>Никакие браузеры и суперредакторы с подсветками и свёртками не дадут такого удобства для _анализа_ текста программы.
Как я понимаю, речь идёт о проекте из трёх классов по сто строк.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Кстати, здесь неоднократно звучат пожелания -- чем зря трепаться, возьми N... и попробуй. Аналогично с бумагой: чем зря доказывать, насколько бумага неудобна, возьми и попробуй Только предупреждаю -- писать GUI-обработчики сначала на бумаге, потом на компьютере смысла большого нет. Здесь нужно что-то более алгоритмическое, например, балансировка нагрузки на исходящее TCP/IP соединение или механизм расставления в приложении контрольных точек для восстановления после сбоя в предшествующем сбою состоянии.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
FR>>Спасибо, но времени разбиратся в таком достаточно приличном объеме кода у меня нет. Вот если бы ты на словах объяснил или дал ссылку на документацию я мог бы сказать можно сделать подобное или нет.
IT>Как я понимаю речь идёт о макросе SupportRelocation. Если на словах, то его работа заключается в переборе всех типов в проекте, поиска в них полей типа Location и добавления кода, отвечающего за изменение этих полей по определённым правилам. По пути делаются некоторые проверки и анализ кода. Так, например, если программист сделает поле типа Location не-mutable и его нельзя будет изменять, то компилятор выдаст ошибку с соответствующим предупреждением.
Здравствуйте, Mirrorer, Вы писали:
FR>>Может стоит начать с каких-нибудь более простых хоть синтетических тестов? M>Да я не против, просто нужно их предложить
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, FR, Вы писали:
FR>>Вот пристал, наверно совсем делать нечего FR>>А я не выносил, я объяснял человеку почему я не использую немерле.
AF>Просто мне стало очень интересно, почему взрослый вроде бы человек применяет аргументацию на уровне "сниму шапку, пусть назло бабушке у меня уши отмерзнут нахрен"
От того что я немерле не использую у меня ни уши ни отмерзнут ни любого другого вреда ни будет, так что не надо некорректных аналогий, тут скорее правильней будет так "эту книгу я не буду читать так как мне не нравится ее слишком назойливая реклама, тем более я ее пролистал и не нашел слишком интересной"
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Mirrorer, Вы писали:
FR>>>Может стоит начать с каких-нибудь более простых хоть синтетических тестов? M>>Да я не против, просто нужно их предложить
FR>С этим у меня тоже пока туго
Вот в этом то и [censored]!
Есть вариант — взять тесты, что Одерски для Скалы сделал. Там именно многопоточность, т.е. чуть оторванно от жизненных реалий, но всё же...
Здравствуйте, PhantomIvan, Вы писали:
PI>- типичная демонстрация DSL-эмбеддинга, но синтаксис становится более "родным" — я выполняю чекинг в компайл-тайм
Кстати еще на тему "модификации" синтаксиса без непосредственного изменения синтаксиса. В Scala By Example приводится задачка:
можно ли реализовать цикл repeat с заданным синтаксисом:
repeatLoop { command } until ( condition )
Оказывается можно:
class Repeater( action: => unit ) {
def until( condition: => boolean ): unit = {
action
if( condition ) until( condition )
}
}
def repeatLoop( action: => unit ) = new Repeater( action )
var i = 0;
repeatLoop {
Console.println( "i=" + i )
i = i + 1
} until ( i < 4 )
как и в Ruby используются только стандартные вызовы методов объектов.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Кстати, я тут добрался до компилятора и, если кому интересно, продолжу эту тему.
Как вы уже все поняли, без подвоха тут не обошлось. И, что мне совсем не понравилось, два опытных немерлиста пропустили ошибку и определили тип функции неверно.
А корень всех зол в данном случае в том, что типы уточнялись не там где надо, нес па?
#pragma indent
using System
using System.Console
using System.Math
def makeDistrib(trxCount : int, quantums : int) : list[int]// объявление типа возвращаемого значения в заголовке
// полезно, это дополнительное документирование.
mutable r = [] // а вот здесь это было скорее замусоривание кода.
mutable remainingTrx = trxCount
mutable remainingQuantums = quantums
foreach (_i in [1..quantums])
r ::= Round((remainingTrx :> double) / remainingQuantums,
MidpointRounding.AwayFromZero) :> int// здесь тип r спокойно выводится.
remainingTrx -= r.Head
--remainingQuantums
r.Rev()// правильная(тм) практика уточнения типов
// помогает компилятору обнаружить ошибку здесь
def result = makeDistrib(2, 6)
WriteLine($"$result")
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>рыться в стопке бумаг для того чтобы понять где-чего... Не понимаю
E>В качестве информации к размышлению E>Re[11]: Методология дворника.
Ничего положительного не скажу про такие записи. Даже банально в Ворде можно лучше сделать.
E>Кстати, здесь неоднократно звучат пожелания -- чем зря трепаться, возьми N... и попробуй. Аналогично с бумагой: чем зря доказывать, насколько бумага неудобна, возьми и попробуй
Пробовал, для прототипирования и описания архитектуры инструменты хотя бы типа Visio/MindManager/FreeMind/Compendium удобнее (я их на практике использовал) удобнее. Наверное даже удобнее (именно для проектирования ПО) этих есть, просто я о них не знаю.
На бумаге в процессе brainstormingа непременно каракули получатся.
Любой whiteboard и то лучше (на нем стирать можно). Хотя все равно то что на нем написано/нарисовано — это лишь рисунок, без машинно-значимой семантики.
В некоторых фирмах (MS в частности) их фотографируют для сохранения, но это все равно не удобно, т.к. это фактически просто рисунок.
Да и хотя бы тот же Adobe Illustrator и то удобнее (+ он сейчас научился и в SVG сохранять, а значит потом из описания можно извлечь информацию для дальнейшей обработки стандартными средствами XML).
И XAML (с соответствующими редакторами) в принципе о том же.
Бумага еще живет, пока не очень распространены/удобны планшеты и сенсорные экраны. Со временем я думаю эти технические проблемы решат.
Здравствуйте, VladD2, Вы писали:
VD>Бизнес скорее пострадает от прагматизма если в следствии этого получится море запутанного кода в котором без паллитры не не разобраться.
VD>Переписывать тоже конечно изврат. Но выход есть. Давно придуман автоматизированный рефакторинг. Првада ув. т. еао197 и его тоже отрицает. Это тоже лишнее по его мнению.
Я являюсь большим поклонником рефакторинга, выполняю его при первой же возможности, но он, к сожалению не всегда возможен (у нас много веток и рефакторинг может сильно усложнить их слияние). Чужой код правлю только если с ним есть какие-то проблемы, а то, что он написан не так как его написал бы я не является аргументом в пользу его переписывания.
EC>>По секрету: я пишу в Visual Studio 2005.
VD>Ой, я тоже по сикрету хочу... Так вот по сикрету. Ты влез в огромный разговор еао197 с Фантомом. И как раз не задолго до твоей материализации еао197 выдвинул идею о бренности IDE. Ты же неразобравшись в конетескте не вольно стал защитником этой идеии. И то что ты сам используешь IDE говорит только о том, что цель у тебя не выяснение истины.
У меня с ними (с истинами) вполне неплохо. И в контексте я разобрался (всю ветку читал).
Речь шла о коде, который без IDE трудно понять — сомнительное достоинство на мой взгляд.
Просто я долго сопровождал довольно большой проект очень коряво написаный, поэтому сейчас знаю цену коду,
который написан просто и понятно, который делает ровно то, что должен делать и не требует неоправданных интеллектуальных услий,
чтобы его понять. Gaperton как-то очень кратно и точно изложил эту позицию
Просто я нелюблю передёргиваний: я не с фанатами IDE, которые не мыслят жизни без неё, не с её противниками — всему своё место.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>Да, в общем то и желания не возникало. Слишком неудобно по-моему.
FR>У бумаги есть большой плюс когда надо рисовать схемки, картинки, мне например при проектировании помогает.
А в чем проблема рисовать их на компе?
Особенно удобно если много стандартных элементов (блоки, стрелки). Их на компе и ворочать можно.
При возможности, цепочку общения необходимо сокращать. 
Если нам не помогут, то мы тоже никого не пощадим.
А пользы — больше.
) есть некие именованные сущности (переменные, классы, функции, модули...) которые потом используются в других местах. Так что переход из места использования к месту объявления/документации — достаточно общая концепция.
