Автор Тема: Задачка архитекторная.  (Прочитано 65655 раз)

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Задачка архитекторная.
« Ответ #120 : Апрель 01, 2011, 05:08:19 pm »
Нелюбовь оберонщиков к динамическим языкам (и даже противопоставления, как у info21) мне вообще не понятна и объясняется только парадоксом Блаба. Оберон при статической типизации лишен какой либо арифметики типов.

Вы можете программировать на Питоне, не составляя тестовые наборы? Т.е. можете получить приемлемое качество компонента, не составив на него тесты?
Я не говорю, что правильно программировать без тестов, неплохо ими подкреплять процесс, но я обычно не прибегаю к модульным тестам вообще (если бы делал вычислительно-алгоритмического характера задачи, то прибегал бы), я и так бываю уверен в качестве компонента. Только интеграционное тестирование. (Разумеется, если бы пришлось решать критичную по надёжности задачу, то нужно было бы перестраховываться любыми доступными способами).

Теперь представьте, перехожу я на динамический язык. (Мне не надо этого представлять, ряд вещей на PHP и JS я совсем недавно писал, но боролся с их закидонами осторожностью и многократными внимательными перепроверками кода, там надо было не очень объёмные, но важные компоненты написать для других разработчиков).
Так вот, перехожу я. Положим первый вариант программы я составлю, и даже забью особо на тесты. Но затем я натолкнусь на дамоклов меч этой динамики - при рефакторинге, при малейшем изменении сигнатур процедур или чего ещё я буду долго биться задницей об стену. А если учесть, что даже при разработке первого варианта я пару раз люблю порефакторить... То биться буду с самого начала.
Те, кто работает в стиле с тестами, те скажут, "а у нас вместо компилятора - тесты". Но у меня-то нет тестовых наборов специальных... Это значит, что я должен буду их завести и привыкнуть к такому стилю. Для меня это будет избыточной работой. Я привык тратить больше времени, чем другие, на написание (чтобы сразу получать правильную программу) и вычитку кода, и ещё буду тратить время на тесты...

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re:Задачка архитекторная.
« Ответ #121 : Апрель 01, 2011, 05:32:42 pm »
А вот если взять питоноверсию и попробовать её переписать на языке со строгой статической типизацией, тогда вот вылезут грабли. Желающие могут попробовать её переписать на хаскеле, ну, или, хотя бы на Аде.
В хаскелле ООП-классов же нету, просто так переписать не получится. Код совершенно другим выйдет...
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Задачка архитекторная.
« Ответ #122 : Апрель 01, 2011, 05:53:53 pm »
Нелюбовь оберонщиков к динамическим языкам (и даже противопоставления, как у info21) мне вообще не понятна и объясняется только парадоксом Блаба. Оберон при статической типизации лишен какой либо арифметики типов.

Вы можете программировать на Питоне, не составляя тестовые наборы? Т.е. можете получить приемлемое качество компонента, не составив на него тесты?

Я вам уже писал как-то... Без тестов приемлемое качество вы никогда не получите. Даже на волшебном обероне (как же к слову не сказать про обилие "дурацкких" ошибок в виртовских книжках). Просто статические языки позволяют вам намного дольше жить "в кредит" с иллюзией, что вам все проверит компилятор, а ошибок в логике вы не делаете. Такой подход даже работает в случае, когда вам удается "спихнуть" проект до наступления часа Х, когда сложность поведения (даже не системы в целом, а отдельных компонент) такова, что компилятор вам уже никак не помогает, а как это должно работать на самом деле никто не знает/не помнит.

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

Я не говорю, что правильно программировать без тестов, неплохо ими подкреплять процесс,

Вот тут принципиальная ошибка. Не подкреплять. Подкреплять вы можете комментариями, документацией и красивыми графиками, если время останется :) Тесты - первичны. Они так же первичны, как дизайн и архитектура.

