Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет Андрей Янпольский ([info]yanis)
@ 2004-12-23 00:34:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
мифы о программировании
Два главных примера принципиально неправильно понятой большинством методологии, с результатами, часто полностью противоположными желаемому - это Объекто-Ориентированное Программирование и Стандарты Кодирования.

Набор благих намерений при переходе на "Объекто-Ориентированную Парадигму" выглядит всегда примерно одинаково:

  • Облегченная поддержка кода

  • Централизация общих компонентов

  • Меньшее количество ошибок в коде и меньшая кодобаза, облегченное тестирование


Употребляются часто слова reusability, decoupling, modularity и тп. количество модулей возрастает в разы и даже десятки раз, информативность кода качественно падает. Там где раньше была процедурка на С из 50 строчек с одним экспортированным символом, которой требовалось скажем 1000 байт в сегменте кода, 100 байт стека, 100 байт статических и 100 байт из кучи, появится иерархия классов в 500 строк которая будет экспортировать 10 символов, занимать 10 килобайт в сегменте кода, жрать в 10-20 раз больше ресурсов и работать в 10 раз медленнее.

Поддерживать новую дрянь будет сложнее - там где раньше требовалось разобраться в 50 строчках теперь придется читать 500 строк кода и несколько документов, автоматически сгенерированных системой Documentix. Поэтому, ни в какой "модуль" он с большой вероятностью не превратится, а будет скопирован столько раз, сколько версий поведения потребуется.

Если а) система существенно велика - скажем больше миллиона строк кода б) процент компетентных программистов (на любом языке) ниже некоторой отметки (скажем 20%) в) процент очень сильных программистов, ниже допустим 10% с) процент очень слиьных программистов, которые глубоко знают новые технологии ниже 5% вероятность того, что все произойдет именно так, как я описал, выше 90%. То есть - поддержка и разработка софта станут дороже, цикл разработки длиннее, качество ниже.

Если документ со "стандартами кодирования" превосходит по длине 3 страницы - его авторам не хватает работы, и их нужно либо срочно занять чем-нибудь полезным, либо уволить, потому что борьба за стандартизацию всегда превращается в самодостаточный процесс.

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

Те кто распоряжаются бюджетами многое из этого понимают, но по ряду естественных биологических причин ничего не делают.


(Добавить комментарий)


[info]https@lj
2004-12-23 03:40 (ссылка)
Да, проблема в не в методологиях, а в том что кругом уроды.

(Ответить) (Ветвь дискуссии)


[info]yanis@lj
2004-12-23 04:28 (ссылка)
проблема в том, что уроды существуют в некотором органичном, изначально работающем мире, нарушая который, мы создаем очень серьезные проблемы. тот факт, что кругом уроды должен учитываться наряду с остальными параметрами ситуации, этого не происходит, но декларируется, что С++, Ява, UML и Кодинг Стандардс смягчат уродства, а это верно с точностью до наоборот.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]https@lj
2004-12-23 05:18 (ссылка)
На самом деле проблема в том, что уродов не сношают. Вот у нас в кодинг стандартс написано, что класс не более 500 строк. Думаешь, что хоть один урод воспринл это ограничение?????? Нет, конечно, файлы по 2000 сводят на нет все ООП, тем самым нивелируя твои претензии к объектам на нет, но жизнь от этого становится просто ужасной. Я бы за такое просто сразу увольнял. Вот как раз такой plain-text я сейчас и пытаюсь привести в себя... зверею....

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]arbat@lj
2004-12-23 09:27 (ссылка)
А вот это и есть пример неправильно понятой идеи "стандартов кодирования". Почему именно 500 строк? Почему не 100 или не 1000?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]https@lj
2004-12-23 09:54 (ссылка)
Потому что больше 500 обычно нечитабельно.
А пример учень и очень удачный. Т.к. требование тривиально, но его несоблюдения делает любой код мертвым и невозможным к сопроваждению.

(Ответить) (Уровень выше) (Ветвь дискуссии)

арбат абсолютно прав.
[info]yanis@lj
2004-12-23 12:16 (ссылка)
дело не в количестве строк в классе и подобные требования, как раз и есть пример того с чего мы начали разговор : )

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: арбат абсолютно прав.
[info]https@lj
2004-12-23 16:26 (ссылка)
Короче, увольте всех уродов вокруг меня ;)

