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

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 (ссылка)
трудно приводить новых работников не мигрируя на новые языки. трудно не внося концепцию интерфейса/модуля делать узких специалистов. другое дело, что в людей не вкладывают. для перехода на новую технологию нужно людей подготовить: научить, дать пару сторонних проектов для отработки навыков и т.д.

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


(Читать комментарии) -