понедельник, 19 августа 2013 г.

Второй вопрос к безмолствующей аудитории

Друзья мои!

Хочется задать вопрос.

Вот вы говорите - "UML - вчерашний день", или "UML - тяжело и не нужно".

И ещё говорите - "структурируйте код" и ещё говорите - "документируйте код".

Вам ПРАВДА удаётся так жить?

Вы РЕАЛЬНО можете жить оперируя ТОЛЬКО "голым кодом" и комментариям к нему?

А вот некоторые говорят - "нам и тесты не нужны, мы и так здорово живём".

Может быть вы просветите меня серого - КАК вам удаётся так спокойно жить?

Может быть я РЕАЛЬНО чего-то не понимаю?

"Структурировать" и "документировать" код я пытался. И НЕ РАЗ. И в разных ипостасях. То, что я вижу - "НУ НЕ РАБОТАЕТ".

Всё равно люди либо "плавают в коде", либо "неправильно его используют", либо "изобретают велосипед".

Не надо только говорить, что "мы многое помним". Я сам - МНОГОЕ помню. Я помню, МНОГОЕ, что писалось лет 10-ть назад. И всё равно - "голый код" - ПЛОХО поддаётся управлению. Это моё - УБЕЖДЕНИЕ. Разубедите меня. Может быть - я в чём-то заблуждаюсь.

P.S. Не надо только про XP или Agile. Это - "процесс". А не структурный анализ кода.

P.P.S. Не надо только про "функциональные языки". Ну или поднимаете эту тему - приведите Success Story. Да ТАКУЮ! Чтобы я от зависти умер.

P.P.P.S. Ну и ещё.. Ну поделитесь, ну хоть какими-нибудь метриками! Ну количество строк кода. Количество сущностей. Количество человек в команде. Количество прецедентов (UseCase). Ну или на худой конец количество таблиц в БД. Пожалуйста.