(Ответить) (Уровень выше)


[info]dmpogo@lj
2004-12-23 13:39 (ссылка)
Soglashus' s Arbatom. Linejnaja programma w 2000 strok zachastuju chitajetsja gorazdo luchshe chem 40 wzaimodejstwujushih modulej po 50. Mozhet w srednem i net, no to chto iskustwennoje ogranichenije
na dlinnu perdiodicheski budet meshat' - ochewidno.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]https@lj
2004-12-23 16:25 (ссылка)
Просто у меня как раз два проекта... таких... уж лучше бы они написали 40 классов. Чем этот сплошной линейный код, в котором ничего непонятно, ничерта не работает и никто не может найти концов.

(Ответить) (Уровень выше)


[info]dmierkin@lj
2004-12-23 12:44 (ссылка)
трудно приводить новых работников не мигрируя на новые языки. трудно не внося концепцию интерфейса/модуля делать узких специалистов. другое дело, что в людей не вкладывают. для перехода на новую технологию нужно людей подготовить: научить, дать пару сторонних проектов для отработки навыков и т.д.

(Ответить) (Уровень выше)

О ООП
[info]ingas@lj
2004-12-23 07:27 (ссылка)
Я считаю, что ООП имеет смысл :

А) Университетские проекты с открытым кодом (что меня совершенно не интересует)

Б) Когда концепции воплощаются не на уровне языка, а на уровне платформы. COM, CORBA, .NET, им подобные. Но в этом случае ни об меньшем объеме кода, ни об его упрощении речи и быть не может. Как и о производительности также. Все наоборот, но затраты иногда окупаются.

Мы собираем экзешник из разных объектов для разных клиентов и собираемся предоставить возможность собирать нужную конфигурацию из объектов администратору на стороне клиента.
Кроме того есть и возможность ИТ клиента самим дописывать плагины.
Что удобно.

Вкратце, мое мнение : ООП наиболее выгоден, когда нужна не программа, выполняющая определенный список функций, а расширяемая платформа.

(Ответить) (Ветвь дискуссии)

Re: О ООП
[info]ex_jcell@lj
2004-12-29 12:19 (ссылка)
Качество кода open source проектов оставляет желать лучшего. Исключений я ещё ниразу не видел.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: О ООП
[info]ingas@lj
2004-12-30 09:48 (ссылка)
Под open source Вы понимаете GPL, BSD-licence и им подобные?
Даже в этом случае Вы слишком категоричны.

А если говорить об университетских проектах, о разработках для военных, очень много корпоративного софта - это все open source. Это не означает, что исходники лежат в открытом доступе для кого угодно, обычно совсем наоборот. Open source - исходники открыты для специалистов клиента.

В этом отношении, серьезного не-open source софта почти не существует. Не зря Microsoft регулярно передает военным исходники, чтобы те удостоверили, что там нет троянов от CIA - без этого вообще бизнес во многих областях невозможен.

(Ответить) (Уровень выше)


[info]cousin_it@lj
2004-12-23 10:06 (ссылка)
Есть мнение, что стремление к modularity/reuse только мешает. А реально набирает силу другой подход: Одноразовое Программирование. Примеры: HTML, Excel, Perl.

(Ответить)

Как фанат ООП ...
[info]maxf@lj
2004-12-23 13:23 (ссылка)
Андрюш, если на Си напишет тот же человек чей бред ты описал, у тебя появится не функция на 50 строк, а функция на 500 строк с повторением одного и того же по методологии Cut&Paste. Я такую прелесть имел удовольствие наблюдать. ООП хорош для того чтобы оперировать объектами на алгоритмическом уровне программы а не на процедурном. Таким образом более сложные программы проще решаются. А на тему ресурсов, вот хорошая статья про две школы мышления:
http://www-106.ibm.com/developerworks/webservices/library/ws-restvsoap/
Это конечно J2EE пример, но идея базовая в том что именно для тебя важно: Ресурс или Сервис?

(Ответить) (Ветвь дискуссии)

Re: Как фанат ООП ...
[info]polter@lj
2004-12-23 21:42 (ссылка)
я бы сказал, что ООП хорош для того, чтобы оперировать объектами точка.
только очень часто объекты появляются там, где они вообще не нужны