Теперь представьте, перехожу я на динамический язык. (Мне не надо этого представлять, ряд вещей на PHP и JS я совсем недавно писал, но боролся с их закидонами осторожностью и многократными внимательными перепроверками кода, там надо было не очень объёмные, но важные компоненты написать для других разработчиков).
Так вот, перехожу я. Положим первый вариант программы я составлю, и даже забью особо на тесты.

Дальше можно не читать... понятно чем оно кончится ;)

Но затем я натолкнусь на дамоклов меч этой динамики - при рефакторинге, при малейшем изменении сигнатур процедур или чего ещё я буду долго биться задницей об стену. А если учесть, что даже при разработке первого варианта я пару раз люблю порефакторить... То биться буду с самого начала.

Рефакторинг - это не только изменение сигнатур функций. Вот я работаю с базой кода, которой больше 10 лет. Статический язык. Невозможно ничего отрефакторить, пока досканально не разберешься, что делает компонента и зачем. На эти разбирательства уходят дни без единой строчки нового кода. И не надо мне пытаться рассказать, что если бы это был оберон, а не С++, то было бы быстрее (скорее наоборот). Да, если бы это был динамический язык - то были бы не дни, а недели, тут я согласен :) Но речь не об этом. А о том, что если бы оно было с вменяемыми тестами, то можно было бы просто брать и спокойно кромсать компоненту в свете нового понимания ее правильной работы, без риска, что потом у пользователя отвалится его самый важный юзкейс.

Те, кто работает в стиле с тестами, те скажут, "а у нас вместо компилятора - тесты". Но у меня-то нет тестовых наборов специальных... Это значит, что я должен буду их завести и привыкнуть к такому стилю. Для меня это будет избыточной работой. Я привык тратить больше времени, чем другие, на написание (чтобы сразу получать правильную программу) и вычитку кода, и ещё буду тратить время на тесты...

Ужос. Я вам это процитирую лет так через 5 :)
« Последнее редактирование: Апрель 01, 2011, 05:56:01 pm от vlad »

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Задачка архитекторная.
« Ответ #123 : Апрель 01, 2011, 06:26:21 pm »
Влад, ну я работаю больше 10 лет, знаешь...

Речь-то идёт об каждом отдельно взятом компоненте. Достаточно обособленно спроектированном и разработанном. Компонент - это 5-10 тыс. строк. Такой компонент можно и нужно разрабатывать надёжно даже в отсутствие тестовых наборов. Остаются небольшие ляпы, но для некритичной системы они сами вылезают и очень быстро (на ассертах тех же) при прогоне на интеграции.

Что изменится за 5, 10 лет? У меня будет 100, 200... компонентов, каждый всё тем же объёмом 5-10 тыс. строк, каждый всё также работает.

А реализовывается тестирование на каждую систему, каждый заказ, идущий в эксплуатацию, разумеется, там это необходимо (без этого можно обходиться только в экстренных случаях, но потом это и правда выходит боком). И такое тестирование - не задача для разработчика компонентов, и не для меня, как архитектора. Есть инженеры по качеству, это их работа. Я эту работу уважаю, но не сильно разбираюсь - не моё :) У меня вот ученик мой бывший и студент, сейчас в Калуге работает на этой должности, над системой для британской биржи какой-то по ценным металлам... Много чего интересного рассказывает :) Ещё одногруппник тоже, тот в Бишкеке по тестированию билинга Мегафона работал два года. Дотошные ребята, молодцы, затестируют вусмерть :)

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Задачка архитекторная.
« Ответ #124 : Апрель 01, 2011, 06:31:11 pm »
Кстати, вот в этом году много примеров разбираю разных со студентами, на проекторе пишем прямо. Размеры примеров 700-2000 строк, около того (1-4 модуля).
И часто бывает, что всё работает верно сразу после написания. Ну либо мгновенно обнаруживаемые ляпы, на ассертах или NIL (что-то не соединили). Не было случая, чтобы надо было возиться с отладкой, если программа хорошо структурирована (в смысле разбиения на процедурки).
И я стараюсь, чтобы ребята запоминали крепко процесс вот такой работы - когда ты запускаешь программу (= компонент системы), будучи уже уверен в том, что она верна.

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Задачка архитекторная.
« Ответ #125 : Апрель 01, 2011, 06:35:31 pm »
Возможно, многое решает привычки-настрой. Если человек настроен на отладку, он будет работать в режиме спринтера - составляем, составляем, не думаем об ошибках. Не перечитываем.