149 комментариев:

  1. Отвечу вопросом на вопрос: А много ли Вы знаете крупных проектов с приложенным к ним UML-диаграммами? Честно, за 8 лет стажа ни разу не встречал :) Может, потому что спецов, умеющих этот UML готовить не так уж и много? Да и нужна ли такая "документация"? Как правило классы, которые я видел на github`е довольно понятны, в противном случае пора делать рефакторинг. Посмотрите, как пример, фреймворк Yii (http://www.yiiframework.com/doc/api/) - его документация сгенерирована из комментариев к коду. Код и комментарии - этого хватает людям, которые вносят изменения по всему миру :)
    Может, применение UML показывает, что у Вас сложность проекта зашкаливает?

    ОтветитьУдалить
    Ответы
    1. Не.. Давайте БЕЗ "вопросов на вопрос"...

      ИНАЧЕ - ОТВЕТЬТЕ на вопрос про "метрики"...

      "Может, применение UML показывает, что у Вас сложность проекта зашкаливает?" - может..

      Так я потому и спрашиваю...

      Удалить
    2. "http://www.yiiframework.com/doc/api/" - не впечатляет,если честно.. :-(

      Удалить
    3. Давайте про "метрики" всё же... Вы СКОЛЬКИМ людям пытались "продать" свои наработки?

      Удалить
    4. Ох уж сразу "продать" :) Я считаю количество людей, которые этим пользуются за "покупателей". Какие метрики Вам нужны? Количество строк кода? 19Мб, Сущностей - дофига, Человек - судя по репу - больше 1000, таблиц нет.
      Не убедил? Возьмём коммерческую фирму (ЗАО "Петер-Сервис", биллинг делают), человек 800 программистов, таблиц порядка 10 000. У них более-менее грамотно разбито по подсистемам. UML не используется. Кстати, а сколько проектов Вы можете привести, где используется UML?
      P.S. Чем же Yii не впечатлил? Тем, что всё понятно? :) Ну не знаю, возьмите ядро linux...

      Удалить
  2. ядро linux ерунда в сравнении с гарантом. и потом скольким людям оно продано?

    ОтветитьУдалить
    Ответы
    1. А, понял, здесь сидят продажники :) ok, оно продано, косвенно, 90% хостинговыми компаниями. Нужны прямые продажи? Обратитесь к Oracle (RHEL) или SUSe.

      Удалить
    2. хм.. все так гордо говорят про ядро lunix как будто сами его написали :-)

      Хотя ядро linux - конечно аргумент. Мне было бы интересно узнать о том как работа организована.

      Но я вообще-то спрашивал о "собственных" проектах. В которых люди САМИ работали.

      Отсылки - а "вот там один парень делает" - здорово конечно, но - не интересно.

      Удалить
    3. Это самое масштабное, что пришло в голову :) По поводу рабочего процесса - обычный с надзирателем, описан в книге "Pro GIT".
      Собственный опыт - всё тот же "Петер-Сервис". Есть аналитики, архитекторы, разработчики, тестировщики... В общем, см. выше. Без UML прекрасно живут :) Или Вы хотели узнать что-то более конкретное?

      Удалить
    4. "аналитики, архитекторы"

      В каком виде они выдают результаты своей деятельности? В виде каких артефактов?

      Удалить
    5. Задача аналитиков выдать документ с указанием что нужно сделать, например, "добавить кнопку на третьей странице для повышения конверсии". Архитекторы/проектировщики общаются уже терминами: "расширить класс XXX, добавив поле YYY". Т.е. По идее именно им был бы нужен UML, однако, не прижился.

      Удалить
    6. Кстати, про организацию рабочего процесса. Я так понял, что у Вас всё строится на UML, а из него потом генерируется код. Сколько примерно часов было потрачено на осуществление такой технологии? Много ли людей этим пользуются? Оформлено ли это в качестве стандарта?

      Удалить
    7. "По идее именно им был бы нужен UML, однако, не прижился."

      "не прижился" и "не нужен" - разные вещи?

      Удалить
    8. "Задача аналитиков выдать документ с указанием что нужно сделать, например, "добавить кнопку на третьей странице для повышения конверсии"."

      Валидирует точность исполнения документа кто? Каким образом?

      Удалить
    9. "Сколько примерно часов было потрачено на осуществление такой технологии? "
      Много.

      "Много ли людей этим пользуются?"
      Достаточно.

      "Оформлено ли это в качестве стандарта?"
      Документы - написаны.

      Удалить
  3. http://doc.qt.digia.com/4.6/classes.html
    Алсо после всех объяснений не вижу никаких причин для UML быть понятнее классической документации.

    ОтветитьУдалить
    Ответы
    1. QTCreateFont - Creates a font ;-)

      Очень познавательно :-) Простите - не удержался.

      Подробнее про документацию - напишу отдельно.

      Удалить
  4. >QTCreateFont - Creates a font ;-)
    Откуда сиё, если не секрет?

    ОтветитьУдалить
    Ответы
    1. QFont::QFont ( const QFont & font )
      Constructs a font that is a copy of font.

      Удалить
    2. А что там ещё писать? :-)
      Судя по приведённому - это конструктор, который клонирует существующий экземпляр.
      UML-диаграмма не сделает ситуацию вокруг этого метода более ясной :-)

      Удалить
    3. "А что там ещё писать? :-)"
      Ничего не писать :-) Не тратить на это силы и время. UML - тут - да. ТОЖЕ - НИЧЕГО не добавляет.

      Удалить
    4. IMHO, написать нужно, поскольку "const QFont & font" передаётся по ссылке, а значит, может быть изменён в конструкторе.
      Кроме того, из комментария однозначно следует, для чего разработчики предназначали этот метод. А это, в свою очередь, может предотвратить его использование не по назначению. "Неправильное" в Вашей терминологии.

      Удалить
    5. " а значит, может быть изменён в конструкторе"

      не может. Там - const. Всякие const_cast и mutable - я бы не рассматривал.

      Удалить
    6. "Кроме того, из комментария однозначно следует, для чего разработчики предназначали этот метод."

      -- по-моему "самодокументируемой" сигнатуры - достаточно. Хотя конечно - "на вкус и цвет - все фломастеры разные".

      Удалить
    7. «" а значит, может быть изменён в конструкторе"
      не может. Там - const. Всякие const_cast и mutable - я бы не рассматривал.»
      -- Вы бы - не рассматривали, а разработчики сделали всё, чтобы пользователь вообще не задумывался на этот счёт.
      Не нравится? Догадались сами? - Не вопрос.
      Но есть определённые правила документирования, от которых не следует отступать, чтобы сохранить дееспособность инфраструктуры. По простому: отступил здесь, положившись на собственное восприятие очевидности - поступишь так же, когда это - недопустимо.

      Удалить
    8. Не согласен. Но спорить - далее не буду.

      Вашу позицию - я понял. И встречал её в своей практике и не раз. Может быть - вы и правы.

      Удалить
  5. NameRec:

    «И ещё говорите - "структурируйте код" и ещё говорите - "документируйте код".»
    -- Говорим не только это, не нужно утрировать...

    «Вам ПРАВДА удаётся так жить?»
    -- Да, безусловно.

    «Вы РЕАЛЬНО можете жить оперируя ТОЛЬКО "голым кодом" и комментариям к нему?»
    -- Да, РЕАЛЬНО :-)

    «А вот некоторые говорят - "нам и тесты не нужны, мы и так здорово живём".»
    -- "Некоторые" много чего говорят... :-)
    В общем случае, нужны не тесты, а полноценное тестирование.
    В некоторых случаях роль тестирования могут взять на себя тесты.

    «Может быть вы просветите меня серого - КАК вам удаётся так спокойно жить?»
    -- Задавайте конкретные вопросы.
    Но вообще-то, много в книжках описано :-)

    «Может быть я РЕАЛЬНО чего-то не понимаю?»
    -- Нельзя этого исключать...

    «"Структурировать" и "документировать" код я пытался. И НЕ РАЗ. И в разных ипостасях. То, что я вижу - "НУ НЕ РАБОТАЕТ".»
    -- Давайте подробнее: что именно у Вас "не работает".

    «Всё равно люди либо "плавают в коде", либо "неправильно его используют", либо "изобретают велосипед".»
    -- Я Вас не понял. Не "плавайте", используйте правильно и не "изобретайте велосипед".
    Наладьте обучение и контроль. Работайте над квалификацией исполнителей.

    «Не надо только говорить, что "мы многое помним". Я сам - МНОГОЕ помню. Я помню, МНОГОЕ, что писалось лет 10-ть назад. И всё равно - "голый код" - ПЛОХО поддаётся управлению.»
    -- Я до сих пор не понимаю, что такое "голый код" :-)
    Тот код, с которым приходится работать мне, вероятно, "одетый", поскольку управлять им вполне удаётся.

    «Не надо только говорить, что мы многое помним . Я сам - МНОГОЕ помню. Я помню, МНОГОЕ, что писалось лет 10-ть назад. И всё равно - голый код - ПЛОХО поддаётся управлению.»
    -- Сначала объясните: зачем здесь, в Вашем блоге, кому-то Вас в чём-то убеждать? :-)
    Непонятно - спрашивайте. А для троллинга есть политические сайты.

    «P.S. Не надо только про XP или Agile. Это - "процесс". А не структурный анализ кода.»
    -- Практически никогда не нужен структурный анализ *всего кода*.
    Требуется иметь *достаточное* представление о коде, с которым придётся взаимодействовать при решении конкретной задачи.
    Больше типовых решений - меньше типового разнообразия такого кода.

    «P.P.P.S. Ну и ещё.. Ну поделитесь, ну хоть какими-нибудь метриками! Ну количество строк кода. Количество сущностей. Количество человек в команде. Количество прецедентов (UseCase). Ну или на худой конец количество таблиц в БД. Пожалуйста.»
    -- Строки кода считать... Ну немного лень, если честно. Давайте лучше в мегабайтах. ~80 MB в 1779 модулях. Понятно, там есть комментарии, но их не больше 10%.
    Количество человек в команде ~20 программистов и 10 аналитиков и тестеров по совместительству.
    Количество прецедентов никто никогда не считал, поскольку для нас это - неоперационный термин.
    Количество таблиц в БД одного из проектов - 561.

    ОтветитьУдалить
    Ответы
    1. "Но вообще-то, много в книжках описано"

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

      Удалить
    2. Считаем, что я погорячился.

      Задам вопрос. Можно?

      В каких книжках? Можно кратенький список?

      А то - может - я не те книжки читал.

      Удалить
    3. "-- Сначала объясните: зачем здесь, в Вашем блоге, кому-то Вас в чём-то убеждать? :-)
      Непонятно - спрашивайте. А для троллинга есть политические сайты."

      Давайте не будем разговаривать в таком ключе? Хорошо? Тем более, что по многим моментам - Вы мне очень помогли.

      Я никого не "троллю". Не хотите - не читайте, не хотите - не отвечайте. Тут дело - взаимное. Я пишу - вы читаете или нет, я спрашиваю - вы отвечаете или нет.

      Я могу заблуждаться или быть не правым, но это не значит, что я кого-то "троллю". Хорошо?

      Удалить
    4. "и *10 аналитиков* и тестеров по совместительству."

      Если это именно "аналитики", а не только "тестеры", то это может быть МНОГОЕ объясняет.

      Удалить
    5. "~80 MB в 1779 модулях."

      По мне - немного. Хотя я могу не понимать всего контекста.

      Удалить
    6. «Задам вопрос. Можно?
      В каких книжках? Можно кратенький список?»
      -- Извольте, на вскидку - то, что я рекомендую своим студентам:
      "П.Гудлиф. Ремесло программиста. Практика написания хорошего кода"
      "Г.Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. Второе издание"
      "Д.Спольски. Джоэл о программировании"
      "К.Бек. Экстремальное программирование"
      "М.Фаулер. Архитектура корпоративных программных приложений"
      "Н.Н.Непейвода, И.Н.Скопин. Основания программирования"
      "Н.Вирт. Алгоритмы + Структуры данных = Программы"
      "Н.Вирт. Систематическое программирование. Введение"
      "С.Макконнелл. Совершенный код"

      Удалить
    7. «"и *10 аналитиков* и тестеров по совместительству."
      Если это именно "аналитики", а не только "тестеры", то это может быть МНОГОЕ объясняет.»
      -- Да. Именно так. Это одновременно И аналитики И тестеры. Намеренно и никак иначе.

      Удалить
    8. «"~80 MB в 1779 модулях."
      По мне - немного. Хотя я могу не понимать всего контекста.»
      -- Вот удивительно: Вы признаёте, что можете не понимать *всего* контекста, и одновременно утверждаете, что "по Вам - немного" :-)
      Мне проще: я не знаю, понимаете Вы или нет и достаточно ли понимаю я Вас. Поэтому, я воздерживаюсь от оценочных суждений.

      Удалить
    9. ""П.Гудлиф. Ремесло программиста. Практика написания хорошего кода"
      "Н.Н.Непейвода, И.Н.Скопин. Основания программирования"
      "

      -- эти книги - я не читал.

      "
      "Д.Спольски. Джоэл о программировании"
      "К.Бек. Экстремальное программирование"
      "М.Фаулер. Архитектура корпоративных программных приложений"
      "Н.Н.Непейвода, И.Н.Скопин. Основания программирования"
      "С.Макконнелл. Совершенный код""

      - это из моего списка "любимых книг" или "must read".

      Удалить
    10. "Да. Именно так. Это одновременно И аналитики И тестеры. Намеренно и никак иначе."

      Сделайте одолжение. Можете рассказать об их должностных инструкциях?

      Удалить
    11. "Вот удивительно: Вы признаёте, что можете не понимать *всего* контекста, и одновременно утверждаете, что "по Вам - немного" :-)"

      В ТОМ КОНТЕКСТЕ, как Я ПОНИМАЮ - немного. Но я - сомневаюсь, что контекст правильный. Посему - и оговорился.

      Ведь термин "модуль" - не определён.

      А если на Mb ТОЛЬКО ориентироваться, то - НЕМНОГО. Опять же - по МОЕМУ пониманию. У "меня" - БОЛЬШЕ Mb кода. Но опять же - могу ошибаться.

      Удалить
    12. "Мой список книг" - http://18delphi.blogspot.com/2013/03/blog-post_2036.html

      Понятно, что он - не полный.

      Удалить
    13. «"Да. Именно так. Это одновременно И аналитики И тестеры. Намеренно и никак иначе."
      Сделайте одолжение. Можете рассказать об их должностных инструкциях?»
      -- Да, пожалуйста. Что Вас конкретно интересует?
      Идея следующая. Аналитик у нас непосредственно общается с пользователем и получает от него информацию, которая, после обсуждения с ведущим инженером проекта, иногда - архитектором, преобразуется в постановку задачи, которую реализует программист.
      Тестирование производится тем же аналитиком, что писал постановку, поскольку вокруг нет никого, кто лучше него представляет проблемы пользователя.
      Ну, а дальше - по Agile/KANBAN...

      Удалить
    14. "Аналитик у нас непосредственно общается с пользователем"
      "Тестирование производится тем же аналитиком, что писал постановку, поскольку вокруг нет никого, кто лучше него представляет проблемы пользователя."

      Понятно. Спасибо. Тогда это - действительно МНОГОЕ объясняет.

      Удалить
    15. «Ведь термин "модуль" - не определён.»
      -- Как это не определён? Я использую только стандартную терминологию.
      То, что перечисляется в списке uses - модули и есть...

      «А если на Mb ТОЛЬКО ориентироваться, то - НЕМНОГО. Опять же - по МОЕМУ пониманию. У "меня" - БОЛЬШЕ Mb кода. Но опять же - могу ошибаться.»
      -- Просите, а *какого* кода у Вас больше? ;-)
      Тот код, о котором пишу я - написан вручную. Нашими программистами или нет - несущественно.
      Как следует из Ваших предыдущих постов, Вы используете кодогенерацию и подмешивание. Второе - в сущности, автоматизированное (include) *дублирование* кода, которое у нас отсутствует.
      Далее, условной компиляцией мы пользуемся совершенно не так, как очевидно, принято у Вас в компании. Это означает, что у нас код, расположенный в разных ветках IFDEF отсутствует.
      Далее, я перечислил *только* исходные тексты на Object Pascal. XML-аналоги DFM - не учитывались, как и Python-код, которого также немало.

      Удалить
    16. "То, что перечисляется в списке uses - модули и есть..."
      -- значит я правильно понял контекст.

      "Тот код, о котором пишу я - написан вручную. Нашими программистами или нет - несущественно."
      -- да это так.

      "Второе - в сущности, автоматизированное (include) *дублирование* кода, которое у нас отсутствует."
      -- это - правда. Но это - "малая толика". И это сравнимо с "шаблонами C++".

      "Далее, условной компиляцией мы пользуемся совершенно не так, как очевидно, принято у Вас в компании. Это означает, что у нас код, расположенный в разных ветках IFDEF отсутствует."
      -- вот это я не очень понял.

      "XML-аналоги DFM - не учитывались"
      -- я их тоже не учитываю.

      "как и Python-код, которого также немало"
      -- жаль, что вы его не посчитали.

      Удалить
    17. "то, что я рекомендую своим студентам"

      Можно ещё вопрос?

      Вы ГДЕ и ЧТО преподаёте?

      Если не секрет.

      Можно послушать ваши лекции? :-) Правда - интересно.

      Удалить
    18. "Второе - в сущности, автоматизированное (include) *дублирование* кода, которое у нас отсутствует."

      -- в Mb это кстати НЕ ВХОДИТ. Входит ТОЛЬКО в "количество строк". Но ведь "количество строк" - мы не обсуждаем.

      Удалить
    19. «"как и Python-код, которого также немало"
      -- жаль, что вы его не посчитали.»
      -- Да нет, я сделал это намеренно :-)
      Не понятно, как Вы будете сопоставлять код на Python коду на Pascal...

      «"Второе - в сущности, автоматизированное (include) *дублирование* кода, которое у нас отсутствует."
      -- это - правда. Но это - "малая толика". И это сравнимо с "шаблонами C++".»
      -- Где? В бинарном коде? - Да, согласен.
      А вот "строчек кода" это добавит пропорционально тому, насколько часто Вы используете подмешивание ;-)

      «"Далее, условной компиляцией мы пользуемся совершенно не так, как очевидно, принято у Вас в компании. Это означает, что у нас код, расположенный в разных ветках IFDEF отсутствует."
      -- вот это я не очень понял.»
      -- А что здесь непонятного?
      У нас в модулях практически отсутствует код, не включаемый в приложение.
      Можно не включить модуль, но опять же, редко для этого используется условная компиляция (хотя и бывает такое).
      Как я понял, в процессе кодогенерации у Вас автоматически производятся включения, описанные в шаблонах (хотя могу и ошибаться, поскольку разбираться в Ваших шаблонах у меня не было достаточного времени :-)).
      Вот мне и непонятно: что и как Вы измеряете в отношении строчек кода.

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

      Удалить
    20. "Более адекватной метрикой был бы размер постановки (в наших терминах), в которой и описано то, что следует обеспечить в проекте."

      -- Согласен. Я потому и говорил изначально про "прецеденты" (UseCase) ну или их аналоги.

      Удалить
    21. "Не понятно, как Вы будете сопоставлять код на Python коду на Pascal..."
      -- вы считаете, что они несопоставимы? почему? Можно узнать? Интересно.

      Удалить
    22. "А вот "строчек кода" это добавит пропорционально тому, насколько часто Вы используете подмешивание ;-)"
      -- про "строчки кода", я вроде уже пояснил. Мы же вроде про Mb говорили. По-крайней мере - "строчки кода" - вы не приводили. Значит - их и обсуждать нечего. Мне так кажется.

      Удалить
    23. "Ну и наконец, я не считаю метрику "количество строчек кода" адекватной для оценки сложности проекта."
      -- Это - ПЛОХАЯ метрика. Согласен. Но лучше - ПЛОХАЯ, чем никакая.
      Хотя "размер постановки" - конечно - СИЛЬНО ЛУЧШЕ. Если он оценен.

      Удалить
    24. «"Второе - в сущности, автоматизированное (include) *дублирование* кода, которое у нас отсутствует."
      -- в Mb это кстати НЕ ВХОДИТ. Входит ТОЛЬКО в "количество строк". Но ведь "количество строк" - мы не обсуждаем.»
      -- Изначально Вы говорили о строчках кода, потом мы переключились на мегабайты.
      Мне сложно уследить, о чём Вы говорите в данном конкретном случае.
      Относительно "метрик" я высказался выше. В разных подходах к программированию будет существенно разное количество и строчек и мегабайт.

      «"то, что я рекомендую своим студентам"
      Можно ещё вопрос?
      Вы ГДЕ и ЧТО преподаёте?
      Если не секрет.
      Можно послушать ваши лекции? :-)»
      -- Да не секрет...
      По совместительству (это хобби) я преподаю два спецкурса на Факультете Прикладной Математики Кубанского Госуниверситета.
      "Технология разработки программного обеспечения" и "Разработка сложных приложений с БД".
      Курсы практические, т.е. обозначается задача, в течение семестра она решается с привлечением литературы и консультаций. Стараюсь устраивать семинары...
      Лекции форматом курса не предусмотрены, в целом, процесс обучения это very-very-lite вариант подготовки нового сотрудника в соей организации.

      Удалить
    25. "Курсы практические, т.е. обозначается задача, в течение семестра она решается с привлечением литературы и консультаций. Стараюсь устраивать семинары..."
      -- "бумажные" или "электронные" документы есть?

      Удалить
    26. "-- Изначально Вы говорили о строчках кода, потом мы переключились на мегабайты.
      Мне сложно уследить, о чём Вы говорите в данном конкретном случае."

      -- ну вы ответили только про Mb. Так что я думаю, что правильнее было бы оставаться в этом контексте.

      Удалить
    27. «"Ну и наконец, я не считаю метрику "количество строчек кода" адекватной для оценки сложности проекта."
      -- Это - ПЛОХАЯ метрика. Согласен. Но лучше - ПЛОХАЯ, чем никакая.
      Хотя "размер постановки" - конечно - СИЛЬНО ЛУЧШЕ. Если он оценен.»
      -- Да, можно. Но не сейчас, по худому WiFi из отеля... :-)

      Удалить
    28. "-- Да, можно. Но не сейчас, по худому WiFi из отеля... :-)"
      Не понял :-(

      Удалить
    29. «"Курсы практические, т.е. обозначается задача, в течение семестра она решается с привлечением литературы и консультаций. Стараюсь устраивать семинары..."
      -- "бумажные" или "электронные" документы есть?»
      -- Да, есть. Но не с собой :-)
      Не ожидал, что в отпуске они мне понадобятся...

      Удалить
    30. Не - ну я не тороплюсь. Главное, что в принципе есть. Уже - радует. Что есть теоретическая возможность почитать.

      Удалить
    31. «"-- Да, можно. Но не сейчас, по худому WiFi из отеля... :-)"
      Не понял :-(»
      -- Ну, я сейчас в отпуске, в отеле, в Украине :-)
      Соединение с офисом у меня через WiFi, который постоянно падает.
      Качать мегабайты отчёта со *всей* постановкой по проекте (хотя это текст, в основном) - буду ждать до утра... :-)

      Удалить
    32. Некоторые люди прочитав это - http://18delphi.blogspot.com/2013/08/mvc.html

      Пишут что-то вроде:
      "Вам нужно преподавать. Интересный способ изложения. Очень интересный. Спасибо!"
      -- значит - до кого-то - донёс. :-)

      Жаль, что таких - пока - единицы.

      Удалить
    33. «"Не понятно, как Вы будете сопоставлять код на Python коду на Pascal..."
      -- вы считаете, что они несопоставимы? почему? Можно узнать? Интересно.»
      -- Ну просто потому, что Python очень высокоуровневый интерпретируемый язык с динамической типизацией.
      Грубо утрируя: одна строчка на Python соответствует 5-6 на Pascal, но не всегда.
      Наверное, приблизительное сопоставление в каждом конкретном случае дать можно, но это будет слишком уж "от фонаря".
      Известные мне примеры решений (когда они есть и на Pascal и на Python) дают очень большой разброс в объёме кода, поэтому я не возьмусь сравнивать.

      Удалить
    34. "Качать мегабайты отчёта со *всей* постановкой по проекте (хотя это текст, в основном)"
      -- теперь - понял. Спасибо.

      Удалить
    35. "Ну просто потому, что Python очень высокоуровневый интерпретируемый язык с динамической типизацией.
      Грубо утрируя: одна строчка на Python соответствует 5-6 на Pascal, но не всегда."
      -- не стал бы я его так переоценивать :-)

      "Известные мне примеры решений (когда они есть и на Pascal и на Python) дают очень большой разброс в объёме кода, поэтому я не возьмусь сравнивать."
      -- а можно какой-нибудь пример? если не сложно.

      Удалить
    36. «Некоторые люди прочитав это - http://18delphi.blogspot.com/2013/08/mvc.html»
      -- Я, разумеется, читал этот пост.
      Скажем так... У меня впечатления амбивалентные.
      С одной стороны, я отдаю себе отчёт в том, что написанное Вами следует воспринимать в контексте, что в итоге "надо всем над этим" у Вас будет находиться UML.
      С другой стороны, мне для описания того, что обозначено в статье, не пришлось бы писать код вообще.
      Это и даёт мне основания полагать, что "строчки кода" и объём этого кода в мегабайтах - неадекватные метрики для оценки сложности системы.
      С третьей стороны, чужой опыт всегда полезен, уже хотя бы потому, что он - опыт :-)

      Удалить
    37. А некоторые ещё говорят - "UML хорош хотя бы тем, что в нём всё по прецедентам (UseCase) разложено".

      Но таких - тоже единицы.

      Удалить
    38. "С одной стороны, я отдаю себе отчёт в том, что написанное Вами следует воспринимать в контексте, что в итоге "надо всем над этим" у Вас будет находиться UML."
      -- вот СОВСЕМ необязательно. Эти идеи были реализованы ещё ДО UML. А на UML Они легли уже после переосмысления проблем.

      "С другой стороны, мне для описания того, что обозначено в статье, не пришлось бы писать код вообще."
      -- можете пояснить? Как бы вы это сделали? В чём я не прав?

      "Это и даёт мне основания полагать, что "строчки кода" и объём этого кода в мегабайтах - неадекватные метрики для оценки сложности системы."
      -- вот здесь я не понял - откуда такой вывод.

      "С третьей стороны, чужой опыт всегда полезен, уже хотя бы потому, что он - опыт :-)"
      -- это -да.

      Удалить
    39. «"Известные мне примеры решений (когда они есть и на Pascal и на Python) дают очень большой разброс в объёме кода, поэтому я не возьмусь сравнивать."
      -- а можно какой-нибудь пример? если не сложно.»
      -- Вы имеете ввиду сейчас законченное решение на Pascal и соответствующее ему - на Python?
      В принципе, можно поискать, но опять же, когда вернусь...
      У нас есть примеры кода, когда мы переписывали его с Pascal на Python, но... Тут те же ограничения, что и у Вас. Проприетарность...
      Что точно могу сделать - это верифицировать оценки. Хотя и с поправкой на то, что при переводе ещё добавлялась функциональность...

      Удалить
    40. "Хотя и с поправкой на то, что при переводе ещё добавлялась функциональность..."
      -- а вот этого я стараюсь избегать.
      Моё правило - сначала - перенос, а потом только "добавление функциональности" или рефакторинг.

      И ЛУЧШЕ после написания тестов. Если таковых не было.

      Если конечно интересно моё мнение.

      Удалить
    41. "язык с динамической типизацией"

      Duck Typing? Как КОНЦЕПЦИЯ - мне это нравится. Но я всё же предпочитаю проверку типов компилятором. Хотя ИМХО - одно другому - не противоречит.

      Могу ошибаться.

      Удалить
    42. «Duck Typing? Как КОНЦЕПЦИЯ - мне это нравится. Но я всё же предпочитаю проверку типов компилятором. Хотя ИМХО - одно другому - не противоречит.»
      -- Ну да :-) Я просто не люблю англицизмы...
      Мне это не очень нравится и как концепция, но против фактов "не попрёш" - производительность труда это увеличивает весьма существенно, хотя обратная сторона - провоцирует быдлокодинг. Но есть эффективные способы борьбы с этим - в книжках они описаны достаточно подробно, а в некоторых случаях это можно даже подстегнуть.
      При надлежащем внимании к процессу управления использование скрипт-языков существенно удешевляет разработку, поскольку для большинства задач не требуется высокая квалификация, а программировать - проще. Да и тема Вашего любимого TDD в Python раскрыта весьма существенно.

      Удалить
  6. «Давайте не будем разговаривать в таком ключе? Хорошо?»
    -- Хорошо, будем считать, что я Вас неправильно понял :-)

    ОтветитьУдалить
    Ответы
    1. "Хорошо, будем считать, что я Вас неправильно понял :-)"

      Ок. Спасибо.

      Удалить
  7. "Вы имеете ввиду сейчас законченное решение на Pascal и соответствующее ему - на Python"
    -- ну да.

    "Проприетарность"
    -- понимаю. Знакомо. Потому и не настаиваю.

    ОтветитьУдалить
  8. «"С другой стороны, мне для описания того, что обозначено в статье, не пришлось бы писать код вообще."
    -- можете пояснить? Как бы вы это сделали? В чём я не прав?»
    -- Начнём с того, что Вы во всём правы.
    У Вас есть инструмент, и Вы используете его так, как оно было задумано.
    Что касается меня, то я воспользовался бы *нашим* дизайнером.
    Разместил бы на разных фреймах или модулях данных (определяется тем, нужны ли визуальные компоненты) то, что требуется мне в контексте каждого элемента управления.
    Ну например, Вы сказали, что нам "повезло" с редактором и он умеет всё, кроме печати и экспорта (я упрощаю для пояснения). - Я бросил бы на отдельный фрейм этот "волшебный" редактор.
    Приделал бы нужные панели инструментов, ну и прочие элементы оформления. Сохранил бы фрейм в XML. Это интерпретированный DFM, т.е. по XML всегда можно получить DFM, а по DFM - XML.
    Вероятно (хотя и не обязательно, поскольку это можно сделать в любой момент) я поступил бы аналогичным образом и с остальными визуальными элементами управления, поскольку в дальнейшем это даст возможность их повторного использования.
    У меня получился бы набор XML.
    Далее, я создал бы в дизайнере форму, на которой расположил бы компоненты из только что созданных XML.
    Ну и потом... Я же не знаю, как Вы собирались развивать то, что начали описывать...
    Для простоты, предварительно, я создал бы класс, который загружал бы форму со всем хозяйством. Загрузка выглядела бы так:
    LoadComponent(Self, UID_MyForm);
    Где UID_MyForm - GUID, размещённый в XML - его формирует наша программа-дизайнер.
    Функциональность печати документа я сделал бы обработчиком, который построил рядом:
    ValidateComponentRef(Self.EditorFrame);
    TDocumentEditor_PrintCommand(form.EditorFrame.Editor);
    Ну, где-то так...

    ОтветитьУдалить
    Ответы
    1. "Что касается меня, то я воспользовался бы *нашим* дизайнером."
      -- дизайнер у нас был, но он потом переехал в UML.

      Удалить
    2. "Ну и потом... Я же не знаю, как Вы собирались развивать то, что начали описывать..."
      -- не успел ещё.

      Удалить
    3. "Это интерпретированный DFM, т.е. по XML всегда можно получить DFM, а по DFM - XML"
      -- логично.

      Удалить
    4. И вообще...

      Если я правильно понял - то, что вы написали - ОЧЕНЬ похоже на то, что я пытался описать. Хотя - возможно - я льщу себе.

      Удалить
    5. «"Что касается меня, то я воспользовался бы *нашим* дизайнером."
      -- дизайнер у нас был, но он потом переехал в UML.»
      -- А кто им пользовался? Программисты? Или как у нас - тестеры-аналитики?

      Удалить
    6. "Программисты? Или как у нас - тестеры-аналитики?"
      -- у нас к сожалению нет РОВНО такой РОЛИ.

      Удалить
    7. «"Это интерпретированный DFM, т.е. по XML всегда можно получить DFM, а по DFM - XML"
      -- логично.»
      -- Да, мне казалось - логично :-)
      В свете этого я и не понимаю сути Ваших претензий к DFM.
      DFM в моём понимании отвечает на вопрос "что" (нужно), а за вопрос "как" (это обеспечить) отвечает код.

      «Если я правильно понял - то, что вы написали - ОЧЕНЬ похоже на то, что я пытался описать.»
      -- Ну... Мне трудно судить.
      Именно поэтому я с интересом наблюдаю за Вашими публикациями.
      Вот только, возможно - пока, не разделяю Вашего отношения к UML, который я, кстати, преподаю на третьем курсе.
      Аналитики передают мне отношения между сущностями предметной области в виде диаграмм классов UML. Они сами его рисуют. И это - удобно.
      Но генерировать код из него... Через такие криптованные шаблоны... Ну, я пока не готов :-) Как бы ни просто было их править тому *кто разобрался*, он должен сначала в них разобраться, а потом бороться с ними, когда кодогенератор нагенерирует некомпилирующийся код или в результате кодогенерации будет не то, что требуется.
      Это лишние накладные расходы и я не готов с ними мириться, даже ощущая прелесть графического представления архитектуры.
      Да и повторюсь - чаще всего это представление *не необходимо*.

      Удалить
    8. Если было бы так, то может быть был бы совсем другой разговор.

      Удалить
    9. "Через такие криптованные шаблоны..."
      -- это - "исторически сложилось", а не "так задумывалось". Мы работаем над этим.

      Удалить
    10. «"Программисты? Или как у нас - тестеры-аналитики?"
      -- у нас к сожалению нет РОВНО такой РОЛИ.»
      -- Формы для объектов предметной области у нас "рисуют" аналитики.

      Удалить
    11. "когда кодогенератор нагенерирует некомпилирующийся код или в результате кодогенерации будет не то, что требуется."
      -- вот такого ПРАКТИЧЕСКИ никогда не случалось.

      Удалить
    12. "Формы для объектов предметной области у нас "рисуют" аналитики."
      -- ну это реально здорово :-)

      Удалить
    13. "Это лишние накладные расходы и я не готов с ними мириться, даже ощущая прелесть графического представления архитектуры."
      -- вот тут пока не соглашусь, что "лишние".

      Удалить
    14. «"Через такие криптованные шаблоны..."
      -- это - "исторически сложилось", а не "так задумывалось". Мы работаем над этим.»
      -- Да, в принципе, просматривается техническое решение...
      Можно тот же Python использовать - это существенно упростит жизнь...
      Но Александр... :-)
      Дополнительный шаг - обработка шаблонов никуда не денется, поскольку это имманентно присущее UML свойство - он (UML) язык описания предметной области, язык пректирования, но *не программирования*.
      Можно сделать шаблоны дружелюбнее, но от связи кода с диаграммой не уйдёшь, если Вы ставите на первое место диаграмму. Шаблоны - центральная часть этой связи.
      Тем более, есть другой путь. Он вынуждает работать в других понятиях (а Вы разве не занимаетесь тем же самым?), но он ориентирован на код. Вот Виктор Вам про Idea писал - в принципе - очень интересное решение. И UML там есть, правда, на вторых ролях, не так как у Вас...
      Ну и IDE... Развитие этого направления может позволить генерировать UML по *существующему* коду. Нам ведь "ехать", а не "шашечки"? Нужно построить графическое представление - а вот оно!
      Но понятно, пока это пока только в проекте...

      Удалить
    15. «"когда кодогенератор нагенерирует некомпилирующийся код или в результате кодогенерации будет не то, что требуется."
      -- вот такого ПРАКТИЧЕСКИ никогда не случалось.»
      -- Восхищаюсь Вашему самоконтролю :-)
      Я бы так точно не смог.
      Но совершенно понятно, что шаблоны можно сделать дружелюбнее...

      Удалить
    16. "Но совершенно понятно, что шаблоны можно сделать дружелюбнее.."
      -- СОВЕРШЕННО ПОНЯТНО. Тут вы правы.

      Удалить
    17. «"Это лишние накладные расходы и я не готов с ними мириться, даже ощущая прелесть графического представления архитектуры."
      -- вот тут пока не соглашусь, что "лишние".»
      -- А я - не настаиваю :-)
      У Вас сложилась система, она складывалась годы, она работает, наконец. Я не предлагаю избавляться от части фундамента этой системы. И не говорю, что эта часть - избыточна.
      В рамках построенной вами (не только Вами) инфраструктуры она может быть органичной и даже - необходимой.
      Я просто хочу сказать, что другой путь - есть.
      Вкратце я его обозначил.

      Удалить
    18. "Дополнительный шаг - обработка шаблонов никуда не денется, поскольку это имманентно присущее UML свойство - он (UML) язык описания предметной области, язык пректирования, но *не программирования*."
      -- а вот тут - вы ошибаетесь.

      1. Это и "программирование".
      2. И это - НЕОБХОДИМЫЙ шаг. А не ДОПОЛНИТЕЛЬНЫЙ. Этот шаг позволяет параметризовывать код "до его написания".

      Удалить
    19. "Я просто хочу сказать, что другой путь - есть."
      -- конечно :-) и его - мы тоже - прошли.

      Удалить
    20. "Но совершенно понятно, что шаблоны можно сделать дружелюбнее..."
      -- и я - работаю над этим :-) но не в сторону Python, а в сторону Forth.

      Удалить
    21. «2. И это - НЕОБХОДИМЫЙ шаг. А не ДОПОЛНИТЕЛЬНЫЙ. Этот шаг позволяет параметризовывать код "до его написания".»
      -- Надеюсь, Вы допускаете существование иных способов это сделать? ;-)
      Программирование ведь - не православие: есть много разных путей к желаемой цели... :-)

      Удалить
    22. "Ну и IDE... Развитие этого направления может позволить генерировать UML по *существующему* коду. Нам ведь "ехать", а не "шашечки"? Нужно построить графическое представление - а вот оно!
      Но понятно, пока это пока только в проекте..."

      -- у вас в проекте? Или у сторонних разработчиков?

      Удалить
    23. «"Но совершенно понятно, что шаблоны можно сделать дружелюбнее..."
      -- и я - работаю над этим :-) но не в сторону Python, а в сторону Forth.»
      -- Решили заменит один инструмент шифрования на другой? ;-)
      Нет-нет, я е против Forth, просто он слишком уж специфичен, хотя и хорошо подходит для своих DSL. Но есть более привычные инструменты, делающее это не хуже...
      Всё сказанное - моё личное IMHO.

      Удалить
    24. "-- Надеюсь, Вы допускаете существование иных способов это сделать? ;-)"
      -- КОНЕЧНО! Я же писал - "UML - Не догма". Как и TDD - не догма. Я стараюсь делиться своим опытом и ЧЕРПАТЬ чужой. Как например ваш.

      Удалить
    25. «"Ну и IDE... Развитие этого направления может позволить генерировать UML по *существующему* коду. Нам ведь "ехать", а не "шашечки"? Нужно построить графическое представление - а вот оно!
      Но понятно, пока это пока только в проекте..."
      -- у вас в проекте? Или у сторонних разработчиков?»
      -- У нас? - Нет :-)
      Мы не придаём UML такого значения.
      Думаю, это появится в сторонних IDE или плагинах к ним. Eclipse, NetBeans, Idea.
      Да кое-что, насколько мне известно, и уже есть...

      Удалить
    26. " хотя и хорошо подходит для своих DSL. "
      -- вот именно.

      Удалить
    27. "Думаю, это появится в сторонних IDE или плагинах к ним"
      -- вот тут - я не такой оптимист как вы. Хотя - кто знает...

      Удалить
    28. «"Я просто хочу сказать, что другой путь - есть."
      -- конечно :-) и его - мы тоже - прошли.»
      -- Ну... Не хотите же Вы сказать, что уже прошли *все* альтернативные пути, в которых не придаётся такого значения UML? ;-)

      Удалить
  9. "Решили заменит один инструмент шифрования на другой? ;-)"

    -- по-моему - вы не правы. Я вот считаю Python "инструментом шифрования". Но не навязываю такого мнения.

    НО! http://18delphi.blogspot.com/2013/07/blog-post_196.html - это - FORTH.

    ОтветитьУдалить
    Ответы
    1. «"Решили заменит один инструмент шифрования на другой? ;-)"
      -- по-моему - вы не правы. Я вот считаю Python "инструментом шифрования". Но не навязываю такого мнения.»
      -- Ну, в Python отсутствует такой элемент шифрования, как обратная польская нотация :-)

      Удалить
    2. "Ну, в Python отсутствует такой элемент шифрования, как обратная польская нотация :-)"
      -- это - правда. Но ОПЗ - очень быстро преодолевается.

      ДА и не всегда она плоха. Она часто соответствует "человеческой природе". Сначала - данные. Потом - действия с ними.

      Но это опять же моё ИМХО.

      Удалить
    3. "Не хотите же Вы сказать, что уже прошли *все* альтернативные пути, в которых не придаётся такого значения UML? "
      -- нет конечно. Но нельзя же всё время метаться и "испытывать различные пути". Надо в итоге что-то выбрать. Мы (пока) выбрали UML.

      Удалить
    4. Control.Height
      -- это ли не пример ОПЗ?

      Удалить
    5. Тут я отчасти опираюсь на статью Хоор "Обработка записей".

      Удалить
    6. http://qnx.org.ru/forum/index.php?topic=499
      Хоор К. Обработка записей. // В кн.: Языки программирования. М.: Мир, 1972

      Удалить
    7. «"Не хотите же Вы сказать, что уже прошли *все* альтернативные пути, в которых не придаётся такого значения UML? "
      -- нет конечно. Но нельзя же всё время метаться и "испытывать различные пути". Надо в итоге что-то выбрать. Мы (пока) выбрали UML.»
      -- Ваше "пока" внушает надежду.
      Какое-то время назад я объявил для себя мораторий на комметрарии в Ваш блог, поскольку у меня сложилось впечатление о Вас, как о некоем евангелисте, открывшем для себя Священный Грааль и стремящегося распространить "знание" по миру.
      То, что вы (Вы и Ваша компания) выбрали UML - совершенно замечательно. Если Ваш подход в итоге окажется конструктивным - у вас появятся последователи. Если нет... Надеюсь, Вы расскажете нам о вашем опыте, поскольку даже опыт неудачный - архиполезен.
      Мне же хтелось бы получить более полное представление о вашей методологии, поэтому я - Ваш внимательный читатель...

      Удалить
    8. «Control.Height
      -- это ли не пример ОПЗ?»
      -- Ну... :-) После литра "Микуличинского" - медового та свiтлого я вполне с Вами соглашусь :-D
      Но по трезвому - вряд ли...

      Удалить
    9. «Тут я отчасти опираюсь на статью Хоор "Обработка записей".»
      -- Я совершенно не склонен глубоко обсуждать достоинства и недостатки обратной польской нотации.
      Впрочем... Будете в Краснодаре - дайте мне знать... У нас есть ряд кабаков, где подают прекрасное пиво - мы можем обсудить, и обратную польскую запись и Путина, если пожелаете... :-D

      Удалить
    10. "поскольку у меня сложилось впечатление о Вас, как о некоем евангелисте, открывшем для себя Священный Грааль и стремящегося распространить "знание" по миру."

      1. Я конечно "неизлечимый евангелист". Но не такой "неизлечимый" как вы думаете.
      2. Я "евангелирую" по-жизни. В основном "в курилке". И далеко не только UML.
      3. UML я для себя не "открыл". Я его "прожил". И потратил лет 8-мь жизни.
      4. Вы наверное не очень внимательно читали меня "серебряную" пулю - я не открыл. Про UML (в частности) я НЕ РАЗ писал - "это не догма".
      5. Я всегда стараюсь слушать и анализировать "обратную связь". И ГОТОВ признавать свои ошибки.
      6. Путина - не очень хочу обсуждать. Незачем. Мы с вами тут ничего не изменим.
      7. Насчёт "неудачности" опыта - хотелось бы верить, что он всё же будет "удачен".
      8. Собственно я и блог завёл потому, что "в курилке" стало скучно "евангелировать".
      9. Я САМ написал много библиотек и фреймворков. Коллеги не дадут соврать. А они это - читают. Другое дело, что я что-то "продал" удачно, а что-то не "продал".

      Удалить
    11. «8. Собственно я и блог завёл потому, что "в курилке" стало скучно "евангелировать".»
      -- В таком случае мне остаётся Вам пожелать не разочароваться...

      Удалить
    12. "В таком случае мне остаётся Вам пожелать не разочароваться..."

      Это прощание или напутствие? :-)

      Понятное дело - практика - "критерий истины" :-)

      Если никто - не заинтересуется - я буду КОНЕЧНО расстроен. Но не разочарован. Мне кажется. Хотя - время покажет.

      Удалить
    13. «Это прощание или напутствие? :-)»
      -- Ни первое, ни второе :-)
      Из Ваших комментариев у меня сложилось ощущение, что Вы ждёте одобрения и легко обижаетесь.
      Если я не ошибся в сути (с формой можно спорить, но я не стану), то такое восприятие может легко привести к разочарованию в окружающем мире, в "нежелании" окружающих внять Вашему опыту и следовать ему. Негативное отношение к "евангелистам" (Вы первый упомянули это слово по отношению к создателям UML, "неожиданно" оказавшимися сотрудниками Rational Software)вполне естественно в сети.

      «Понятное дело - практика - "критерий истины" :-)»
      -- Это общие слова Александр... Это - ни о чём...

      «Если никто - не заинтересуется - я буду КОНЕЧНО расстроен. Но не разочарован. Мне кажется. Хотя - время покажет.»
      -- Заинтересовались. Продолжайте.
      Но пока не ждите аплодисментов. Потому, что *пока* - рано.

      Удалить
    14. "и легко обижаетесь."
      -- ВООБЩЕ не обижаюсь :-)

      "Вы ждёте одобрения"
      -- конечно :-) Жду. Если его нет - ищу проблемы в себе :-)

      "Но пока не ждите аплодисментов."
      -- да и не ждал :-) но многое для себя понял :-)

      Удалить
    15. «"и легко обижаетесь."
      -- ВООБЩЕ не обижаюсь :-)»
      -- Напрасно Вы это сказали... :-(
      Ну да ладно, я совершенно не собираюсь углубляться в эту тему.

      «"Вы ждёте одобрения"
      -- конечно :-) Жду. Если его нет - ищу проблемы в себе :-)»
      -- Идеологически выдержанный ответ... :-)
      Личность многогранна - важно знать, где искать...
      Но не обращайте здесь на меня внимания.
      Смысл того, что я сказал в этом фрагменте можно раскрыть в объёме полумегабайта текста, но этот текст не укладывается в тематику Вашего блога...

      Удалить
    16. "Это общие слова Александр... Это - ни о чём..."

      "менторство".. ну да ладно :-) сам - грешу :-) не хочется ругаться.. да и незачем... мы все - ВЗРОСЛЫЕ люди.. глупо друг друга воспитывать.. :-)

      "с формой можно спорить" - форма повествования? Или "стиль жизни"? Да - я "программист по-жизни".. Как раньше был "альпинистом" по-жизни :-)

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

      Кстати говоря про "анонимов" - я не имел в виду вас. Вы всё ПО ДЕЛУ пишете. Хотя и не всегда "приятное". Но это - нормально.

      Удалить
    17. "-- Напрасно Вы это сказали... :-(
      Ну да ладно, я совершенно не собираюсь углубляться в эту тему."

      Жаль.. Видимо не "на волне".

      "Но не обращайте здесь на меня внимания."
      Зря вы так. Я вас внимательно слушаю. Вы хороший читатель и писатель.

      "Смысл того, что я сказал в этом фрагменте можно раскрыть в объёме полумегабайта текста, но этот текст не укладывается в тематику Вашего блога..."
      Заинтриговали конечно :-)

      Удалить
    18. «"Это общие слова Александр... Это - ни о чём..."
      "менторство".. ну да ладно :-) сам - грешу :-)»
      -- Да, Вы "грешите" Александр. Причём усложняете тем самым себе задачу.
      Да ещё и берётесь судить "с собственной колокольни" о словах других в форме обличения.
      С моей стороны не было даже намёка на менторство.
      Менторству свойственны афоризмы и избитые фразы. Мне это не нравится, тем более, что я знаю, чего стою.
      "Практика - критерий истины" это банальность, свойственная менторству.
      Пожалуйста, не обвиняйте меня в том, чего я не делал.

      Удалить
    19. Извините. Наверное, я вас неправильно понял.

      Удалить
  10. «"Ну, в Python отсутствует такой элемент шифрования, как обратная польская нотация :-)"
    -- это - правда. Но ОПЗ - очень быстро преодолевается.

    ДА и не всегда она плоха. Она часто соответствует "человеческой природе". Сначала - данные. Потом - действия с ними.

    Но это опять же моё ИМХО.»
    -- Вы, Александр, похоже совершенно не чувствуете, когда с Вами шутят :-)
    Я ничего не имею против Forth и спокойно отношусь к обратной польской записи. Школа МК-61, так сказать... :-)
    Если серьёзно... Я не думаю, что стоит создавать проблемы там, где их не предвидится. Можно привыкнуть и к обратной польской записи, но зачем это делать, если есть скобочная логика, а в нашем распоряжении мегабайты RAM, а не 15 регистров... :-)

    ОтветитьУдалить
    Ответы
    1. "Вы, Александр, похоже совершенно не чувствуете, когда с Вами шутят"
      Я понимаю когда шутят :-) но не стараюсь искать "шуток" там где их нет.

      Что до Forth - я не вижу в нём проблем. ОПЗ - преодолевается. И легко. Могу дать вам ссылки на литературу.

      Да и ОПЗ ВАЖНО только для арифметических операций. Для моих задач - они не так востребованы.

      А Forth - не потому, что "15 регистров", а потому, что он (как вы верно заметили) хорошо подходит для DSL.

      Да и не Forth в общем-то у меня вовсе. А Forth-машина (близкая к Java-машине) я надеюсь, что вы понимаете разницу.

      Удалить
    2. «Что до Forth - я не вижу в нём проблем. ОПЗ - преодолевается. И легко. Могу дать вам ссылки на литературу.»
      -- Я предпочитаю подходы, в которых не нуно ничего преодолевать, кроме сложности проблемы.

      «А Forth - не потому, что "15 регистров", а потому, что он (как вы верно заметили) хорошо подходит для DSL.»
      -- Не хочу спорить о Forth, хочу отметить только, что это не очень распространённая платформа, что само по себе "не способствует"...

      «Да и не Forth в общем-то у меня вовсе. А Forth-машина (близкая к Java-машине) я надеюсь, что вы понимаете разницу.»
      -- Разницу понимаю, но не вижу разницы в контексте обсуждаемой темы.

      Удалить
  11. Этот комментарий был удален автором.

    ОтветитьУдалить
  12. Этот комментарий был удален автором.

    ОтветитьУдалить
  13. Анонимный, у вас случайно ник не NTFS на kuban.ru?

    ОтветитьУдалить
    Ответы
    1. Вот кстати Дмитрий знаком с одним из наших проектов. Может быть он откомментирует - сложный он или нет. Если захочет.

      Удалить
  14. «Анонимный, у вас случайно ник не NTFS на kuban.ru?»
    -- Нет. kuban.ru не посещаю.

    ОтветитьУдалить
  15. Гарант или Арчи? Да, проекты сложные.

    ОтветитьУдалить
    Ответы
    1. "Гарант или Арчи? Да, проекты сложные."

      Спасибо, Дмитрий.

      Я имел в виду Арчи. Он - СЛОЖНЕЕ. Потому, что там не "read-only" система. Многопользовательская. С транзакциями. С СОБСТВЕННЫМ редактором. С СОБСТВЕННЫМ форматом данных. С СОБСТВЕННЫМ хранилищем.

      Хотя я ЛИЧНО участвовал в обоих.

      Удалить
    2. «Вот кстати Дмитрий знаком с одним из наших проектов. Может быть он откомментирует - сложный он или нет.»
      -- Вот интересно - зачем Вы об этом? ;-)

      Удалить
    3. "Вот интересно - зачем Вы об этом?"
      -- просто потому, чтобы вы поняли, что я не только "hello world" написал :-)
      Ещё раз - "никому ничего доказывать не хочу" :-) просто интересны чужие мнения.

      Но если мнения в стиле "читайте книги" - это грустно. Хотя я про это уже оговорился.

      Хотите общаться - будем общаться :-) я не обижаюсь на "свою неправоту" вот нисколько. Обижаюсь лишь на "менторство". Да и то - принимаю это на свой счёт.

      Удалить
    4. «"Вот интересно - зачем Вы об этом?"
      -- просто потому, чтобы вы поняли, что я не только "hello world" написал :-)
      Ещё раз - "никому ничего доказывать не хочу" :-) просто интересны чужие мнения.»
      -- Забавно :-)
      Действительно - забавно!
      Зачем Вам мне что-либо доказывать? :-)
      Тем более, апеллируя к субъективному мнению человека, которого я не знаю?
      Давайте, я остановлюсь на этом моменте, поскольку уже чувствую, что это следовало бы писать "в личку"...

      «Но если мнения в стиле "читайте книги" - это грустно. Хотя я про это уже оговорился.»
      -- Такое мнение, по крайней мере, с моей стороны, не было высказано.
      Отсылка к литературе (причём, в общем смысле) означала, что мною лично применяются рекомендованные методы управления программным кодом, которые позволяют избежать проблем с сопровождением и развитием проекта.
      По крайней мере Вас я никуда не отсылал.
      И для меня является неожиданной *такая* интерпретация моих слов с Вашей стороны.
      Или я опять неправильно Вас понял?

      «Хотите общаться - будем общаться :-) я не обижаюсь на "свою неправоту" вот нисколько. Обижаюсь лишь на "менторство". Да и то - принимаю это на свой сч»
      -- С моей стороны нет менторства, Александр. Вообще. Это - Ваше воображение, а не я.
      И не будет. Я уже не в том возрасте и не собираюсь Вас ничему учить.

      Удалить
    5. Извините. По-моему - мы друг-друга - не так поняли. Не стоит усугублять. Я думаю.

      Лучше "без оценочных суждений" на профессиональные темы общаться. Если интересно.

      "что это следовало бы писать "в личку"..." - если интересно и есть что сказать - пишите. С интересом бы почитал. lulinalex@gmail.com

      Я - ТОЖЕ не в том возрасте :-) Предлагаю - забыть этот инцидент.

      Удалить
    6. Да нет никакого инцидента, Александр...:-)
      Я настроен в отношении Вас более чем доброжелательно...

      Удалить
    7. "Да нет никакого инцидента, Александр...:-)
      Я настроен в отношении Вас более чем доброжелательно..."
      -- ну и отлично! :-) Извините, если я вас чем-то задел. Не хотел. Правда.

      Наверное не подбираю правильных слов.

      Буду работать над собой :-)

      Удалить
    8. По поводи 10-ти аналитиков - вы мне на МНОГОЕ глаза открыли :-)

      Удалить
    9. Я отправил пост "в личку" :-)
      Извините за некоторую сумбурность - 1,5 л. "Микуличинского" всё-таки... ;-)

      Удалить
    10. «По поводи 10-ти аналитиков»
      -- Аналитики разделяются между проектами.
      Нет такого, чтобы аналитик-тестер работал на один проект.
      И программисты, кстати, тоже.
      Это способствует их профессиональному росту.
      Кстати, здесь напрашивается некая параллель с литературой...
      Обозначенное мною "разделение" сотрудников на совершенно разные задачи по совершенно разным проектам встречается во многих организациях, хотя об этом явно никто не пишет могу ошибаться, поскольку я не могу прочитать всё, что публикуется).
      Это я к тому, что часто бывает так: нечто становится сначала общепринятой практикой, и только после этого закрепляется в литературе.

      Удалить
    11. ""Микуличинского" всё-таки..."
      Я свою "цистерну" уже выпил.. Артрит и почки..

      Удалить
    12. "Нет такого, чтобы аналитик-тестер работал на один проект.
      И программисты, кстати, тоже."

      -- вот тут - СТО ПРОЦЕНТОВ - СОГЛАСЕН.

      Я к сожалению не могу донести эту мысль до тех, кто решения принимает.

      Удалить
    13. «"Нет такого, чтобы аналитик-тестер работал на один проект.
      И программисты, кстати, тоже."
      -- вот тут - СТО ПРОЦЕНТОВ - СОГЛАСЕН.
      Я к сожалению не могу донести эту мысль до тех, кто решения принимает.»
      -- А тут есть одна технологичекая тонкость, которая всё портит... :-)
      Улыбаюсь потому, что "диавол", как ни пошло это звучит, кроется в деталях...
      В мэйнстриме так сложилось, что аналитик и тестер - это два совершенно различных вида деятельности. Это влияет на подготовку сотрудников после приёма на работу и их специализацию, на предъявляемые требования при приёме на работу, на представление о границах собственной ответственности, наконец.
      Для нас очевидно, что это порочная практика и дикость, когда мы узнаём, что кое-где тестирование производится посредством анализа исходного кода.
      Аналитик, непосредственно взаимодействующий с пользователем, только он может быть тестером. Он - представитель пользователя у нас. Он - адвокат пользователя и он же, во взаимодействии с пользователем должен обеспечивать компромисс требований. В том смысле, что требования должны органично вписываться в создаваемую модель, гарантируя её непротиворечивость.
      С точки зрения управления, руководство должно способствовать здоровому антагонисту таких аналитиков с программистами, поскольку в условиях конкуренции и рождается то, что нужно.
      Ну... Где-то так... :-)

      Удалить
    14. "В мэйнстриме так сложилось, что аналитик и тестер - это два совершенно различных вида деятельности. "

      вот вот...

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

      логично

      Удалить
  16. Этот комментарий был удален автором.

    ОтветитьУдалить
  17. Хорошо бы Арчи внедрить в органы власти - чтобы чиновники сразу форматировали свои документы в Арчи и выдавали нам готовые NSR :)

    ОтветитьУдалить
  18. Спасибо за интересную дискуссию.
    И спасибо что сделали её публичной.
    Насчет метрик.
    softproject.com.ua там описаны проекты.
    Реально дорабатываются в текущий момент только 2.
    "САПО" = Система автоматизированного подомового учета(по укр. будет Облику)
    "Ломбард" = не описан на сайте, так как пока разработка ведется только под одного клиента. (60 отделений по Украине и центральная БД. Отдельно написана программа импорта экспорта данных)
    Сапо = 500к строк.
    Ломбард = 110к строк.
    Кстати для определения строк хотел написать свою прогу, но в итоге нашел эту возможность в CNWizards
    Базы. Сначала начал писать но понял что лучше писать не по памяти, а глянуть на работе. Так что завтра напишу.
    Проекту в этом году по идее будет 10 лет.
    Кол-во программистов работавших над ним думаю порядка 30-50. Точные знания надо узнавать у руководства.
    Тех кто был в начале пути, и до сих пор работает 3.
    Работаем без UML.
    Всё "размазано" по всему коду, часть в обработчиках событий. Что меня просто убивает. Тестов нет.
    Начали применять Scrum, Kanban.
    Технологии которые используем:
    Jira - Баги и постановка задач.
    Git - без комментариев ^_^.
    FishEye - для code review.
    Есть документ страниц на 80 описывающий стандарт кодирования. (Был кстати инициатором всего выше перечисленного, правда внедрял и писал не я)
    В планах:
    1. TDD.
    2. Выработать Scrum подход ВОЗМОЖНЫЙ для нашей команды.
    3. UML

    Кол-во команды:
    1. Прогеры = 4,5. Именно 4 с половиной. Так как 5 пока ученик, а прошлый от меня убежал (
    2. Тестеры = 2.
    3. Отдел тех. поддержки = 2. Люди которые в принципе могут настроить серваки. Узнать проблемы по логу. Решить проблемы с внесением данных в БД. Да впринципе всё то что не решается именно кодированием.

    Кол-во клиентов, даже хз как считать, в пользователях ? В кол-ве БД ? Есть целые города работающие на нашей программе. Имею в виду коммунальные службы.


    ОтветитьУдалить
    Ответы
    1. Спасибо. ОЧЕНЬ познавательно.

      Jira - у нас свой аналог. На основе Confluence. Ну вы понимаете.
      Git - CVS/SVN.
      FishEye - ИСПОЛЬЗУЕМ!

      TDD - могу "посоветовать" - не воспринимайте его как "догму".
      Scrum - я лично - "не вкурил".
      UML - буду рад помочь советом, если что.

      "Есть документ страниц на 80 описывающий стандарт кодирования." - если "вдруг" решите поделится тем как вы "валидируете" его исполнение - был бы рад.

      "Сапо = 500к строк.
      Ломбард = 110к строк." - ИМХО - немного. Но и не мало.

      Удалить