Скачать: CL | DM;

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

← →
Ученик чародея ©   (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]

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

---

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

Ученик чародея ©   (18.02.06 18:05) [17]

Ну и правильно.

---

← →
wicked ©   (2006-02-18 18:18) [19]

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

---

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

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


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

---

← →
КаПиБаРа ©   (2006-02-20 12:35) [21]

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

---

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

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


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

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

---

← →
Mystic ©   (2006-02-20 12:45) [23]

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

---

← →
by ©   (2006-02-20 14:06) [24]

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

---

Страницы: 1 вся ветка

Скачать: CL | DM;



Память: 0.53 MB
Время: 0.027 c