Если работать с противоположной привычкой, то больше 2/3 времени сидишь и листаешь свой же код, напишешь - перечитаешь сто раз. Может, у меня характер такой - я люблю неспешно строить, а не бежать за строчками.

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Задачка архитекторная.
« Ответ #126 : Апрель 01, 2011, 07:41:39 pm »
Влад, ну я работаю больше 10 лет, знаешь...
Извиняюсь за возможно некорректное вмешательство, но, однако, получается что ты работаешь как минимум с 14ти лет программистом и около того.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Задачка архитекторная.
« Ответ #127 : Апрель 01, 2011, 07:52:48 pm »
Влад, ну я работаю больше 10 лет, знаешь...

Это не то. Приходилось ли вам рефакторить чужой код, которому 10+ лет? Еще и написанный не в вашем стиле (я не про форматирование)? Код, кторый вы не имеет права "сломать"? Код, у которого не два выхода "сработало/не сработало", а нечто о чем вы имеет общее представление. Код, который вмурован зависимостями в другой код? Не выкидывать и переписывать нафиг, а рефакторить? Еще раз замечу, что это был не плохой код (10 лет назад) и писан не идиотами. И с зависимостями у него 10 лет назад было все относительно хорошо. Просто за 10 лет он был столько раз "захэкан", что превратился в полное говно. А захэкан он был из самых добрых побуждений - чтобы с меньшей вероятностью что-то сломать. Потому что сделать "смелый" рефакторинг слишком дорого - тестов нет, фиг знает какие сценарии использования будут упущены.

Речь-то идёт об каждом отдельно взятом компоненте. Достаточно обособленно спроектированном и разработанном. Компонент - это 5-10 тыс. строк. Такой компонент можно и нужно разрабатывать надёжно даже в отсутствие тестовых наборов. Остаются небольшие ляпы, но для некритичной системы они сами вылезают и очень быстро (на ассертах тех же) при прогоне на интеграции.

Блин. Да не можете вы его взять и прогнать. Потому что там мильён сценариев. Потому что, например, вам среду окружения надо будет сетапить целый день (специфика работы с каким-нибудь файловым сервером под Mac OSX). Или потому что у вас просто нет железки, с которой он работает.

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Задачка архитекторная.
« Ответ #128 : Апрель 01, 2011, 07:58:57 pm »
Кстати, вот в этом году много примеров разбираю разных со студентами, на проекторе пишем прямо. Размеры примеров 700-2000 строк, около того (1-4 модуля).
И часто бывает, что всё работает верно сразу после написания.

И чего? В момент написания - ну вообще не парит. Можно писать на питоне и без тестов. Быстро. Парит потом, когда уже поздно что-то делать, можно только плакать и грызть кактус.

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Задачка архитекторная.
« Ответ #129 : Апрель 01, 2011, 08:03:22 pm »
Возможно, многое решает привычки-настрой. Если человек настроен на отладку, он будет работать в режиме спринтера - составляем, составляем, не думаем об ошибках. Не перечитываем.
ешно строить, а не бежать за строчками.

Да, да. Я вот пишу и не не знаю - заработает или нет и какие будут ошибки. Поэтому приходится писать тесты. А вам это не грозит, потому что вы думаете. Смешно...

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Задачка архитекторная.
« Ответ #130 : Апрель 02, 2011, 07:05:07 am »
Влад, ну ёханый бабай, если компонент ПРАВИЛЕН, если он вычитан перекрёстно несколькими людьми и не раз (потому что написан настолько структурированно, чтобы это можно было делать), то какие с этим компонентом будут проблемы? Рефакторить "хаками" реализацию отдельного модуля у нас тоже не принято, отдельная реализация какого-нибудь ABSTRACT-типа на пару тыщ строк просто переписывается с нуля, так, как нужно под новые требования...

