Как можно уменьшить сложность разработки больших комплексов.

← →
Ученик чародея © (2006-02-17 20:30) [0]

Навскидку.
1. Документирование каждой процедуры/метода/свойства/класса...
2. Применение агентного или объектного программирования.
3. Разделение программы на модули однородные по семантике.
4. Использование RAD средств.
5. Использование языков с большим количеством бесплатных библиотек (C/C++, Java, Delphi).
...

← →
Джо © (2006-02-17 20:35) [1]

Одно другому не мешает, имхо.

← →
Игорь Шевченко © (2006-02-17 20:38) [2]

2 по моему мнению, при 5 само собой разумеющемся, чтобы не тратить время на изобретение велосипедов. 1 тоже способствует, если разумно использовать.

6. Грамотное проектирование, без этого все остальные пункты бесполезны.

← →
Sergey Masloff (2006-02-17 20:39) [3]

Джо © (17.02.06 20:35) [1]
Мешает-мешает.
п.1 вообще детский лепет
п.2 слышал звон не знает где он
п.3 вообще общие слова
....

← →
Ученик чародея © (2006-02-17 20:47) [4]

>>Sergey Masloff (17.02.06 20:39) [3]
>>п.3 вообще общие слова

Например работу с FTP и с локальными файлами разнести в два и более независимых юнита. Чтобы каждый модуль был самодостаточен(или группа модулей) и его можно было без проблем отделить от проекта, например, для повторного использования.

>>Sergey Masloff (17.02.06 20:39) [3]
>>п.2 слышал звон не знает где он

Может тогда вы расскажете, в двух словах, в чем концепция агентного подхода к программированию и ее преимущества?

>>п.1 вообще детский лепет

Не совсем нравится, так как забирает время, которое можно потратить на кодирование.

← →
Игорь Шевченко © (2006-02-17 21:23) [5]

> Не совсем нравится, так как забирает время, которое можно
> потратить на кодирование.

Неплохо бы учитывать, что программы пишутся не для компьютера

> Например работу с FTP и с локальными файлами разнести в
> два и более независимых юнита

Как минимум, в три.

← →
Sergey Masloff (2006-02-17 21:29) [6]

Игорь Шевченко © (17.02.06 21:23) [5]
>Неплохо бы учитывать, что программы пишутся не для компьютера
А так как пишутся для человека, а ему свойственно менять желания, код постоянно "дышит" и рассинхронизируется с документацией. Потому документирование каждого чиха занятие не только бесполезное но и вредное. Код должен быть самодокументируемым (имена методов etc...) и легкочитаемым, а документация должна описывать только самые общие концепции и, может быть, какие-то аспекты алгоритмов нетривиальные. Вроде так.

← →
Ученик чародея © (2006-02-17 21:31) [7]

> Игорь Шевченко © (17.02.06 21:23) [5]
> Неплохо бы учитывать, что программы пишутся не для компьютера

А какой уровень документирования достаточен (люди диссертация по этому поводу защищают)? Каждый оператор или достаточно общего описания работы модуля?

> > Например работу с FTP и с локальными файлами разнести в
> > два и более независимых юнита
>
>
> Как минимум, в три.

Почему в три? Интересно, так как никогда не работал в команде, но мой код вполне читабелен (по словах тех кто с ним работает).

А старые студенческие программы просто жуть. При попытке что-то отшкрести - падает все.

← →
Ученик чародея © (2006-02-17 21:35) [8]

>>Sergey Masloff (17.02.06 21:29) [6]

Sun-овский JDK (javadoc) позволяет по исходникам строить скелет документации (плюс препроцессор для документированного кода).

← →
Sergey Masloff (2006-02-17 21:38) [9]

Ученик чародея © (17.02.06 21:35) [8]
Вот только хотел про это написать. Это профанация! То что он генерит ( и подобные ему) это чушняк. Гораздо быстрей прочесть код чем шаблонные фразы которые пытаются его описать. Я с этим делом работал много, интегрировал большую систему в которой как раз так документация была сделана. Это ужас. Да что там далеко ходить - документация в Jedy и Indy. Слово одно - убожество. Только замедляет работу.

← →
wicked © (2006-02-17 21:39) [10]

не меня спрашивали, но вставлю свои 5 коп.......

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

> Почему в три? Интересно, так как никогда не работал в команде,
> но мой код вполне читабелен (по словах тех кто с ним работает).
интерфейс-предок + уточняющие реализации..... почти идеальный пример - TStream сопотомки....

← →
Игорь Шевченко © (2006-02-17 22:10) [11]

Ученик чародея © (17.02.06 21:31) [7]

> Почему в три?

В одном абстрактная реализация, в двух других две конкретные.

> А какой уровень документирования достаточен (люди диссертация
> по этому поводу защищают)? Каждый оператор или достаточно
> общего описания работы модуля?

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

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