что касается алгоритмического уровня, то там порой объекты могут вообще довести до катастрофы.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: Как фанат ООП ...
[info]yanis@lj
2004-12-23 21:51 (ссылка)
разумеется, да. речь идет о принципиальном непонимании человечеством того, когда объекты таки нужны

(Ответить) (Уровень выше)


[info]dmpogo@lj
2004-12-23 14:42 (ссылка)
Vot ja woobshe ne programmist. To est' pishu programmy dlja nauchnyh zadach, nekotorye w sotrudnichestwe s kollegami. Sootwetstwenno my ne osobenno orientirowany na maintenance, a skoree - na resul'tat. I u nas net nikogo manager osushestwljajushego rukowodstwo. Wpolne analog programmisticheskih urodov.

Iz moego opyta - maksimum chto slepo reused - eto podprogrammu/funkcii. Mne pripominajetsja chut' li ne lish' odin
Fortran95/C++ modul'/class kotoryj ja ispol'zowal bez izmenenij v neskol'kih (swoih zhe) proektah. A wse moi kollegi imejut customized versii ego zhe. A tak kazhdyj nowyj proekt trebuet chut' drugoj versii, zdes' polowina ne nuzhna, zdes' drugie peremennye nado eksportirowat', zdes' kollege nuzhen odin tip, mne drugoj. Podderzhka uniwersal'nogo modulja nachinaet byt' zadachej po sebe. A cut/paste/customise tak prost.

I wed' pered kazhdym proektom my dogowariwaemsja chto w etot raz - wse budet moduljarno, usilija ne budut dublirowat'sja, dogoworimsja o strukture. I kazhdyj raz cherez polgoda u menja obnaruzhiwaetsja modul' wrappers na moduli kollegi, u nego - na moi, a nedawno ja uwidel u nego wrappers na moi wrappers.

A prjamolinejnyje C/Fortran programmy 10 letnej dawnosti, s horoshej strukturoj podprogram i bez modulej/objectow - chitajutsja legko, i modificirujutsja legko.

Ja k chemu - reusability estestwenno ne woznikaet, a trebuet zhestkoj managerial discipliny. I usilija na ego podderzhku zachastuju a) potracheny naprasno b) priwodjat lish' k uslozhnenije struktury. Osobenno esli delajutsja ne programmistami wysokogo professional'nogo plana. A ja podozrewaju ne tol'ko my w nauke dwizhemy resul'tatom i podzhimaemy dedlajnom.

(Ответить)


[info]polter@lj
2004-12-23 21:53 (ссылка)
на самом деле конечно уроды доведут до абсурда любую идею
так всегда было и будет
тут правда еще и идея уродская достаточно
так что в результате мы имеем системы из десяток тысяч классов в которых можно разбираться жизнь
и порой, чтобы добавить новую функциональность или чуть-чуть поправить существующую, приходится так сильно углубляться в систему, что это начинает занимать полжизни.

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

(Ответить)


[info]yazmeya@lj
2004-12-24 20:02 (ссылка)
не пишите перед сном на плохих обжектно-ориентированных языках

класс задач, для которых имеет смысл применение ОО методов не имеет ничего общего с классом задач, решаемых в 50 строчек на Ц.

(Ответить) (Ветвь дискуссии)


[info]yanis@lj
2004-12-24 20:04 (ссылка)
ты не понял. было 5000000 строчек, а 50 строчек - это только кусочек (стихи прямо). так вот каждый кусочек 50 строчный после объективизации ухудшится в 10 раз.

(Ответить) (Уровень выше)


[info]ex_jcell@lj
2004-12-29 12:17 (ссылка)
Структурное программирование не обеспечивает должный уровень инкапсуляции кода и независимости модулей. Copy&Past является основным стилем расширения функциональности приверженцами структурного стиля программирования.

Рекомендую почитать букварь под названием "Рефакторинг" Мартина Фаулера :)

(Ответить) (Ветвь дискуссии)


[info]yanis@lj
2004-12-29 12:30 (ссылка)
не надо такую хуйню мне рекомендовать, плиз :)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ex_jcell@lj
2004-12-29 12:31 (ссылка)
Нет, я конечно понимаю что поддержание бардака в проекте гарантия от того что тебя не заменят кем-то менее дорогим :)

(Ответить) (Уровень выше)