Это не самоуверенность, это просто наблюдения из практики - если поставить целью выверять код аудитом до тестирования и заточить весь стиль работы группы разработчиков под это, то результаты удивляют. Даже нас самих.
« Последнее редактирование: Апрель 02, 2011, 07:08:23 am от Илья Ермаков »

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Задачка архитекторная.
« Ответ #131 : Апрель 02, 2011, 07:11:23 am »
Хотя, впрочем, я выше подчёркивал, что я не обобщаю подход на какие-то вычислительного характера задачи, и, кстати, на бизнес-логику (где идёт действительно взрыв сценариев). Я говорю о кубиках-компонентах (по стилю разработки это - системное программирование, в общем). А бизнес-логика как раз возникает поверх кубиков, на верхнем уровне, как интегрирующий слой. "Оркестровка", как принято это называть. Вот ей инженеры по качеству и должны заниматься, разрабатывать тесты, как положено.

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Задачка архитекторная.
« Ответ #132 : Апрель 02, 2011, 07:16:52 am »
На самом деле, характер кода неплохо характеризуется критерием разветвлённости (числом путей, за счёт IF-ов).
Кстати, эта мера чётко растёт от системного уровня к прикладному. И подходы, соответственно, тоже должны различаться.

С другой стороны, правильно организовывать систему надо так, чтобы все сценарии, вот это принятие решений уходило наверх, на интегрирующий уровень. Каждый компонент должен включать в себя как можно меньше принятий решений, вот этих сценариев работы. Вместо параметризации компонентное программирование предполагает вариативность реализации.
Возникает желание сделать компонент X с кучей конфигурационных параметров? Делаем одну абстракцию и несколько разных её реализаций. Вместо одной настраиваемой. (Правда, код в реализациях будет процентов на 30 повторяться, ну и что? Это же сокрытое внутреннее устройство, оно один раз написано (по аналогии или частично даже копипастом) и годами потом используется...)

Года два назад сформулировал для себя принцип: кубики тупые и делают конкретную работу, принимает решение надсистема.

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Задачка архитекторная.
« Ответ #133 : Апрель 02, 2011, 05:02:37 pm »
На самом деле, характер кода неплохо характеризуется критерием разветвлённости (числом путей, за счёт IF-ов).
Кстати, эта мера чётко растёт от системного уровня к прикладному. И подходы, соответственно, тоже должны различаться.

С другой стороны, правильно организовывать систему надо так, чтобы все сценарии, вот это принятие решений уходило наверх, на интегрирующий уровень. Каждый компонент должен включать в себя как можно меньше принятий решений, вот этих сценариев работы. Вместо параметризации компонентное программирование предполагает вариативность реализации.
Возникает желание сделать компонент X с кучей конфигурационных параметров? Делаем одну абстракцию и несколько разных её реализаций. Вместо одной настраиваемой. (Правда, код в реализациях будет процентов на 30 повторяться, ну и что? Это же сокрытое внутреннее устройство, оно один раз написано (по аналогии или частично даже копипастом) и годами потом используется...)

Года два назад сформулировал для себя принцип: кубики тупые и делают конкретную работу, принимает решение надсистема.

Вы описываете в точности мое представление о правильной разработке. Как это не странно :) Тем не менее. Такой подход не исключает тестов. Тесты - его обеспечивают. Как соблюдать такой "кубиковый" подход без написания тестов - я не представляю. Одного желания мало, особенно для больших объемов и многих участников. Нужно конкретное техническое контролирующее средство. Пока кроме тестов на эту роль никого не видно.

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Задачка архитекторная.
« Ответ #134 : Апрель 02, 2011, 08:47:07 pm »
Я не против тестов, поймите меня правильно. Я за них. Добавить ещё и тесты. Особенно в большом коллективе, это наверняка будет просто необходимо.

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

Я говорю о том, что надо иметь процесс, который и без систематического тестирования компонентов даёт в небольшом коллективе их высокое качество, а если к нему добавить ещё и тесты, то это вообще будет экстра-класс :)