Кстати, очень хороший код в исходниках Unix, много лет назад я видел какую-то BSD, пришел в восторг.

Sergey Masloff (17.02.06 21:38) [9]

> Вот только хотел про это написать. Это профанация! То что
> он генерит ( и подобные ему) это чушняк

Не скажи. Генерация перекрестных ссылок очень полезна.

← →
Дмитрий Белькевич © (2006-02-18 04:40) [12]

> А какой уровень документирования достаточен (люди диссертация
> по этому поводу защищают)? Каждый оператор или достаточно
> общего описания работы модуля?

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

Что касается наружного лица модуля - то тут, чем точнее опишете, тем меньше вопросов. Например, документация от MS иногда просто убивает. Как вспомню, как несколько раз псевдонаучными методами параметры некоторых api искал, так вздрогну ;)

← →
Ученик чародея © (2006-02-18 04:50) [13]

>>Дмитрий Белькевич © (18.02.06 04:40) [12]

А что более важно, чтобы при минимуме времени и средств создать крупный проект?

← →
Anatoly Podgoretsky © (2006-02-18 09:22) [14]

wicked © (17.02.06 21:39) [10]
Может название сменить, зачем же обходные пути?

← →
Ученик чародея © (2006-02-18 18:00) [15]

Есть предложение - составить четко означенные критерии хорошего кода на Delphi с примерами и антипримерами и способы уменьшения сложности и выложить в FAQ.

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

← →
Kerk © (2006-02-18 18:02) [16]

Ученик чародея © (18.02.06 18:00) [15]
Например, ни в одной институтской программе этого нет

"Технология программирования", 3й курс

← →
Ученик чародея © (2006-02-18 18:05) [17]

>>Kerk © (18.02.06 18:02) [16]

Там нет четкой технологии, там есть набор общих принципов, которые нужно самому выстроить в технологию.

> Anatoly Podgoretsky © (18.02.06 09:22) [14]
например, "МоёДлинноеСамодокументирующееИмя1", "МоёДлинноеСамодокументирующееИмя2" и т. д?........
я понимаю, что нужно называть четко, пусть и длинно, и даже сам так делаю..... но согласитесь, что если для адекватного названия идентификатору напрашивается целая фраза (а ля, утрированно, "флажок, сигнализирующий о том, что мышь попала в нужную точку и при данном режиме отображения делать ничего не нужно"), то что то нужно переделывать, не так ли?....
тут уж называем исходя из контекста (например, метод Open класса BeerCan), либо пишем аннотации....

> Есть предложение - составить четко означенные критерии хорошего
> кода на Delphi с примерами и антипримерами и способы уменьшения
> сложности и выложить в FAQ.

С антипримерами просто - полные форумы

Ученик чародея © (18.02.06 4:50) [13]
А что более важно, чтобы при минимуме времени и средств создать крупный проект?
Опыт

← →
Algol (2006-02-20 12:40) [22]

> Есть предложение - составить четко означенные критерии хорошего
> кода на Delphi с примерами и антипримерами и способы уменьшения
> сложности и выложить в FAQ.

Хых.... тут сразу ТАКОЙ холивар начнется....
Сколько людей - столько мнений. И к программистам это в первую очередь относится.

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

Как по мне панацеи нет :) Равно как и конструктивных советов. Можно пользоваться пунктами 1-5 из твоего списка и запутаться. Можно пользвоаться пунктами 1-5 и не запутаться. Можно не пользоваться пунктами 1-5 и все-таки разработать неплохую большую программу %)

Ученик чародея © (18.02.06 18:00) [15]
хороший код автоматически начинает получаться только со 2-го рабочего проекта
Хороший код получается с третьей системы, так как после второй приходит ложное понимание что все хорошо.
====
Самодисциплина - эффект второй системы
Первый проект архитектора стремится к скромности и ясности. Архитектор
понимает, что не знает, чем занимается, поэтому он занимается этим со
старанием и самоограничением.
При работе над первым проектом ему постоянно приходят в голову то одни,
то другие "украшения". Они откладываются в сторону для использования "в
следующий раз". В конце концов, первая система закончена, и архитектор, с
твердой уверенностью в себе и продемонстрированным освоением этого класса
систем, готов к созданию нового проекта.
Эта вторая система таит наибольшие опасности для проектировщика. При
работе над третьей и последующими системами закрепляется полученный ранее
опыт в отношении общих характеристик таких систем, а различия между ними
выявляют те части опыта, которые носят частный характер и не могут быть
обобщены.
Общая тенденция заключается в перегруженности проекта второй системы
идеями и украшательствами, благоразумно отложенными в сторону при работе над
первым проектом. В результате получается, говоря словами Овидия, "большая
куча".
(с) Фредерик П.Брукс. Мифический человеко-месяц или как создатся программные системы

Как можно уменьшить сложность разработки больших комплексов. Найти похожие ветки