Про ёжика в тумане, зазнайство, языки программирования и вериги
Когда трава была зеленее, небо выше, за компьютерами работали люди с натуральным высшим образованием, и ещё существовали программы, не содержащие ошибок, были известны и использовались многие очень полезные методы, технологии и приёмы.
Сейчас они применяются только старыми опытными профессионалами, по какой-то причине не ушедшими в менеджмент. Иногда можно найти их изуродованные и раскрашенные под лубок следы в «передовых изобретениях» и «новейших открытиях». Современные учёные компьютерных наук и производители ррреволюционных тулов, когда с ними заговариваешь на эту тему, делают круглые глаза и уходят в несознанку. Подрастающее поколение вообще не понимает о чём речь. И только в редких случаях, в особо интимной обстановке коллегиальной пьянки можно изредка услышать от престарелых гуру и консультантов «Да. Конечно оно так. И лучше. И надёжнее. Но, ты понимаешь, спросом не пользуется.»
Почему так произошло? Одна из причин, неумолимый закон ИТ индустрии Worse is better. Про него все знают и я не буду дальше раскрывать этот аспект. А вот о другой, не менее существенной причине, я расскажу ниже.
Про зазнайство, жестокосердие и утерянные технологии
Из всего потерянного на пути от научной разработки к индийским программистам мне больше всего не хватает STT (State Transition Table).
Конечный автомат получает сигнал, переходит в новое состояние и выполняет какие-то операции. Или в другом варианте получает сигнал, выполняет какие-то операции и переходит в новое состояние.
Новое состояние может быть тем же самым. В определённом состоянии конечный автомат может игнорировать какие-то сигналы, и есть сигналы, которые в таком состоянии придти не могут. То есть, если мы их получаем, то где-то в логике работы системы закралась ошибка.
Всё просто и банально. Можно запрограммировать это большой бородой if-else, можно нарисовать диаграммку с кучей стрелочек. Можно жульнически написать на функциональном языке, таская состояние в параметрах вызова. Чего нельзя сделать, так это описать в туле сигналы и состояния, сгенерить таблицу, расставить значения по клеточкам, а потом нажать кнопку и получить в одном окне красивые диаграммки, а в другом - работающий код.
Даже те редкие тулы, которые это умели, не в состоянии делать это в новых версиях. Разве что кроме тех немногих, что обитают где-то на задворках индустрии, не очень удобны в применении и дороги как престарелая Нокия, инкрустированная бриллиантами.
Если то, что тебе нужно, нельзя ни купить, ни найти, сделай это сам. Слева - сигналы, справа - состояния.
[Spoiler (click to open)]
private static final int[][] STATE_TABLE = {
//=========================================================================================================|
// | INIT | CHECK_PRECOND | REGISTRATION | WAIT_ACCEPTED | LEVEL_OK |
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* START */ { CHECK_PRECOND , INT_ERROR , INT_ERROR , INT_ERROR , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* PRE_CONDITIONS */ ,{ INIT , REGISTRATION , INT_ERROR , WAIT_ACCEPTED , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* NOT_PRE_CONDITIONS */ ,{ INIT , INIT , INT_ERROR , INT_ERROR , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* REGISTRATION_DONE */ ,{ INIT , CHECK_PRECOND , WAIT_ACCEPTED , INT_ERROR , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* REGISTRATION_FAIL */ ,{ INIT , INT_ERROR , INIT , INT_ERROR , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* ACCEPTED */ ,{ INIT , INT_ERROR , INT_ERROR , LEVEL_OK , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* INT_ERROR */ ,{ INT_ERROR , INT_ERROR , INT_ERROR , INT_ERROR , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
};
Выше почти не изменённый код реального проекта. На прошлой неделе я сделал нечто подобное снова, уже на другом языке и немного по-другому.
В чём тут фокус?
Первым делом я могу изменить логику поведения системы, просто поменяв одно значение на другое. Можно записать логику в файл и передать её по сети. Можно сгенерировать UML State Transition Diagram. Но всё это полезные добавления. Главным и наиболее ценным свойством является жестокосердие.
Сигналы и переходы полностью описывают поведение конечного автомата. То есть: полностью. Я могу забыть какой-то сигнал и получить ошибку в тесте или в поле. Я могу забыть состояние и получить поведение, не соответствующее требуемому. Я могу поставить в клеточку фигню или просто ошибиться. Чего я не могу сделать - это проигнорировать комбинацию сигнала и состояния.
Как-то я сделал подобную таблицу в Экселе и, когда на митинге она возникла на экране, сказал примерно следующее:
- Уважаемые коллеги. Я внимательно прочитал главу техзадания с функциональными требованиями. Все двадцать восемь страниц, и изучил все стоящие там картинки. Я формализовал то, что я понял. Но тут есть два места, где стоят толстые красные вопросительные знаки. Что должно произойти в этих двух случаях? Должно тут стоять «IGNORE», «ERROR» или что-нибудь ещё?
Минут пять продолжалась борьба с «Я не понимаю» и «У нас нет времени, давайте обсудим что-нибудь другое», а последующее вылилось в сорок минут обсуждения, неделю перекидывания мейлами и серьёзные изменения в финальной версии техзадания.
Это очень долгий, очень недемонстрационный процесс. Практически час митинга на то, чтобы написать два значения.
Практически все жестокосердные методики столь же компактны. Как-то мы с одним мужиком писали функциональную спецификацию на псевдокоде. Средняя цена вышла по одному человекочасу на две строчки.
Шестьдесят строчек - это одна страница. Покажите менеджеру документ и скажите, что страница стоит тысячу евро. И посмотрите на его лицо.
А теперь представьте, что с другого бока к этому менеджеру подходит экзальтированный Skrum Master и обещает счастье для всех, почти даром, и так, что никто от него не укроется.
Я частенько писал документацию, где страница стоила и в десять раз больше. Но это было скрыто в куче митингов, разъездов, мейлов, и никому не нужной писанины. Но попробуйте сказать среднему нормальному менеджеру, что целью недели работы будет десяток страниц текста.
Да, из этого псевдокода были сгенерированы диаграммы. На его основе были расставлены приоритеты. Открытые ошибки были отклассифицированы и расставлены по релизам. В результате проект вышел из штопора и смог скрипя и почти не разваливаясь доползти до стадии он-лайн.
Но сделать этот документ удалось только потому, что менеджменту было просто пофиг, чем мы там вдвоём с этим мужиком занимаемся. Менеджмент в это время храбро тонул в потоке новостей от отдела тестирования, что дало нам окно для свободной работы.
Конечно, таблица тридцать на тридцать - это место, где можно закопаться всерьёз и надолго. Но тем и отличается аналитик от аналоха, что он сделает не это, а три размерностью десять на десять. Чтобы было понятно. И чтобы задача решалась просто. Но даже таблица на девять сотен не проставленных реакций на сигнал лучше, чем её отсутствие. Потому что бардак будет точно такой же, а вот увидеть его в полном объёме не удастся даже настоящим экспертам.
Но самое главное, самое ценное для результата и самое вредное для распространения STT в массах - выше упомянутое жестокосердие. Это безжалостная методика, не дающая поблажек.
Тут нельзя нарисовать или не нарисовать стрелочку так, чтоб никто этого не заметил. В ячейке таблицы стоит или IGNORE, или ERROR, или новое состояние, или жирный красный вопросительный знак. И ни умные рассуждения о перспективах развития энтерпрайза, ни рассказы о важности и не важности, ни упоминания послемитингового обеда не ответят на вопрос «Что должно тут быть и почему?»
В немецкой культуре люди привыкли, что у каждой проблемы есть ответ, и этот ответ им известен. Причём, известен на уровне экспертном. Если, вдруг, ответ не известен, то вопрос ерундовый и малозначащий. И они экспертно объяснят это.
Порой приходиться выслушивать совершенно бредовые рассуждалки на уровне детского сада. Причём, все как-бы знают, что это может быть не совсем правильно и не совсем так. Но, если высказывание сделано громким уверенным голосом, человеком обличённым экспертными полномочиями, то так оно и есть. И сомневаться просто не прилично. Примерно на том же уровне, как ковыряться в носу за обедом.
Обычно у меня статус эксперта и мне часто задают разные вопросы. Иногда дельные, иногда идиотские. Но это как-бы получение дополнительных и не относящихся к области компетенции знаний из правильного источника. Только один раз ко мне подошёл коллега не из русскоговорящих и сказал «Слушай, у меня есть один глупый вопрос.» Он был студентом. И французом.
А вот этот гадкий жирный вопросительный знак в клетке STT таблицы как заноза встаёт посреди корпоративной культуры, плюёт на все написанные в визитке «Доктор Компьютерных Наук» или «Самый Главный Аналитик» и заставляет выдавить из себя предательское «Не знаю.»
У всех производителей тулов, которые поддерживали SST я постоянно спрашивал, есть ли у них, вдруг, клиенты в Германии. Ответ был неизменно отрицательным.
Продолжение может быть будет когда-нибудь потом. Сейчас хочется вернуться к более весёлым темам
Copyright
(CC BY-NC-ND 3.0) vit_r, 2012
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
Перевод на английский запрещён, потому как нефиг портить хорошую вещь.
Сейчас они применяются только старыми опытными профессионалами, по какой-то причине не ушедшими в менеджмент. Иногда можно найти их изуродованные и раскрашенные под лубок следы в «передовых изобретениях» и «новейших открытиях». Современные учёные компьютерных наук и производители ррреволюционных тулов, когда с ними заговариваешь на эту тему, делают круглые глаза и уходят в несознанку. Подрастающее поколение вообще не понимает о чём речь. И только в редких случаях, в особо интимной обстановке коллегиальной пьянки можно изредка услышать от престарелых гуру и консультантов «Да. Конечно оно так. И лучше. И надёжнее. Но, ты понимаешь, спросом не пользуется.»
Почему так произошло? Одна из причин, неумолимый закон ИТ индустрии Worse is better. Про него все знают и я не буду дальше раскрывать этот аспект. А вот о другой, не менее существенной причине, я расскажу ниже.
Про зазнайство, жестокосердие и утерянные технологии
Из всего потерянного на пути от научной разработки к индийским программистам мне больше всего не хватает STT (State Transition Table).
Конечный автомат получает сигнал, переходит в новое состояние и выполняет какие-то операции. Или в другом варианте получает сигнал, выполняет какие-то операции и переходит в новое состояние.
Новое состояние может быть тем же самым. В определённом состоянии конечный автомат может игнорировать какие-то сигналы, и есть сигналы, которые в таком состоянии придти не могут. То есть, если мы их получаем, то где-то в логике работы системы закралась ошибка.
Всё просто и банально. Можно запрограммировать это большой бородой if-else, можно нарисовать диаграммку с кучей стрелочек. Можно жульнически написать на функциональном языке, таская состояние в параметрах вызова. Чего нельзя сделать, так это описать в туле сигналы и состояния, сгенерить таблицу, расставить значения по клеточкам, а потом нажать кнопку и получить в одном окне красивые диаграммки, а в другом - работающий код.
Даже те редкие тулы, которые это умели, не в состоянии делать это в новых версиях. Разве что кроме тех немногих, что обитают где-то на задворках индустрии, не очень удобны в применении и дороги как престарелая Нокия, инкрустированная бриллиантами.
Если то, что тебе нужно, нельзя ни купить, ни найти, сделай это сам. Слева - сигналы, справа - состояния.
[Spoiler (click to open)]
private static final int[][] STATE_TABLE = {
//=========================================================================================================|
// | INIT | CHECK_PRECOND | REGISTRATION | WAIT_ACCEPTED | LEVEL_OK |
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* START */ { CHECK_PRECOND , INT_ERROR , INT_ERROR , INT_ERROR , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* PRE_CONDITIONS */ ,{ INIT , REGISTRATION , INT_ERROR , WAIT_ACCEPTED , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* NOT_PRE_CONDITIONS */ ,{ INIT , INIT , INT_ERROR , INT_ERROR , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* REGISTRATION_DONE */ ,{ INIT , CHECK_PRECOND , WAIT_ACCEPTED , INT_ERROR , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* REGISTRATION_FAIL */ ,{ INIT , INT_ERROR , INIT , INT_ERROR , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* ACCEPTED */ ,{ INIT , INT_ERROR , INT_ERROR , LEVEL_OK , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
/* INT_ERROR */ ,{ INT_ERROR , INT_ERROR , INT_ERROR , INT_ERROR , INT_ERROR }
//--------------------------+----------------+---------------+---------------+---------------+-------------|
};
Выше почти не изменённый код реального проекта. На прошлой неделе я сделал нечто подобное снова, уже на другом языке и немного по-другому.
В чём тут фокус?
Первым делом я могу изменить логику поведения системы, просто поменяв одно значение на другое. Можно записать логику в файл и передать её по сети. Можно сгенерировать UML State Transition Diagram. Но всё это полезные добавления. Главным и наиболее ценным свойством является жестокосердие.
Сигналы и переходы полностью описывают поведение конечного автомата. То есть: полностью. Я могу забыть какой-то сигнал и получить ошибку в тесте или в поле. Я могу забыть состояние и получить поведение, не соответствующее требуемому. Я могу поставить в клеточку фигню или просто ошибиться. Чего я не могу сделать - это проигнорировать комбинацию сигнала и состояния.
Как-то я сделал подобную таблицу в Экселе и, когда на митинге она возникла на экране, сказал примерно следующее:
- Уважаемые коллеги. Я внимательно прочитал главу техзадания с функциональными требованиями. Все двадцать восемь страниц, и изучил все стоящие там картинки. Я формализовал то, что я понял. Но тут есть два места, где стоят толстые красные вопросительные знаки. Что должно произойти в этих двух случаях? Должно тут стоять «IGNORE», «ERROR» или что-нибудь ещё?
Минут пять продолжалась борьба с «Я не понимаю» и «У нас нет времени, давайте обсудим что-нибудь другое», а последующее вылилось в сорок минут обсуждения, неделю перекидывания мейлами и серьёзные изменения в финальной версии техзадания.
Это очень долгий, очень недемонстрационный процесс. Практически час митинга на то, чтобы написать два значения.
Практически все жестокосердные методики столь же компактны. Как-то мы с одним мужиком писали функциональную спецификацию на псевдокоде. Средняя цена вышла по одному человекочасу на две строчки.
Шестьдесят строчек - это одна страница. Покажите менеджеру документ и скажите, что страница стоит тысячу евро. И посмотрите на его лицо.
А теперь представьте, что с другого бока к этому менеджеру подходит экзальтированный Skrum Master и обещает счастье для всех, почти даром, и так, что никто от него не укроется.
Я частенько писал документацию, где страница стоила и в десять раз больше. Но это было скрыто в куче митингов, разъездов, мейлов, и никому не нужной писанины. Но попробуйте сказать среднему нормальному менеджеру, что целью недели работы будет десяток страниц текста.
Да, из этого псевдокода были сгенерированы диаграммы. На его основе были расставлены приоритеты. Открытые ошибки были отклассифицированы и расставлены по релизам. В результате проект вышел из штопора и смог скрипя и почти не разваливаясь доползти до стадии он-лайн.
Но сделать этот документ удалось только потому, что менеджменту было просто пофиг, чем мы там вдвоём с этим мужиком занимаемся. Менеджмент в это время храбро тонул в потоке новостей от отдела тестирования, что дало нам окно для свободной работы.
Конечно, таблица тридцать на тридцать - это место, где можно закопаться всерьёз и надолго. Но тем и отличается аналитик от аналоха, что он сделает не это, а три размерностью десять на десять. Чтобы было понятно. И чтобы задача решалась просто. Но даже таблица на девять сотен не проставленных реакций на сигнал лучше, чем её отсутствие. Потому что бардак будет точно такой же, а вот увидеть его в полном объёме не удастся даже настоящим экспертам.
Но самое главное, самое ценное для результата и самое вредное для распространения STT в массах - выше упомянутое жестокосердие. Это безжалостная методика, не дающая поблажек.
Тут нельзя нарисовать или не нарисовать стрелочку так, чтоб никто этого не заметил. В ячейке таблицы стоит или IGNORE, или ERROR, или новое состояние, или жирный красный вопросительный знак. И ни умные рассуждения о перспективах развития энтерпрайза, ни рассказы о важности и не важности, ни упоминания послемитингового обеда не ответят на вопрос «Что должно тут быть и почему?»
В немецкой культуре люди привыкли, что у каждой проблемы есть ответ, и этот ответ им известен. Причём, известен на уровне экспертном. Если, вдруг, ответ не известен, то вопрос ерундовый и малозначащий. И они экспертно объяснят это.
Порой приходиться выслушивать совершенно бредовые рассуждалки на уровне детского сада. Причём, все как-бы знают, что это может быть не совсем правильно и не совсем так. Но, если высказывание сделано громким уверенным голосом, человеком обличённым экспертными полномочиями, то так оно и есть. И сомневаться просто не прилично. Примерно на том же уровне, как ковыряться в носу за обедом.
Обычно у меня статус эксперта и мне часто задают разные вопросы. Иногда дельные, иногда идиотские. Но это как-бы получение дополнительных и не относящихся к области компетенции знаний из правильного источника. Только один раз ко мне подошёл коллега не из русскоговорящих и сказал «Слушай, у меня есть один глупый вопрос.» Он был студентом. И французом.
А вот этот гадкий жирный вопросительный знак в клетке STT таблицы как заноза встаёт посреди корпоративной культуры, плюёт на все написанные в визитке «Доктор Компьютерных Наук» или «Самый Главный Аналитик» и заставляет выдавить из себя предательское «Не знаю.»
У всех производителей тулов, которые поддерживали SST я постоянно спрашивал, есть ли у них, вдруг, клиенты в Германии. Ответ был неизменно отрицательным.
Продолжение может быть будет когда-нибудь потом. Сейчас хочется вернуться к более весёлым темам
Copyright
(CC BY-NC-ND 3.0) vit_r, 2012
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
Перевод на английский запрещён, потому как нефиг портить хорошую вещь.