Здравствуйте, Gaperton, Вы писали:
G>В целом, если разобрать основные траты времени, специфичные для существующего кода, их будет не так много: G>1) Затраты на диагностику проблем/разбор ситуаций — понимание, почему именно оно так работает в конкретном случае. Это, по сути, восстановление "детального дизайна". G>2) Затраты на reverse engineering (понимание, как оно в целом устроено и работает. "дизайн"+"детальный дизайн"). G>3) Затраты на рефакторинг (изменение без добавления/изменения функциональности, но, возможно, с одновременным исправлением дефектов).
Кстати, существует довольно обширный класс ошибок, которые легко фиксятся без понимания как работает система не только в целом, но даже исследуемая её часть.
G>Если бы тебе не приходилось на этот работающий код времени тратить, ты бы не стал его трогать, правильно?
Абсолютно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Кстати, существует довольно обширный класс ошибок, которые легко фиксятся без понимания как работает система не только в целом, но даже исследуемая её часть.
Бывает. Но вообще говоря — "симптоматическое лечение поциента" — это ай-ай-ай. Иногда, впрочем, бывает, что выхода другого нет.
Насчет фаз — я, помнится, выделял три фазы работы над дефектом.
1) "А что вообще происходит". Завершается, когда ты признал наличие проблемы (либо объяснил, что это не дефект, и тогда ваще все), смог сам воспроизвести ситуацию, и в состоянии работать с ней дальше без тестера. Иногда бывает, что это длительная фаза.
2) "Загон зверя". Завершается, когда ты понял root cause дефекта. То есть, ты в состоянии по шагам показать, как так выходит, что дефект проявляется, и почему. Вовсе не обязательно ты в этот момент знаешь, что тебе делать, и как эту дичь исправлять. На этой фазе добывается понимание, как система работает, необходимое для описания root cause.
3) "Добивание". Собственно, раздумья над фиксом, завершаются его реализацией, и коммитом. Иногда бывает, что это дольше, чем все предыдущее, потому, что понимания для внесения правки требуется куда больше. Здесь ты можешь принять решение провести рефакторинг, если дефектов в найденном месте гнездо.
Дефекты могут быть классифицированы на типы по грубому соотношению времен этих фаз. Не то, штоб для какой-то специальной цели — но надо ж их, зараз, как-то различать, когда на поддержке работаешь? Ну, типо как у эскимосов в языке 20 названий разного снега .
Скажем, по вырожденности фаз, когда время на какой-либо из них близко к нолю. Например, бывает, что фикс совершенно очевиден при окончании фазы 2. Фаза (3) длительна тогда, когда ты оказался в непростой ситуации. Это, в общем, само по себе индикатор того, что с кодом все крайне запущено.
Здравствуйте, Gaperton, Вы писали:
IT>>Отношением к ним. G>Приведи пожалуйста пример "заведомо геморройной" задачи, не подпадающей ни под один из трех типов.
Задача, которую я приводил выше. Да любая задача, требующая ковыряния в коде заведомо низкого качества.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
G>Это я и так отлично знаю.
G>Меня интересует другое. "Сложность" существует объективно, вот и хочется понять какие факторы влияют на нее. И как можно бороться с объективной сложностью, чтобы минимизировать итоговые метрики "объем", "время", "плотность ошибок"
Сложность это количество простейших умозаключений + количество простейших механических действий которые необходимо совершить, что бы решить задачу.
Соответсвенно, нужно уменьшать это количество, за счет
1. использования высокоуровневых конструкций
2. использования высокоуровневых инструментов
Здравствуйте, IT, Вы писали:
IT>Я уже своё отруководил. Лет 6 начальником группы/сектора в одном НИИ, потом 4 года начальником отдела разработки ПО в одной программистской конторе. В целом — не понравилось Руководить людьми не моё.
В линкедине у тебя написано вице-президент Морган Стенли, это руководящя должность или где ?
"Пол сотни программистов, шесть воркстримов на проекте " — ты один из этих "пол сотни" или ты руководишь этой кухней ?
Здравствуйте, Ikemefula, Вы писали:
IT>>Я уже своё отруководил. Лет 6 начальником группы/сектора в одном НИИ, потом 4 года начальником отдела разработки ПО в одной программистской конторе. В целом — не понравилось Руководить людьми не моё. I>В линкедине у тебя написано вице-президент Морган Стенли, это руководящя должность или где ?
Это звание, а не должность. Как погоны у военных. Можно иметь много звёзд, но не иметь при этом ни одного человека в прямом подчинении.
I>"Пол сотни программистов, шесть воркстримов на проекте " — ты один из этих "пол сотни" или ты руководишь этой кухней ?
Это был один проект в IBM. Там я был архитектором и руководил в основном диаграммами и схемами
Если нам не помогут, то мы тоже никого не пощадим.
FR>>Так что награда есть и вполне осязаемая, кто испытывал "второе дыхание" сразу поймет
G>Здесь не идет речи о награде. Здесь они нудно описывают наблюдаемые особенности физиологии, не осознаваемые испытуемым, перечисляя установленные ими факты.
Угу, но на своей шкуре в потоке на самом деле не устаешь.
Факты ими установленные с этим совпадают.
G>Далее, углубившись в анализ ЭЭГ и альфа-ритмов, и накидывая over 9000 умняка, чтобы усыпить бдительность читателя и навести легкий транс, автор статьи ВНЕЗАПНО вдруг говорит:
G>
G>Таким образом, результаты М. Чиксентмихайи могут быть дополнены еще одним элементом, который может быть использован сознательно для вызывания состояния «потока». Используя терминологию нейро-лингвистического программирования, можно сказать, что связное дыхание служит при этом для «якорения» состояния «потока». Более того, существует реальная возможность создавать физиологические и нейропсихологические предпосылки для вызывания ресурсных, творческих состояний личности – процессы осознанного связного дыхания.
Это похоже уже второй автор подключился психолого притом из "новых" гуманистических
G>Что представляет собой полный бред, который автор даже не потрудился как-то обосновать. Ибо перед этим он вещал:
Психологам тоже кушать хочется
G>Это комплексное состояние, оно неустойчиво, и его нельзя вызвать "якорями" и какими-либо другими заклинаниями. Так же бессмысленно и глупо, как и вызвать ощущение радости от победы.
Угу.
G>Вы "полагаетесь" на "ощущение победы", которое дает заряд бодрости и прилив новых сил? Оно "позабыто" и атрофировалось? Может быть, для него нужны сложная психология, и физиологи с аппаратами?
G>Или для того, чтобы вызвать это ощущение — надо победить, черт бы его побрал?
Все таки ты сравниваешь мягкое с зеленым
Поток все-таки не такое узкоспециализированное ощущение, да и не ощущение вовсе, это состояние и сравнивать его надо именно с состояниями — сном, бодрствованием, трансом и гипнозом.
G>Так же и для поддержания состояния "потока" нужны не альфа ритмы и особое дыхание. Человек не система веревочек, за которые можно тупо дергать. Нужен набор факторов, поддерживающих спонтанный интерес и свободно перетекающее внимание. Следствием этого являются возбуждение, особенности дыхания, и прочие вещи, которые увлеченно наблюдает автор статьи, делая из бодрый вывод, что "таракан слышит ногами".
Понятно что правильно задышав и подстроив альфа ритмы в поток не войдешь, но и знание о том что поток по сути полезен для здоровья не лишнее.
G>НЛПсты не психологи. Они такие же психологи, как продавцы скрама специалисты по процессам разработки, а продавцы пищевых добавок — фармацевты. НЛП — это инфраструктура по зарабатыванию бабла, а не наука.
НЛПисты да, но это вообще традиционно для (около)психологии те же психоаналитики недалеко от них ушли.
G>С когнитивными психологами бихейвиористов не путаете? Нет у них никакого черного ящика. Методы бихейвиористов основаны на модели психики, в основе которой лежит система условных рефлексов. В частности, "непавловском условном рефлексе". И в своем классе ситуаций бихейвиористика потрясающе эффективна — напоминает магию. НЛПстам не снилось. Собственно, НЛП сдернуло большую часть именно у бихейвиористов, выкинув при этом всю теоретическую базу.
Вроде нет, но возможно слишком много читал советских психологов не особо жалующих бихейвиористов
FR>>лучше уж физиологов почитать, к примеру того же Бернштейна у него хоть вполне рабочие модели подкрепленные фактами.
G>Это примерно так же продуктивно, как пытаться реверс-инжинирить оперсистему Windows, копаясь на уровне транзисторов, замера времянок, и спиливания печатной платы по слоям.
Не это скорее ядро, прерывания и низкоуровневое программирование
G>Скажем, практический интерес представляет "мышечный панцирь", и, в частности, связь переживания тревожности с неконтроллируемым напряжением диафрагмы. Связь есть, она экспериментально наблюдается, она двухсторонняя, и этим можно пользоваться.
G>А что там происходит с точки зрения физиологии при переживании тревожности — абсолютно по барабану. Понимание, совершенно лишнее для действия.
Бернштейн как раз один из основоположников современной биомеханики и психофизиологии и у него много захватывается именно пси притом на достаточно высоком уровне, вплоть до мотивации http://flogiston.ru/library/bernstein
Здравствуйте, Ikemefula, Вы писали:
FR>>Угу, но на своей шкуре в потоке на самом деле не устаешь. FR>>Факты ими установленные с этим совпадают.
I>Вообще говоря в потоке ты устаёшь, только не замечаешь этого.
Да конечно устаешь, но устаешь меньше выполняя более сложную работу чем вне потока.
Здравствуйте, thesz, Вы писали:
S_>>Бывают задачи простые,краткие, с недвусмысленными условиями.Но с очень сложным решением. T>Пример?
Докажите, что для раскраски любой карты на плоскости достаточно четырёх красок.
Докажите, что A^Z+B^Z=C^Z не имеет решения в целых числах для Z>3.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, FR, Вы писали:
G>>Здесь не идет речи о награде. Здесь они нудно описывают наблюдаемые особенности физиологии, не осознаваемые испытуемым, перечисляя установленные ими факты.
FR>Угу, но на своей шкуре в потоке на самом деле не устаешь. FR>Факты ими установленные с этим совпадают.
В потоке не замечаешь, как устаешь, по причине, знакомой каждому, но не наблюдаемой их методами.
По причине постоянной заинтересованности в предмете. Предмет является настолько сильной "фигурой", что ощущения усталости, голода, и пр. находятся в "фоне".
Для гештальт-психологии описание состояния "потока" — одноходовка. По физиологическим критериям — его надежно хрен установишь. И непонятно, зачем это вообще делать.
G>>Или для того, чтобы вызвать это ощущение — надо победить, черт бы его побрал?
FR>Все таки ты сравниваешь мягкое с зеленым FR>Поток все-таки не такое узкоспециализированное ощущение, да и не ощущение вовсе, это состояние и сравнивать его надо именно с состояниями — сном, бодрствованием, трансом и гипнозом.
Не надо. Сон, бодрствование, транс, и гипноз — устойчивые состояния. "Поток" — нет.
FR>Вроде нет, но возможно слишком много читал советских психологов не особо жалующих бихейвиористов
Советсткие психологи не жаловали не только бихейвиористов, — но вообще по большей части всю психологию. По сугубо идеологическим соображениям.
Поэтому, наверное, и не оставили миру значимого наследия, мало-мальски сравнимого с "западными" школами.
G>>Это примерно так же продуктивно, как пытаться реверс-инжинирить оперсистему Windows, копаясь на уровне транзисторов, замера времянок, и спиливания печатной платы по слоям.
FR>Не это скорее ядро, прерывания и низкоуровневое программирование
Физиология — это таки транзисторы и провода . Грубая, но точная аналогия: психология — это софт, психиатрия — хард. "Психиатрические" заболевания обусловлены биохимией, "психологические" же проблемы — с биохимией не связаны и допускают "психокоррекцию". Литий колоть вовсе не обязательно, чтобы приступ купировать. Все. Разница объективно наблюдаема.
Попытки притянуть физиологию к объяснению психологических эффектов идут от непонимания этой разницы — что причина, а что следствие. Физиология — это как протокол транспортного уровня по отношению к прикладному. Хоть голубиной почтой доставляй пакеты — на логику приложения не влияет.
G>>А что там происходит с точки зрения физиологии при переживании тревожности — абсолютно по барабану. Понимание, совершенно лишнее для действия.
FR>Бернштейн как раз один из основоположников современной биомеханики и психофизиологии и у него много захватывается именно пси притом на достаточно высоком уровне, вплоть до мотивации http://flogiston.ru/library/bernstein
Здравствуйте, Gaperton, Вы писали:
G>В потоке не замечаешь, как устаешь, по причине, знакомой каждому, но не наблюдаемой их методами.
G>По причине постоянной заинтересованности в предмете. Предмет является настолько сильной "фигурой", что ощущения усталости, голода, и пр. находятся в "фоне".
G>Для гештальт-психологии описание состояния "потока" — одноходовка. По физиологическим критериям — его надежно хрен установишь. И непонятно, зачем это вообще делать.
Психология все-таки не наука, психологи могут "описать" и "объяснить" любые факты, которые до этого в упор не видели. Это и поток и гипноз и транс.
Ну и по физиологическим параметрам даже сон от бодрствования не всегда однозначно различается.
G>Не надо. Сон, бодрствование, транс, и гипноз — устойчивые состояния. "Поток" — нет.
Зависит от глубины, также как и у остальных состояний. Бывает так затянет что все вокруг исчезает
G>Советсткие психологи не жаловали не только бихейвиористов, — но вообще по большей части всю психологию. По сугубо идеологическим соображениям.
G>Поэтому, наверное, и не оставили миру значимого наследия, мало-мальски сравнимого с "западными" школами.
А зачем сравнивать всю западную где население было чуть не в 10 раз больше и советскую? А так вполне на нормальном уровне была,
идеология конечно ее прилично ограничила, вот тут взгляд из запада http://scepsis.ru/library/id_666.html
FR>>Не это скорее ядро, прерывания и низкоуровневое программирование
G>Физиология — это таки транзисторы и провода . Грубая, но точная аналогия: психология — это софт, психиатрия — хард. "Психиатрические" заболевания обусловлены биохимией, "психологические" же проблемы — с биохимией не связаны и допускают "психокоррекцию". Литий колоть вовсе не обязательно, чтобы приступ купировать. Все. Разница объективно наблюдаема.
Это да, я не вообще про физиологию, разделение правильное, но это не отменяет существование ни психофизиологии ни системных программистов
G>Попытки притянуть физиологию к объяснению психологических эффектов идут от непонимания этой разницы — что причина, а что следствие. Физиология — это как протокол транспортного уровня по отношению к прикладному. Хоть голубиной почтой доставляй пакеты — на логику приложения не влияет.
Это у нас не влияет, у них все гораздо хуже, комп наполовину аналоговый и хард на софт влияет и наоборот тоже.
Здравствуйте, Gaperton, Вы писали:
G>И не говори. Совсем распоясались. Как напьются — так сразу в "философию программирования" буянить.
А я вот скромный, я сдерживаюсь — чивас и сигара, и за вами наблюдать из-за укрытия.. =))
Здравствуйте, IT, Вы писали:
IT>Трудоёмеость в программировании — это в чистом виде субъективная оценка конкретного индивидуума сроков выполнения его проектов, IT>построенная на его предпочтениях. Можно, конечно, выявлять закономерности, но работать это будет в строго ограниченных рамках.
А почему такую статистику нельзя применять with respect to конкретному человеку, к его предпочтениям.
Т.е. например добавил 1-октябра индивидум 1 статический класс, и чекины за следущие две недели показывают что код начинает расти
со скоростью 300 строк в день +-100 , и какие нибудь cyclomatic complexity стабильно низкая и прыгает в примерно таких границах.
А если он 1 декабря индивдум 1 добавил базовый класс для Visitora — то за следущие две недели он код растет то по 100 строчек
в день, то по 1000, то вообще уменьшается, комплексити прыгает как сумасшедшая, классы то добавляются, то убираются, ну и
так далее.
Т.е. в принципе можно, если будет достаточная статистика (по индивидуму) — можно будет вывести заранее к чему приведет то или иное его/ее действие.
Тут конечно много допущений, как то код чекиниться через равные промежутки времени, индивидумы работают не на
пятью совсем разными проектами (что в общем-то нормально для тех кто поддерживает старый код), а более менее
постоянно над одним.
Здравствуйте, Igor Sukhov, Вы писали:
IT>>Трудоёмеость в программировании — это в чистом виде субъективная оценка конкретного индивидуума сроков выполнения его проектов, IT>>построенная на его предпочтениях. Можно, конечно, выявлять закономерности, но работать это будет в строго ограниченных рамках. IS>А почему такую статистику нельзя применять with respect to конкретному человеку, к его предпочтениям.
Попробуй.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>Трудоёмеость в программировании — это в чистом виде субъективная оценка конкретного индивидуума сроков выполнения его проектов, IT>>>построенная на его предпочтениях. Можно, конечно, выявлять закономерности, но работать это будет в строго ограниченных рамках. IS>>А почему такую статистику нельзя применять with respect to конкретному человеку, к его предпочтениям.
IT>Попробуй.
вот как будет такая тула — обязательно попробую. интересно — есть что то подобное под TFS & SVN?
Здравствуйте, Igor Sukhov, Вы писали:
IS>>>А почему такую статистику нельзя применять with respect to конкретному человеку, к его предпочтениям. IT>>Попробуй. IS>вот как будет такая тула — обязательно попробую. интересно — есть что то подобное под TFS & SVN?
Тула, считающая строки? Игорь, ты же вроде взрослый человек, даже XBox уже сам себе покупаешь, а всё ещё веришь в строчки кода
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IS>>>>А почему такую статистику нельзя применять with respect to конкретному человеку, к его предпочтениям. IT>>>Попробуй. IS>>вот как будет такая тула — обязательно попробую. интересно — есть что то подобное под TFS & SVN?
IT>Тула, считающая строки? Игорь, ты же вроде взрослый человек, даже XBox уже сам себе покупаешь, а всё ещё веришь в строчки кода
тула которая сможет определить источник проблем в проекте. т.е. где проблемность сконценрирована, откуда она взялась, и что с ней станет через месяц, если не боротся.
дело конечно не в строчках, а в метриках файлов, классов, их связей между друг другом. это конечно не метрики на уровне кода (но такое и сделать сложннее — надо будет парсить код методов) — т.е. таким макаром не определишь качество внутри ф-и (хотя конечно оно и важно), но в большинсве случае если проблемы пошли то они будут видны и на уровне файлов, классов, функций, но хотя бы что-то.