Друзья мои!
Хочется задать вопрос.
Вот вы говорите - "UML - вчерашний день", или "UML - тяжело и не нужно".
И ещё говорите - "структурируйте код" и ещё говорите - "документируйте код".
Вам ПРАВДА удаётся так жить?
Вы РЕАЛЬНО можете жить оперируя ТОЛЬКО "голым кодом" и комментариям к нему?
А вот некоторые говорят - "нам и тесты не нужны, мы и так здорово живём".
Может быть вы просветите меня серого - КАК вам удаётся так спокойно жить?
Может быть я РЕАЛЬНО чего-то не понимаю?
"Структурировать" и "документировать" код я пытался. И НЕ РАЗ. И в разных ипостасях. То, что я вижу - "НУ НЕ РАБОТАЕТ".
Всё равно люди либо "плавают в коде", либо "неправильно его используют", либо "изобретают велосипед".
Не надо только говорить, что "мы многое помним". Я сам - МНОГОЕ помню. Я помню, МНОГОЕ, что писалось лет 10-ть назад. И всё равно - "голый код" - ПЛОХО поддаётся управлению. Это моё - УБЕЖДЕНИЕ. Разубедите меня. Может быть - я в чём-то заблуждаюсь.
P.S. Не надо только про XP или Agile. Это - "процесс". А не структурный анализ кода.
P.P.S. Не надо только про "функциональные языки". Ну или поднимаете эту тему - приведите Success Story. Да ТАКУЮ! Чтобы я от зависти умер.
P.P.P.S. Ну и ещё.. Ну поделитесь, ну хоть какими-нибудь метриками! Ну количество строк кода. Количество сущностей. Количество человек в команде. Количество прецедентов (UseCase). Ну или на худой конец количество таблиц в БД. Пожалуйста.
Хочется задать вопрос.
Вот вы говорите - "UML - вчерашний день", или "UML - тяжело и не нужно".
И ещё говорите - "структурируйте код" и ещё говорите - "документируйте код".
Вам ПРАВДА удаётся так жить?
Вы РЕАЛЬНО можете жить оперируя ТОЛЬКО "голым кодом" и комментариям к нему?
А вот некоторые говорят - "нам и тесты не нужны, мы и так здорово живём".
Может быть вы просветите меня серого - КАК вам удаётся так спокойно жить?
Может быть я РЕАЛЬНО чего-то не понимаю?
"Структурировать" и "документировать" код я пытался. И НЕ РАЗ. И в разных ипостасях. То, что я вижу - "НУ НЕ РАБОТАЕТ".
Всё равно люди либо "плавают в коде", либо "неправильно его используют", либо "изобретают велосипед".
Не надо только говорить, что "мы многое помним". Я сам - МНОГОЕ помню. Я помню, МНОГОЕ, что писалось лет 10-ть назад. И всё равно - "голый код" - ПЛОХО поддаётся управлению. Это моё - УБЕЖДЕНИЕ. Разубедите меня. Может быть - я в чём-то заблуждаюсь.
P.S. Не надо только про XP или Agile. Это - "процесс". А не структурный анализ кода.
P.P.S. Не надо только про "функциональные языки". Ну или поднимаете эту тему - приведите Success Story. Да ТАКУЮ! Чтобы я от зависти умер.
P.P.P.S. Ну и ещё.. Ну поделитесь, ну хоть какими-нибудь метриками! Ну количество строк кода. Количество сущностей. Количество человек в команде. Количество прецедентов (UseCase). Ну или на худой конец количество таблиц в БД. Пожалуйста.
Отвечу вопросом на вопрос: А много ли Вы знаете крупных проектов с приложенным к ним UML-диаграммами? Честно, за 8 лет стажа ни разу не встречал :) Может, потому что спецов, умеющих этот UML готовить не так уж и много? Да и нужна ли такая "документация"? Как правило классы, которые я видел на github`е довольно понятны, в противном случае пора делать рефакторинг. Посмотрите, как пример, фреймворк Yii (http://www.yiiframework.com/doc/api/) - его документация сгенерирована из комментариев к коду. Код и комментарии - этого хватает людям, которые вносят изменения по всему миру :)
ОтветитьУдалитьМожет, применение UML показывает, что у Вас сложность проекта зашкаливает?
Не.. Давайте БЕЗ "вопросов на вопрос"...
УдалитьИНАЧЕ - ОТВЕТЬТЕ на вопрос про "метрики"...
"Может, применение UML показывает, что у Вас сложность проекта зашкаливает?" - может..
Так я потому и спрашиваю...
"http://www.yiiframework.com/doc/api/" - не впечатляет,если честно.. :-(
УдалитьДавайте про "метрики" всё же... Вы СКОЛЬКИМ людям пытались "продать" свои наработки?
УдалитьОх уж сразу "продать" :) Я считаю количество людей, которые этим пользуются за "покупателей". Какие метрики Вам нужны? Количество строк кода? 19Мб, Сущностей - дофига, Человек - судя по репу - больше 1000, таблиц нет.
УдалитьНе убедил? Возьмём коммерческую фирму (ЗАО "Петер-Сервис", биллинг делают), человек 800 программистов, таблиц порядка 10 000. У них более-менее грамотно разбито по подсистемам. UML не используется. Кстати, а сколько проектов Вы можете привести, где используется UML?
P.S. Чем же Yii не впечатлил? Тем, что всё понятно? :) Ну не знаю, возьмите ядро linux...
ядро linux ерунда в сравнении с гарантом. и потом скольким людям оно продано?
ОтветитьУдалитьА, понял, здесь сидят продажники :) ok, оно продано, косвенно, 90% хостинговыми компаниями. Нужны прямые продажи? Обратитесь к Oracle (RHEL) или SUSe.
Удалитьхм.. все так гордо говорят про ядро lunix как будто сами его написали :-)
УдалитьХотя ядро linux - конечно аргумент. Мне было бы интересно узнать о том как работа организована.
Но я вообще-то спрашивал о "собственных" проектах. В которых люди САМИ работали.
Отсылки - а "вот там один парень делает" - здорово конечно, но - не интересно.
Это самое масштабное, что пришло в голову :) По поводу рабочего процесса - обычный с надзирателем, описан в книге "Pro GIT".
УдалитьСобственный опыт - всё тот же "Петер-Сервис". Есть аналитики, архитекторы, разработчики, тестировщики... В общем, см. выше. Без UML прекрасно живут :) Или Вы хотели узнать что-то более конкретное?
"аналитики, архитекторы"
УдалитьВ каком виде они выдают результаты своей деятельности? В виде каких артефактов?
Задача аналитиков выдать документ с указанием что нужно сделать, например, "добавить кнопку на третьей странице для повышения конверсии". Архитекторы/проектировщики общаются уже терминами: "расширить класс XXX, добавив поле YYY". Т.е. По идее именно им был бы нужен UML, однако, не прижился.
УдалитьКстати, про организацию рабочего процесса. Я так понял, что у Вас всё строится на UML, а из него потом генерируется код. Сколько примерно часов было потрачено на осуществление такой технологии? Много ли людей этим пользуются? Оформлено ли это в качестве стандарта?
Удалить"По идее именно им был бы нужен UML, однако, не прижился."
Удалить"не прижился" и "не нужен" - разные вещи?
"Задача аналитиков выдать документ с указанием что нужно сделать, например, "добавить кнопку на третьей странице для повышения конверсии"."
УдалитьВалидирует точность исполнения документа кто? Каким образом?
"Сколько примерно часов было потрачено на осуществление такой технологии? "
УдалитьМного.
"Много ли людей этим пользуются?"
Достаточно.
"Оформлено ли это в качестве стандарта?"
Документы - написаны.
http://doc.qt.digia.com/4.6/classes.html
ОтветитьУдалитьАлсо после всех объяснений не вижу никаких причин для UML быть понятнее классической документации.
QTCreateFont - Creates a font ;-)
УдалитьОчень познавательно :-) Простите - не удержался.
Подробнее про документацию - напишу отдельно.
>QTCreateFont - Creates a font ;-)
ОтветитьУдалитьОткуда сиё, если не секрет?
QFont::QFont ( const QFont & font )
УдалитьConstructs a font that is a copy of font.
А что там ещё писать? :-)
УдалитьСудя по приведённому - это конструктор, который клонирует существующий экземпляр.
UML-диаграмма не сделает ситуацию вокруг этого метода более ясной :-)
"А что там ещё писать? :-)"
УдалитьНичего не писать :-) Не тратить на это силы и время. UML - тут - да. ТОЖЕ - НИЧЕГО не добавляет.
IMHO, написать нужно, поскольку "const QFont & font" передаётся по ссылке, а значит, может быть изменён в конструкторе.
УдалитьКроме того, из комментария однозначно следует, для чего разработчики предназначали этот метод. А это, в свою очередь, может предотвратить его использование не по назначению. "Неправильное" в Вашей терминологии.
" а значит, может быть изменён в конструкторе"
Удалитьне может. Там - const. Всякие const_cast и mutable - я бы не рассматривал.
"Кроме того, из комментария однозначно следует, для чего разработчики предназначали этот метод."
Удалить-- по-моему "самодокументируемой" сигнатуры - достаточно. Хотя конечно - "на вкус и цвет - все фломастеры разные".
«" а значит, может быть изменён в конструкторе"
Удалитьне может. Там - const. Всякие const_cast и mutable - я бы не рассматривал.»
-- Вы бы - не рассматривали, а разработчики сделали всё, чтобы пользователь вообще не задумывался на этот счёт.
Не нравится? Догадались сами? - Не вопрос.
Но есть определённые правила документирования, от которых не следует отступать, чтобы сохранить дееспособность инфраструктуры. По простому: отступил здесь, положившись на собственное восприятие очевидности - поступишь так же, когда это - недопустимо.
Не согласен. Но спорить - далее не буду.
УдалитьВашу позицию - я понял. И встречал её в своей практике и не раз. Может быть - вы и правы.
NameRec:
ОтветитьУдалить«И ещё говорите - "структурируйте код" и ещё говорите - "документируйте код".»
-- Говорим не только это, не нужно утрировать...
«Вам ПРАВДА удаётся так жить?»
-- Да, безусловно.
«Вы РЕАЛЬНО можете жить оперируя ТОЛЬКО "голым кодом" и комментариям к нему?»
-- Да, РЕАЛЬНО :-)
«А вот некоторые говорят - "нам и тесты не нужны, мы и так здорово живём".»
-- "Некоторые" много чего говорят... :-)
В общем случае, нужны не тесты, а полноценное тестирование.
В некоторых случаях роль тестирования могут взять на себя тесты.
«Может быть вы просветите меня серого - КАК вам удаётся так спокойно жить?»
-- Задавайте конкретные вопросы.
Но вообще-то, много в книжках описано :-)
«Может быть я РЕАЛЬНО чего-то не понимаю?»
-- Нельзя этого исключать...
«"Структурировать" и "документировать" код я пытался. И НЕ РАЗ. И в разных ипостасях. То, что я вижу - "НУ НЕ РАБОТАЕТ".»
-- Давайте подробнее: что именно у Вас "не работает".
«Всё равно люди либо "плавают в коде", либо "неправильно его используют", либо "изобретают велосипед".»
-- Я Вас не понял. Не "плавайте", используйте правильно и не "изобретайте велосипед".
Наладьте обучение и контроль. Работайте над квалификацией исполнителей.
«Не надо только говорить, что "мы многое помним". Я сам - МНОГОЕ помню. Я помню, МНОГОЕ, что писалось лет 10-ть назад. И всё равно - "голый код" - ПЛОХО поддаётся управлению.»
-- Я до сих пор не понимаю, что такое "голый код" :-)
Тот код, с которым приходится работать мне, вероятно, "одетый", поскольку управлять им вполне удаётся.
«Не надо только говорить, что мы многое помним . Я сам - МНОГОЕ помню. Я помню, МНОГОЕ, что писалось лет 10-ть назад. И всё равно - голый код - ПЛОХО поддаётся управлению.»
-- Сначала объясните: зачем здесь, в Вашем блоге, кому-то Вас в чём-то убеждать? :-)
Непонятно - спрашивайте. А для троллинга есть политические сайты.
«P.S. Не надо только про XP или Agile. Это - "процесс". А не структурный анализ кода.»
-- Практически никогда не нужен структурный анализ *всего кода*.
Требуется иметь *достаточное* представление о коде, с которым придётся взаимодействовать при решении конкретной задачи.
Больше типовых решений - меньше типового разнообразия такого кода.
«P.P.P.S. Ну и ещё.. Ну поделитесь, ну хоть какими-нибудь метриками! Ну количество строк кода. Количество сущностей. Количество человек в команде. Количество прецедентов (UseCase). Ну или на худой конец количество таблиц в БД. Пожалуйста.»
-- Строки кода считать... Ну немного лень, если честно. Давайте лучше в мегабайтах. ~80 MB в 1779 модулях. Понятно, там есть комментарии, но их не больше 10%.
Количество человек в команде ~20 программистов и 10 аналитиков и тестеров по совместительству.
Количество прецедентов никто никогда не считал, поскольку для нас это - неоперационный термин.
Количество таблиц в БД одного из проектов - 561.
"Но вообще-то, много в книжках описано"
УдалитьНу если вы считаете, что книжек я не читал, то на сём дискуссию можно прекращать.
Считаем, что я погорячился.
УдалитьЗадам вопрос. Можно?
В каких книжках? Можно кратенький список?
А то - может - я не те книжки читал.
"-- Сначала объясните: зачем здесь, в Вашем блоге, кому-то Вас в чём-то убеждать? :-)
УдалитьНепонятно - спрашивайте. А для троллинга есть политические сайты."
Давайте не будем разговаривать в таком ключе? Хорошо? Тем более, что по многим моментам - Вы мне очень помогли.
Я никого не "троллю". Не хотите - не читайте, не хотите - не отвечайте. Тут дело - взаимное. Я пишу - вы читаете или нет, я спрашиваю - вы отвечаете или нет.
Я могу заблуждаться или быть не правым, но это не значит, что я кого-то "троллю". Хорошо?
"и *10 аналитиков* и тестеров по совместительству."
УдалитьЕсли это именно "аналитики", а не только "тестеры", то это может быть МНОГОЕ объясняет.
"~80 MB в 1779 модулях."
УдалитьПо мне - немного. Хотя я могу не понимать всего контекста.
«Задам вопрос. Можно?
УдалитьВ каких книжках? Можно кратенький список?»
-- Извольте, на вскидку - то, что я рекомендую своим студентам:
"П.Гудлиф. Ремесло программиста. Практика написания хорошего кода"
"Г.Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. Второе издание"
"Д.Спольски. Джоэл о программировании"
"К.Бек. Экстремальное программирование"
"М.Фаулер. Архитектура корпоративных программных приложений"
"Н.Н.Непейвода, И.Н.Скопин. Основания программирования"
"Н.Вирт. Алгоритмы + Структуры данных = Программы"
"Н.Вирт. Систематическое программирование. Введение"
"С.Макконнелл. Совершенный код"
«"и *10 аналитиков* и тестеров по совместительству."
УдалитьЕсли это именно "аналитики", а не только "тестеры", то это может быть МНОГОЕ объясняет.»
-- Да. Именно так. Это одновременно И аналитики И тестеры. Намеренно и никак иначе.
«"~80 MB в 1779 модулях."
УдалитьПо мне - немного. Хотя я могу не понимать всего контекста.»
-- Вот удивительно: Вы признаёте, что можете не понимать *всего* контекста, и одновременно утверждаете, что "по Вам - немного" :-)
Мне проще: я не знаю, понимаете Вы или нет и достаточно ли понимаю я Вас. Поэтому, я воздерживаюсь от оценочных суждений.
""П.Гудлиф. Ремесло программиста. Практика написания хорошего кода"
Удалить"Н.Н.Непейвода, И.Н.Скопин. Основания программирования"
"
-- эти книги - я не читал.
"
"Д.Спольски. Джоэл о программировании"
"К.Бек. Экстремальное программирование"
"М.Фаулер. Архитектура корпоративных программных приложений"
"Н.Н.Непейвода, И.Н.Скопин. Основания программирования"
"С.Макконнелл. Совершенный код""
- это из моего списка "любимых книг" или "must read".
"Да. Именно так. Это одновременно И аналитики И тестеры. Намеренно и никак иначе."
УдалитьСделайте одолжение. Можете рассказать об их должностных инструкциях?
"Вот удивительно: Вы признаёте, что можете не понимать *всего* контекста, и одновременно утверждаете, что "по Вам - немного" :-)"
УдалитьВ ТОМ КОНТЕКСТЕ, как Я ПОНИМАЮ - немного. Но я - сомневаюсь, что контекст правильный. Посему - и оговорился.
Ведь термин "модуль" - не определён.
А если на Mb ТОЛЬКО ориентироваться, то - НЕМНОГО. Опять же - по МОЕМУ пониманию. У "меня" - БОЛЬШЕ Mb кода. Но опять же - могу ошибаться.
"Мой список книг" - http://18delphi.blogspot.com/2013/03/blog-post_2036.html
УдалитьПонятно, что он - не полный.
«"Да. Именно так. Это одновременно И аналитики И тестеры. Намеренно и никак иначе."
УдалитьСделайте одолжение. Можете рассказать об их должностных инструкциях?»
-- Да, пожалуйста. Что Вас конкретно интересует?
Идея следующая. Аналитик у нас непосредственно общается с пользователем и получает от него информацию, которая, после обсуждения с ведущим инженером проекта, иногда - архитектором, преобразуется в постановку задачи, которую реализует программист.
Тестирование производится тем же аналитиком, что писал постановку, поскольку вокруг нет никого, кто лучше него представляет проблемы пользователя.
Ну, а дальше - по Agile/KANBAN...
"Аналитик у нас непосредственно общается с пользователем"
Удалить"Тестирование производится тем же аналитиком, что писал постановку, поскольку вокруг нет никого, кто лучше него представляет проблемы пользователя."
Понятно. Спасибо. Тогда это - действительно МНОГОЕ объясняет.
«Ведь термин "модуль" - не определён.»
Удалить-- Как это не определён? Я использую только стандартную терминологию.
То, что перечисляется в списке uses - модули и есть...
«А если на Mb ТОЛЬКО ориентироваться, то - НЕМНОГО. Опять же - по МОЕМУ пониманию. У "меня" - БОЛЬШЕ Mb кода. Но опять же - могу ошибаться.»
-- Просите, а *какого* кода у Вас больше? ;-)
Тот код, о котором пишу я - написан вручную. Нашими программистами или нет - несущественно.
Как следует из Ваших предыдущих постов, Вы используете кодогенерацию и подмешивание. Второе - в сущности, автоматизированное (include) *дублирование* кода, которое у нас отсутствует.
Далее, условной компиляцией мы пользуемся совершенно не так, как очевидно, принято у Вас в компании. Это означает, что у нас код, расположенный в разных ветках IFDEF отсутствует.
Далее, я перечислил *только* исходные тексты на Object Pascal. XML-аналоги DFM - не учитывались, как и Python-код, которого также немало.
"То, что перечисляется в списке uses - модули и есть..."
Удалить-- значит я правильно понял контекст.
"Тот код, о котором пишу я - написан вручную. Нашими программистами или нет - несущественно."
-- да это так.
"Второе - в сущности, автоматизированное (include) *дублирование* кода, которое у нас отсутствует."
-- это - правда. Но это - "малая толика". И это сравнимо с "шаблонами C++".
"Далее, условной компиляцией мы пользуемся совершенно не так, как очевидно, принято у Вас в компании. Это означает, что у нас код, расположенный в разных ветках IFDEF отсутствует."
-- вот это я не очень понял.
"XML-аналоги DFM - не учитывались"
-- я их тоже не учитываю.
"как и Python-код, которого также немало"
-- жаль, что вы его не посчитали.
"то, что я рекомендую своим студентам"
УдалитьМожно ещё вопрос?
Вы ГДЕ и ЧТО преподаёте?
Если не секрет.
Можно послушать ваши лекции? :-) Правда - интересно.
"Второе - в сущности, автоматизированное (include) *дублирование* кода, которое у нас отсутствует."
Удалить-- в Mb это кстати НЕ ВХОДИТ. Входит ТОЛЬКО в "количество строк". Но ведь "количество строк" - мы не обсуждаем.
«"как и Python-код, которого также немало"
Удалить-- жаль, что вы его не посчитали.»
-- Да нет, я сделал это намеренно :-)
Не понятно, как Вы будете сопоставлять код на Python коду на Pascal...
«"Второе - в сущности, автоматизированное (include) *дублирование* кода, которое у нас отсутствует."
-- это - правда. Но это - "малая толика". И это сравнимо с "шаблонами C++".»
-- Где? В бинарном коде? - Да, согласен.
А вот "строчек кода" это добавит пропорционально тому, насколько часто Вы используете подмешивание ;-)
«"Далее, условной компиляцией мы пользуемся совершенно не так, как очевидно, принято у Вас в компании. Это означает, что у нас код, расположенный в разных ветках IFDEF отсутствует."
-- вот это я не очень понял.»
-- А что здесь непонятного?
У нас в модулях практически отсутствует код, не включаемый в приложение.
Можно не включить модуль, но опять же, редко для этого используется условная компиляция (хотя и бывает такое).
Как я понял, в процессе кодогенерации у Вас автоматически производятся включения, описанные в шаблонах (хотя могу и ошибаться, поскольку разбираться в Ваших шаблонах у меня не было достаточного времени :-)).
Вот мне и непонятно: что и как Вы измеряете в отношении строчек кода.
Ну и наконец, я не считаю метрику "количество строчек кода" адекватной для оценки сложности проекта. Как и количество "сущностей", тем более, что в моём случае это вообще сомнительное понятие.
Более адекватной метрикой был бы размер постановки (в наших терминах), в которой и описано то, что следует обеспечить в проекте.
"Более адекватной метрикой был бы размер постановки (в наших терминах), в которой и описано то, что следует обеспечить в проекте."
Удалить-- Согласен. Я потому и говорил изначально про "прецеденты" (UseCase) ну или их аналоги.
"Не понятно, как Вы будете сопоставлять код на Python коду на Pascal..."
Удалить-- вы считаете, что они несопоставимы? почему? Можно узнать? Интересно.
"А вот "строчек кода" это добавит пропорционально тому, насколько часто Вы используете подмешивание ;-)"
Удалить-- про "строчки кода", я вроде уже пояснил. Мы же вроде про Mb говорили. По-крайней мере - "строчки кода" - вы не приводили. Значит - их и обсуждать нечего. Мне так кажется.
"Ну и наконец, я не считаю метрику "количество строчек кода" адекватной для оценки сложности проекта."
Удалить-- Это - ПЛОХАЯ метрика. Согласен. Но лучше - ПЛОХАЯ, чем никакая.
Хотя "размер постановки" - конечно - СИЛЬНО ЛУЧШЕ. Если он оценен.
«"Второе - в сущности, автоматизированное (include) *дублирование* кода, которое у нас отсутствует."
Удалить-- в Mb это кстати НЕ ВХОДИТ. Входит ТОЛЬКО в "количество строк". Но ведь "количество строк" - мы не обсуждаем.»
-- Изначально Вы говорили о строчках кода, потом мы переключились на мегабайты.
Мне сложно уследить, о чём Вы говорите в данном конкретном случае.
Относительно "метрик" я высказался выше. В разных подходах к программированию будет существенно разное количество и строчек и мегабайт.
«"то, что я рекомендую своим студентам"
Можно ещё вопрос?
Вы ГДЕ и ЧТО преподаёте?
Если не секрет.
Можно послушать ваши лекции? :-)»
-- Да не секрет...
По совместительству (это хобби) я преподаю два спецкурса на Факультете Прикладной Математики Кубанского Госуниверситета.
"Технология разработки программного обеспечения" и "Разработка сложных приложений с БД".
Курсы практические, т.е. обозначается задача, в течение семестра она решается с привлечением литературы и консультаций. Стараюсь устраивать семинары...
Лекции форматом курса не предусмотрены, в целом, процесс обучения это very-very-lite вариант подготовки нового сотрудника в соей организации.
"Курсы практические, т.е. обозначается задача, в течение семестра она решается с привлечением литературы и консультаций. Стараюсь устраивать семинары..."
Удалить-- "бумажные" или "электронные" документы есть?
"-- Изначально Вы говорили о строчках кода, потом мы переключились на мегабайты.
УдалитьМне сложно уследить, о чём Вы говорите в данном конкретном случае."
-- ну вы ответили только про Mb. Так что я думаю, что правильнее было бы оставаться в этом контексте.
«"Ну и наконец, я не считаю метрику "количество строчек кода" адекватной для оценки сложности проекта."
Удалить-- Это - ПЛОХАЯ метрика. Согласен. Но лучше - ПЛОХАЯ, чем никакая.
Хотя "размер постановки" - конечно - СИЛЬНО ЛУЧШЕ. Если он оценен.»
-- Да, можно. Но не сейчас, по худому WiFi из отеля... :-)
"-- Да, можно. Но не сейчас, по худому WiFi из отеля... :-)"
УдалитьНе понял :-(
«"Курсы практические, т.е. обозначается задача, в течение семестра она решается с привлечением литературы и консультаций. Стараюсь устраивать семинары..."
Удалить-- "бумажные" или "электронные" документы есть?»
-- Да, есть. Но не с собой :-)
Не ожидал, что в отпуске они мне понадобятся...
Не - ну я не тороплюсь. Главное, что в принципе есть. Уже - радует. Что есть теоретическая возможность почитать.
Удалить«"-- Да, можно. Но не сейчас, по худому WiFi из отеля... :-)"
УдалитьНе понял :-(»
-- Ну, я сейчас в отпуске, в отеле, в Украине :-)
Соединение с офисом у меня через WiFi, который постоянно падает.
Качать мегабайты отчёта со *всей* постановкой по проекте (хотя это текст, в основном) - буду ждать до утра... :-)
Некоторые люди прочитав это - http://18delphi.blogspot.com/2013/08/mvc.html
УдалитьПишут что-то вроде:
"Вам нужно преподавать. Интересный способ изложения. Очень интересный. Спасибо!"
-- значит - до кого-то - донёс. :-)
Жаль, что таких - пока - единицы.
«"Не понятно, как Вы будете сопоставлять код на Python коду на Pascal..."
Удалить-- вы считаете, что они несопоставимы? почему? Можно узнать? Интересно.»
-- Ну просто потому, что Python очень высокоуровневый интерпретируемый язык с динамической типизацией.
Грубо утрируя: одна строчка на Python соответствует 5-6 на Pascal, но не всегда.
Наверное, приблизительное сопоставление в каждом конкретном случае дать можно, но это будет слишком уж "от фонаря".
Известные мне примеры решений (когда они есть и на Pascal и на Python) дают очень большой разброс в объёме кода, поэтому я не возьмусь сравнивать.
"Качать мегабайты отчёта со *всей* постановкой по проекте (хотя это текст, в основном)"
Удалить-- теперь - понял. Спасибо.
"Ну просто потому, что Python очень высокоуровневый интерпретируемый язык с динамической типизацией.
УдалитьГрубо утрируя: одна строчка на Python соответствует 5-6 на Pascal, но не всегда."
-- не стал бы я его так переоценивать :-)
"Известные мне примеры решений (когда они есть и на Pascal и на Python) дают очень большой разброс в объёме кода, поэтому я не возьмусь сравнивать."
-- а можно какой-нибудь пример? если не сложно.
«Некоторые люди прочитав это - http://18delphi.blogspot.com/2013/08/mvc.html»
Удалить-- Я, разумеется, читал этот пост.
Скажем так... У меня впечатления амбивалентные.
С одной стороны, я отдаю себе отчёт в том, что написанное Вами следует воспринимать в контексте, что в итоге "надо всем над этим" у Вас будет находиться UML.
С другой стороны, мне для описания того, что обозначено в статье, не пришлось бы писать код вообще.
Это и даёт мне основания полагать, что "строчки кода" и объём этого кода в мегабайтах - неадекватные метрики для оценки сложности системы.
С третьей стороны, чужой опыт всегда полезен, уже хотя бы потому, что он - опыт :-)
А некоторые ещё говорят - "UML хорош хотя бы тем, что в нём всё по прецедентам (UseCase) разложено".
УдалитьНо таких - тоже единицы.
"С одной стороны, я отдаю себе отчёт в том, что написанное Вами следует воспринимать в контексте, что в итоге "надо всем над этим" у Вас будет находиться UML."
Удалить-- вот СОВСЕМ необязательно. Эти идеи были реализованы ещё ДО UML. А на UML Они легли уже после переосмысления проблем.
"С другой стороны, мне для описания того, что обозначено в статье, не пришлось бы писать код вообще."
-- можете пояснить? Как бы вы это сделали? В чём я не прав?
"Это и даёт мне основания полагать, что "строчки кода" и объём этого кода в мегабайтах - неадекватные метрики для оценки сложности системы."
-- вот здесь я не понял - откуда такой вывод.
"С третьей стороны, чужой опыт всегда полезен, уже хотя бы потому, что он - опыт :-)"
-- это -да.
«"Известные мне примеры решений (когда они есть и на Pascal и на Python) дают очень большой разброс в объёме кода, поэтому я не возьмусь сравнивать."
Удалить-- а можно какой-нибудь пример? если не сложно.»
-- Вы имеете ввиду сейчас законченное решение на Pascal и соответствующее ему - на Python?
В принципе, можно поискать, но опять же, когда вернусь...
У нас есть примеры кода, когда мы переписывали его с Pascal на Python, но... Тут те же ограничения, что и у Вас. Проприетарность...
Что точно могу сделать - это верифицировать оценки. Хотя и с поправкой на то, что при переводе ещё добавлялась функциональность...
"Хотя и с поправкой на то, что при переводе ещё добавлялась функциональность..."
Удалить-- а вот этого я стараюсь избегать.
Моё правило - сначала - перенос, а потом только "добавление функциональности" или рефакторинг.
И ЛУЧШЕ после написания тестов. Если таковых не было.
Если конечно интересно моё мнение.
"язык с динамической типизацией"
УдалитьDuck Typing? Как КОНЦЕПЦИЯ - мне это нравится. Но я всё же предпочитаю проверку типов компилятором. Хотя ИМХО - одно другому - не противоречит.
Могу ошибаться.
«Duck Typing? Как КОНЦЕПЦИЯ - мне это нравится. Но я всё же предпочитаю проверку типов компилятором. Хотя ИМХО - одно другому - не противоречит.»
Удалить-- Ну да :-) Я просто не люблю англицизмы...
Мне это не очень нравится и как концепция, но против фактов "не попрёш" - производительность труда это увеличивает весьма существенно, хотя обратная сторона - провоцирует быдлокодинг. Но есть эффективные способы борьбы с этим - в книжках они описаны достаточно подробно, а в некоторых случаях это можно даже подстегнуть.
При надлежащем внимании к процессу управления использование скрипт-языков существенно удешевляет разработку, поскольку для большинства задач не требуется высокая квалификация, а программировать - проще. Да и тема Вашего любимого TDD в Python раскрыта весьма существенно.
Вот тут - всё понятно.
Удалить«Давайте не будем разговаривать в таком ключе? Хорошо?»
ОтветитьУдалить-- Хорошо, будем считать, что я Вас неправильно понял :-)
"Хорошо, будем считать, что я Вас неправильно понял :-)"
УдалитьОк. Спасибо.
"Вы имеете ввиду сейчас законченное решение на Pascal и соответствующее ему - на Python"
ОтветитьУдалить-- ну да.
"Проприетарность"
-- понимаю. Знакомо. Потому и не настаиваю.
«"С другой стороны, мне для описания того, что обозначено в статье, не пришлось бы писать код вообще."
ОтветитьУдалить-- можете пояснить? Как бы вы это сделали? В чём я не прав?»
-- Начнём с того, что Вы во всём правы.
У Вас есть инструмент, и Вы используете его так, как оно было задумано.
Что касается меня, то я воспользовался бы *нашим* дизайнером.
Разместил бы на разных фреймах или модулях данных (определяется тем, нужны ли визуальные компоненты) то, что требуется мне в контексте каждого элемента управления.
Ну например, Вы сказали, что нам "повезло" с редактором и он умеет всё, кроме печати и экспорта (я упрощаю для пояснения). - Я бросил бы на отдельный фрейм этот "волшебный" редактор.
Приделал бы нужные панели инструментов, ну и прочие элементы оформления. Сохранил бы фрейм в XML. Это интерпретированный DFM, т.е. по XML всегда можно получить DFM, а по DFM - XML.
Вероятно (хотя и не обязательно, поскольку это можно сделать в любой момент) я поступил бы аналогичным образом и с остальными визуальными элементами управления, поскольку в дальнейшем это даст возможность их повторного использования.
У меня получился бы набор XML.
Далее, я создал бы в дизайнере форму, на которой расположил бы компоненты из только что созданных XML.
Ну и потом... Я же не знаю, как Вы собирались развивать то, что начали описывать...
Для простоты, предварительно, я создал бы класс, который загружал бы форму со всем хозяйством. Загрузка выглядела бы так:
LoadComponent(Self, UID_MyForm);
Где UID_MyForm - GUID, размещённый в XML - его формирует наша программа-дизайнер.
Функциональность печати документа я сделал бы обработчиком, который построил рядом:
ValidateComponentRef(Self.EditorFrame);
TDocumentEditor_PrintCommand(form.EditorFrame.Editor);
Ну, где-то так...
"Что касается меня, то я воспользовался бы *нашим* дизайнером."
Удалить-- дизайнер у нас был, но он потом переехал в UML.
"Ну и потом... Я же не знаю, как Вы собирались развивать то, что начали описывать..."
Удалить-- не успел ещё.
"Это интерпретированный DFM, т.е. по XML всегда можно получить DFM, а по DFM - XML"
Удалить-- логично.
И вообще...
УдалитьЕсли я правильно понял - то, что вы написали - ОЧЕНЬ похоже на то, что я пытался описать. Хотя - возможно - я льщу себе.
«"Что касается меня, то я воспользовался бы *нашим* дизайнером."
Удалить-- дизайнер у нас был, но он потом переехал в UML.»
-- А кто им пользовался? Программисты? Или как у нас - тестеры-аналитики?
"Программисты? Или как у нас - тестеры-аналитики?"
Удалить-- у нас к сожалению нет РОВНО такой РОЛИ.
«"Это интерпретированный DFM, т.е. по XML всегда можно получить DFM, а по DFM - XML"
Удалить-- логично.»
-- Да, мне казалось - логично :-)
В свете этого я и не понимаю сути Ваших претензий к DFM.
DFM в моём понимании отвечает на вопрос "что" (нужно), а за вопрос "как" (это обеспечить) отвечает код.
«Если я правильно понял - то, что вы написали - ОЧЕНЬ похоже на то, что я пытался описать.»
-- Ну... Мне трудно судить.
Именно поэтому я с интересом наблюдаю за Вашими публикациями.
Вот только, возможно - пока, не разделяю Вашего отношения к UML, который я, кстати, преподаю на третьем курсе.
Аналитики передают мне отношения между сущностями предметной области в виде диаграмм классов UML. Они сами его рисуют. И это - удобно.
Но генерировать код из него... Через такие криптованные шаблоны... Ну, я пока не готов :-) Как бы ни просто было их править тому *кто разобрался*, он должен сначала в них разобраться, а потом бороться с ними, когда кодогенератор нагенерирует некомпилирующийся код или в результате кодогенерации будет не то, что требуется.
Это лишние накладные расходы и я не готов с ними мириться, даже ощущая прелесть графического представления архитектуры.
Да и повторюсь - чаще всего это представление *не необходимо*.
Если было бы так, то может быть был бы совсем другой разговор.
Удалить"Через такие криптованные шаблоны..."
Удалить-- это - "исторически сложилось", а не "так задумывалось". Мы работаем над этим.
«"Программисты? Или как у нас - тестеры-аналитики?"
Удалить-- у нас к сожалению нет РОВНО такой РОЛИ.»
-- Формы для объектов предметной области у нас "рисуют" аналитики.
"когда кодогенератор нагенерирует некомпилирующийся код или в результате кодогенерации будет не то, что требуется."
Удалить-- вот такого ПРАКТИЧЕСКИ никогда не случалось.
"Формы для объектов предметной области у нас "рисуют" аналитики."
Удалить-- ну это реально здорово :-)
"Это лишние накладные расходы и я не готов с ними мириться, даже ощущая прелесть графического представления архитектуры."
Удалить-- вот тут пока не соглашусь, что "лишние".
«"Через такие криптованные шаблоны..."
Удалить-- это - "исторически сложилось", а не "так задумывалось". Мы работаем над этим.»
-- Да, в принципе, просматривается техническое решение...
Можно тот же Python использовать - это существенно упростит жизнь...
Но Александр... :-)
Дополнительный шаг - обработка шаблонов никуда не денется, поскольку это имманентно присущее UML свойство - он (UML) язык описания предметной области, язык пректирования, но *не программирования*.
Можно сделать шаблоны дружелюбнее, но от связи кода с диаграммой не уйдёшь, если Вы ставите на первое место диаграмму. Шаблоны - центральная часть этой связи.
Тем более, есть другой путь. Он вынуждает работать в других понятиях (а Вы разве не занимаетесь тем же самым?), но он ориентирован на код. Вот Виктор Вам про Idea писал - в принципе - очень интересное решение. И UML там есть, правда, на вторых ролях, не так как у Вас...
Ну и IDE... Развитие этого направления может позволить генерировать UML по *существующему* коду. Нам ведь "ехать", а не "шашечки"? Нужно построить графическое представление - а вот оно!
Но понятно, пока это пока только в проекте...
«"когда кодогенератор нагенерирует некомпилирующийся код или в результате кодогенерации будет не то, что требуется."
Удалить-- вот такого ПРАКТИЧЕСКИ никогда не случалось.»
-- Восхищаюсь Вашему самоконтролю :-)
Я бы так точно не смог.
Но совершенно понятно, что шаблоны можно сделать дружелюбнее...
"Но совершенно понятно, что шаблоны можно сделать дружелюбнее.."
Удалить-- СОВЕРШЕННО ПОНЯТНО. Тут вы правы.
«"Это лишние накладные расходы и я не готов с ними мириться, даже ощущая прелесть графического представления архитектуры."
Удалить-- вот тут пока не соглашусь, что "лишние".»
-- А я - не настаиваю :-)
У Вас сложилась система, она складывалась годы, она работает, наконец. Я не предлагаю избавляться от части фундамента этой системы. И не говорю, что эта часть - избыточна.
В рамках построенной вами (не только Вами) инфраструктуры она может быть органичной и даже - необходимой.
Я просто хочу сказать, что другой путь - есть.
Вкратце я его обозначил.
"Дополнительный шаг - обработка шаблонов никуда не денется, поскольку это имманентно присущее UML свойство - он (UML) язык описания предметной области, язык пректирования, но *не программирования*."
Удалить-- а вот тут - вы ошибаетесь.
1. Это и "программирование".
2. И это - НЕОБХОДИМЫЙ шаг. А не ДОПОЛНИТЕЛЬНЫЙ. Этот шаг позволяет параметризовывать код "до его написания".
"Я просто хочу сказать, что другой путь - есть."
Удалить-- конечно :-) и его - мы тоже - прошли.
"Но совершенно понятно, что шаблоны можно сделать дружелюбнее..."
Удалить-- и я - работаю над этим :-) но не в сторону Python, а в сторону Forth.
«2. И это - НЕОБХОДИМЫЙ шаг. А не ДОПОЛНИТЕЛЬНЫЙ. Этот шаг позволяет параметризовывать код "до его написания".»
Удалить-- Надеюсь, Вы допускаете существование иных способов это сделать? ;-)
Программирование ведь - не православие: есть много разных путей к желаемой цели... :-)
"Ну и IDE... Развитие этого направления может позволить генерировать UML по *существующему* коду. Нам ведь "ехать", а не "шашечки"? Нужно построить графическое представление - а вот оно!
УдалитьНо понятно, пока это пока только в проекте..."
-- у вас в проекте? Или у сторонних разработчиков?
«"Но совершенно понятно, что шаблоны можно сделать дружелюбнее..."
Удалить-- и я - работаю над этим :-) но не в сторону Python, а в сторону Forth.»
-- Решили заменит один инструмент шифрования на другой? ;-)
Нет-нет, я е против Forth, просто он слишком уж специфичен, хотя и хорошо подходит для своих DSL. Но есть более привычные инструменты, делающее это не хуже...
Всё сказанное - моё личное IMHO.
"-- Надеюсь, Вы допускаете существование иных способов это сделать? ;-)"
Удалить-- КОНЕЧНО! Я же писал - "UML - Не догма". Как и TDD - не догма. Я стараюсь делиться своим опытом и ЧЕРПАТЬ чужой. Как например ваш.
«"Ну и IDE... Развитие этого направления может позволить генерировать UML по *существующему* коду. Нам ведь "ехать", а не "шашечки"? Нужно построить графическое представление - а вот оно!
УдалитьНо понятно, пока это пока только в проекте..."
-- у вас в проекте? Или у сторонних разработчиков?»
-- У нас? - Нет :-)
Мы не придаём UML такого значения.
Думаю, это появится в сторонних IDE или плагинах к ним. Eclipse, NetBeans, Idea.
Да кое-что, насколько мне известно, и уже есть...
" хотя и хорошо подходит для своих DSL. "
Удалить-- вот именно.
"Думаю, это появится в сторонних IDE или плагинах к ним"
Удалить-- вот тут - я не такой оптимист как вы. Хотя - кто знает...
«"Я просто хочу сказать, что другой путь - есть."
Удалить-- конечно :-) и его - мы тоже - прошли.»
-- Ну... Не хотите же Вы сказать, что уже прошли *все* альтернативные пути, в которых не придаётся такого значения UML? ;-)
"Решили заменит один инструмент шифрования на другой? ;-)"
ОтветитьУдалить-- по-моему - вы не правы. Я вот считаю Python "инструментом шифрования". Но не навязываю такого мнения.
НО! http://18delphi.blogspot.com/2013/07/blog-post_196.html - это - FORTH.
«"Решили заменит один инструмент шифрования на другой? ;-)"
Удалить-- по-моему - вы не правы. Я вот считаю Python "инструментом шифрования". Но не навязываю такого мнения.»
-- Ну, в Python отсутствует такой элемент шифрования, как обратная польская нотация :-)
"Ну, в Python отсутствует такой элемент шифрования, как обратная польская нотация :-)"
Удалить-- это - правда. Но ОПЗ - очень быстро преодолевается.
ДА и не всегда она плоха. Она часто соответствует "человеческой природе". Сначала - данные. Потом - действия с ними.
Но это опять же моё ИМХО.
"Не хотите же Вы сказать, что уже прошли *все* альтернативные пути, в которых не придаётся такого значения UML? "
Удалить-- нет конечно. Но нельзя же всё время метаться и "испытывать различные пути". Надо в итоге что-то выбрать. Мы (пока) выбрали UML.
Control.Height
Удалить-- это ли не пример ОПЗ?
Тут я отчасти опираюсь на статью Хоор "Обработка записей".
Удалитьhttp://qnx.org.ru/forum/index.php?topic=499
УдалитьХоор К. Обработка записей. // В кн.: Языки программирования. М.: Мир, 1972
«"Не хотите же Вы сказать, что уже прошли *все* альтернативные пути, в которых не придаётся такого значения UML? "
Удалить-- нет конечно. Но нельзя же всё время метаться и "испытывать различные пути". Надо в итоге что-то выбрать. Мы (пока) выбрали UML.»
-- Ваше "пока" внушает надежду.
Какое-то время назад я объявил для себя мораторий на комметрарии в Ваш блог, поскольку у меня сложилось впечатление о Вас, как о некоем евангелисте, открывшем для себя Священный Грааль и стремящегося распространить "знание" по миру.
То, что вы (Вы и Ваша компания) выбрали UML - совершенно замечательно. Если Ваш подход в итоге окажется конструктивным - у вас появятся последователи. Если нет... Надеюсь, Вы расскажете нам о вашем опыте, поскольку даже опыт неудачный - архиполезен.
Мне же хтелось бы получить более полное представление о вашей методологии, поэтому я - Ваш внимательный читатель...
«Control.Height
Удалить-- это ли не пример ОПЗ?»
-- Ну... :-) После литра "Микуличинского" - медового та свiтлого я вполне с Вами соглашусь :-D
Но по трезвому - вряд ли...
«Тут я отчасти опираюсь на статью Хоор "Обработка записей".»
Удалить-- Я совершенно не склонен глубоко обсуждать достоинства и недостатки обратной польской нотации.
Впрочем... Будете в Краснодаре - дайте мне знать... У нас есть ряд кабаков, где подают прекрасное пиво - мы можем обсудить, и обратную польскую запись и Путина, если пожелаете... :-D
"поскольку у меня сложилось впечатление о Вас, как о некоем евангелисте, открывшем для себя Священный Грааль и стремящегося распространить "знание" по миру."
Удалить1. Я конечно "неизлечимый евангелист". Но не такой "неизлечимый" как вы думаете.
2. Я "евангелирую" по-жизни. В основном "в курилке". И далеко не только UML.
3. UML я для себя не "открыл". Я его "прожил". И потратил лет 8-мь жизни.
4. Вы наверное не очень внимательно читали меня "серебряную" пулю - я не открыл. Про UML (в частности) я НЕ РАЗ писал - "это не догма".
5. Я всегда стараюсь слушать и анализировать "обратную связь". И ГОТОВ признавать свои ошибки.
6. Путина - не очень хочу обсуждать. Незачем. Мы с вами тут ничего не изменим.
7. Насчёт "неудачности" опыта - хотелось бы верить, что он всё же будет "удачен".
8. Собственно я и блог завёл потому, что "в курилке" стало скучно "евангелировать".
9. Я САМ написал много библиотек и фреймворков. Коллеги не дадут соврать. А они это - читают. Другое дело, что я что-то "продал" удачно, а что-то не "продал".
«8. Собственно я и блог завёл потому, что "в курилке" стало скучно "евангелировать".»
Удалить-- В таком случае мне остаётся Вам пожелать не разочароваться...
"В таком случае мне остаётся Вам пожелать не разочароваться..."
УдалитьЭто прощание или напутствие? :-)
Понятное дело - практика - "критерий истины" :-)
Если никто - не заинтересуется - я буду КОНЕЧНО расстроен. Но не разочарован. Мне кажется. Хотя - время покажет.
«Это прощание или напутствие? :-)»
Удалить-- Ни первое, ни второе :-)
Из Ваших комментариев у меня сложилось ощущение, что Вы ждёте одобрения и легко обижаетесь.
Если я не ошибся в сути (с формой можно спорить, но я не стану), то такое восприятие может легко привести к разочарованию в окружающем мире, в "нежелании" окружающих внять Вашему опыту и следовать ему. Негативное отношение к "евангелистам" (Вы первый упомянули это слово по отношению к создателям UML, "неожиданно" оказавшимися сотрудниками Rational Software)вполне естественно в сети.
«Понятное дело - практика - "критерий истины" :-)»
-- Это общие слова Александр... Это - ни о чём...
«Если никто - не заинтересуется - я буду КОНЕЧНО расстроен. Но не разочарован. Мне кажется. Хотя - время покажет.»
-- Заинтересовались. Продолжайте.
Но пока не ждите аплодисментов. Потому, что *пока* - рано.
"и легко обижаетесь."
Удалить-- ВООБЩЕ не обижаюсь :-)
"Вы ждёте одобрения"
-- конечно :-) Жду. Если его нет - ищу проблемы в себе :-)
"Но пока не ждите аплодисментов."
-- да и не ждал :-) но многое для себя понял :-)
«"и легко обижаетесь."
Удалить-- ВООБЩЕ не обижаюсь :-)»
-- Напрасно Вы это сказали... :-(
Ну да ладно, я совершенно не собираюсь углубляться в эту тему.
«"Вы ждёте одобрения"
-- конечно :-) Жду. Если его нет - ищу проблемы в себе :-)»
-- Идеологически выдержанный ответ... :-)
Личность многогранна - важно знать, где искать...
Но не обращайте здесь на меня внимания.
Смысл того, что я сказал в этом фрагменте можно раскрыть в объёме полумегабайта текста, но этот текст не укладывается в тематику Вашего блога...
"Это общие слова Александр... Это - ни о чём..."
Удалить"менторство".. ну да ладно :-) сам - грешу :-) не хочется ругаться.. да и незачем... мы все - ВЗРОСЛЫЕ люди.. глупо друг друга воспитывать.. :-)
"с формой можно спорить" - форма повествования? Или "стиль жизни"? Да - я "программист по-жизни".. Как раньше был "альпинистом" по-жизни :-)
"то такое восприятие может легко привести к разочарованию в окружающем мире, в "нежелании" окружающих внять Вашему опыту и следовать ему"
-- я СТОЛЬКО раз разочаровывался, что меня этим уже не проймёшь :-) Поверьте.
Кстати говоря про "анонимов" - я не имел в виду вас. Вы всё ПО ДЕЛУ пишете. Хотя и не всегда "приятное". Но это - нормально.
"-- Напрасно Вы это сказали... :-(
УдалитьНу да ладно, я совершенно не собираюсь углубляться в эту тему."
Жаль.. Видимо не "на волне".
"Но не обращайте здесь на меня внимания."
Зря вы так. Я вас внимательно слушаю. Вы хороший читатель и писатель.
"Смысл того, что я сказал в этом фрагменте можно раскрыть в объёме полумегабайта текста, но этот текст не укладывается в тематику Вашего блога..."
Заинтриговали конечно :-)
«"Это общие слова Александр... Это - ни о чём..."
Удалить"менторство".. ну да ладно :-) сам - грешу :-)»
-- Да, Вы "грешите" Александр. Причём усложняете тем самым себе задачу.
Да ещё и берётесь судить "с собственной колокольни" о словах других в форме обличения.
С моей стороны не было даже намёка на менторство.
Менторству свойственны афоризмы и избитые фразы. Мне это не нравится, тем более, что я знаю, чего стою.
"Практика - критерий истины" это банальность, свойственная менторству.
Пожалуйста, не обвиняйте меня в том, чего я не делал.
Извините. Наверное, я вас неправильно понял.
Удалить«"Ну, в Python отсутствует такой элемент шифрования, как обратная польская нотация :-)"
ОтветитьУдалить-- это - правда. Но ОПЗ - очень быстро преодолевается.
ДА и не всегда она плоха. Она часто соответствует "человеческой природе". Сначала - данные. Потом - действия с ними.
Но это опять же моё ИМХО.»
-- Вы, Александр, похоже совершенно не чувствуете, когда с Вами шутят :-)
Я ничего не имею против Forth и спокойно отношусь к обратной польской записи. Школа МК-61, так сказать... :-)
Если серьёзно... Я не думаю, что стоит создавать проблемы там, где их не предвидится. Можно привыкнуть и к обратной польской записи, но зачем это делать, если есть скобочная логика, а в нашем распоряжении мегабайты RAM, а не 15 регистров... :-)
"Вы, Александр, похоже совершенно не чувствуете, когда с Вами шутят"
УдалитьЯ понимаю когда шутят :-) но не стараюсь искать "шуток" там где их нет.
Что до Forth - я не вижу в нём проблем. ОПЗ - преодолевается. И легко. Могу дать вам ссылки на литературу.
Да и ОПЗ ВАЖНО только для арифметических операций. Для моих задач - они не так востребованы.
А Forth - не потому, что "15 регистров", а потому, что он (как вы верно заметили) хорошо подходит для DSL.
Да и не Forth в общем-то у меня вовсе. А Forth-машина (близкая к Java-машине) я надеюсь, что вы понимаете разницу.
«Что до Forth - я не вижу в нём проблем. ОПЗ - преодолевается. И легко. Могу дать вам ссылки на литературу.»
Удалить-- Я предпочитаю подходы, в которых не нуно ничего преодолевать, кроме сложности проблемы.
«А Forth - не потому, что "15 регистров", а потому, что он (как вы верно заметили) хорошо подходит для DSL.»
-- Не хочу спорить о Forth, хочу отметить только, что это не очень распространённая платформа, что само по себе "не способствует"...
«Да и не Forth в общем-то у меня вовсе. А Forth-машина (близкая к Java-машине) я надеюсь, что вы понимаете разницу.»
-- Разницу понимаю, но не вижу разницы в контексте обсуждаемой темы.
Этот комментарий был удален автором.
ОтветитьУдалитьЭтот комментарий был удален автором.
ОтветитьУдалитьАнонимный, у вас случайно ник не NTFS на kuban.ru?
ОтветитьУдалитьВот кстати Дмитрий знаком с одним из наших проектов. Может быть он откомментирует - сложный он или нет. Если захочет.
Удалить«Анонимный, у вас случайно ник не NTFS на kuban.ru?»
ОтветитьУдалить-- Нет. kuban.ru не посещаю.
Гарант или Арчи? Да, проекты сложные.
ОтветитьУдалить"Гарант или Арчи? Да, проекты сложные."
УдалитьСпасибо, Дмитрий.
Я имел в виду Арчи. Он - СЛОЖНЕЕ. Потому, что там не "read-only" система. Многопользовательская. С транзакциями. С СОБСТВЕННЫМ редактором. С СОБСТВЕННЫМ форматом данных. С СОБСТВЕННЫМ хранилищем.
Хотя я ЛИЧНО участвовал в обоих.
«Вот кстати Дмитрий знаком с одним из наших проектов. Может быть он откомментирует - сложный он или нет.»
Удалить-- Вот интересно - зачем Вы об этом? ;-)
"Вот интересно - зачем Вы об этом?"
Удалить-- просто потому, чтобы вы поняли, что я не только "hello world" написал :-)
Ещё раз - "никому ничего доказывать не хочу" :-) просто интересны чужие мнения.
Но если мнения в стиле "читайте книги" - это грустно. Хотя я про это уже оговорился.
Хотите общаться - будем общаться :-) я не обижаюсь на "свою неправоту" вот нисколько. Обижаюсь лишь на "менторство". Да и то - принимаю это на свой счёт.
«"Вот интересно - зачем Вы об этом?"
Удалить-- просто потому, чтобы вы поняли, что я не только "hello world" написал :-)
Ещё раз - "никому ничего доказывать не хочу" :-) просто интересны чужие мнения.»
-- Забавно :-)
Действительно - забавно!
Зачем Вам мне что-либо доказывать? :-)
Тем более, апеллируя к субъективному мнению человека, которого я не знаю?
Давайте, я остановлюсь на этом моменте, поскольку уже чувствую, что это следовало бы писать "в личку"...
«Но если мнения в стиле "читайте книги" - это грустно. Хотя я про это уже оговорился.»
-- Такое мнение, по крайней мере, с моей стороны, не было высказано.
Отсылка к литературе (причём, в общем смысле) означала, что мною лично применяются рекомендованные методы управления программным кодом, которые позволяют избежать проблем с сопровождением и развитием проекта.
По крайней мере Вас я никуда не отсылал.
И для меня является неожиданной *такая* интерпретация моих слов с Вашей стороны.
Или я опять неправильно Вас понял?
«Хотите общаться - будем общаться :-) я не обижаюсь на "свою неправоту" вот нисколько. Обижаюсь лишь на "менторство". Да и то - принимаю это на свой сч»
-- С моей стороны нет менторства, Александр. Вообще. Это - Ваше воображение, а не я.
И не будет. Я уже не в том возрасте и не собираюсь Вас ничему учить.
Извините. По-моему - мы друг-друга - не так поняли. Не стоит усугублять. Я думаю.
УдалитьЛучше "без оценочных суждений" на профессиональные темы общаться. Если интересно.
"что это следовало бы писать "в личку"..." - если интересно и есть что сказать - пишите. С интересом бы почитал. lulinalex@gmail.com
Я - ТОЖЕ не в том возрасте :-) Предлагаю - забыть этот инцидент.
Да нет никакого инцидента, Александр...:-)
УдалитьЯ настроен в отношении Вас более чем доброжелательно...
"Да нет никакого инцидента, Александр...:-)
УдалитьЯ настроен в отношении Вас более чем доброжелательно..."
-- ну и отлично! :-) Извините, если я вас чем-то задел. Не хотел. Правда.
Наверное не подбираю правильных слов.
Буду работать над собой :-)
По поводи 10-ти аналитиков - вы мне на МНОГОЕ глаза открыли :-)
УдалитьЯ отправил пост "в личку" :-)
УдалитьИзвините за некоторую сумбурность - 1,5 л. "Микуличинского" всё-таки... ;-)
«По поводи 10-ти аналитиков»
Удалить-- Аналитики разделяются между проектами.
Нет такого, чтобы аналитик-тестер работал на один проект.
И программисты, кстати, тоже.
Это способствует их профессиональному росту.
Кстати, здесь напрашивается некая параллель с литературой...
Обозначенное мною "разделение" сотрудников на совершенно разные задачи по совершенно разным проектам встречается во многих организациях, хотя об этом явно никто не пишет могу ошибаться, поскольку я не могу прочитать всё, что публикуется).
Это я к тому, что часто бывает так: нечто становится сначала общепринятой практикой, и только после этого закрепляется в литературе.
""Микуличинского" всё-таки..."
УдалитьЯ свою "цистерну" уже выпил.. Артрит и почки..
"Нет такого, чтобы аналитик-тестер работал на один проект.
УдалитьИ программисты, кстати, тоже."
-- вот тут - СТО ПРОЦЕНТОВ - СОГЛАСЕН.
Я к сожалению не могу донести эту мысль до тех, кто решения принимает.
«"Нет такого, чтобы аналитик-тестер работал на один проект.
УдалитьИ программисты, кстати, тоже."
-- вот тут - СТО ПРОЦЕНТОВ - СОГЛАСЕН.
Я к сожалению не могу донести эту мысль до тех, кто решения принимает.»
-- А тут есть одна технологичекая тонкость, которая всё портит... :-)
Улыбаюсь потому, что "диавол", как ни пошло это звучит, кроется в деталях...
В мэйнстриме так сложилось, что аналитик и тестер - это два совершенно различных вида деятельности. Это влияет на подготовку сотрудников после приёма на работу и их специализацию, на предъявляемые требования при приёме на работу, на представление о границах собственной ответственности, наконец.
Для нас очевидно, что это порочная практика и дикость, когда мы узнаём, что кое-где тестирование производится посредством анализа исходного кода.
Аналитик, непосредственно взаимодействующий с пользователем, только он может быть тестером. Он - представитель пользователя у нас. Он - адвокат пользователя и он же, во взаимодействии с пользователем должен обеспечивать компромисс требований. В том смысле, что требования должны органично вписываться в создаваемую модель, гарантируя её непротиворечивость.
С точки зрения управления, руководство должно способствовать здоровому антагонисту таких аналитиков с программистами, поскольку в условиях конкуренции и рождается то, что нужно.
Ну... Где-то так... :-)
"В мэйнстриме так сложилось, что аналитик и тестер - это два совершенно различных вида деятельности. "
Удалитьвот вот...
"Аналитик, непосредственно взаимодействующий с пользователем, только он может быть тестером."
"С точки зрения управления, руководство должно способствовать здоровому антагонисту таких аналитиков с программистами, поскольку в условиях конкуренции и рождается то, что нужно."
логично
Этот комментарий был удален автором.
ОтветитьУдалитьХорошо бы Арчи внедрить в органы власти - чтобы чиновники сразу форматировали свои документы в Арчи и выдавали нам готовые NSR :)
ОтветитьУдалитьСпасибо за интересную дискуссию.
ОтветитьУдалитьИ спасибо что сделали её публичной.
Насчет метрик.
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. Люди которые в принципе могут настроить серваки. Узнать проблемы по логу. Решить проблемы с внесением данных в БД. Да впринципе всё то что не решается именно кодированием.
Кол-во клиентов, даже хз как считать, в пользователях ? В кол-ве БД ? Есть целые города работающие на нашей программе. Имею в виду коммунальные службы.
Спасибо. ОЧЕНЬ познавательно.
УдалитьJira - у нас свой аналог. На основе Confluence. Ну вы понимаете.
Git - CVS/SVN.
FishEye - ИСПОЛЬЗУЕМ!
TDD - могу "посоветовать" - не воспринимайте его как "догму".
Scrum - я лично - "не вкурил".
UML - буду рад помочь советом, если что.
"Есть документ страниц на 80 описывающий стандарт кодирования." - если "вдруг" решите поделится тем как вы "валидируете" его исполнение - был бы рад.
"Сапо = 500к строк.
Ломбард = 110к строк." - ИМХО - немного. Но и не мало.