Исходный код трудночитаемый, но предлагаемое решение выглядит еще хуже.
Я в таких случаях использую таблицы решений (decision tables). Это наглядный метод табличного описания алгоритмов, который описываются большим количеством логических операторов if и switch.
Я ними познакомился в 2000 году во время работы над проектом, который реализовывался по методологии Хэтли-Пирбхаи. С тех пор я регулярно использую их как для написания нового кода, так и для анализа существующего кода.
Это очень давно известная методика. Хорошее описание можно найти в книге издательства "Мир" 1976 года: Э.Хамби "Программирование таблиц решений".
По поводу объединения словарей: я давно использую собственную функцию для этих целей, а именно
def merge_dicts(d1, d2, merge_value_func=None):
d_result = d1.copy()
for key, value in d2.items():
if key in d1:
if merge_value_func is None:
d_result[key] = value
else:
d_result[key] = merge_value_func(d_result[key], value)
else:
d_result[key] = value
return d_result
Здесь имеется дополнительный параметр merge_value_func. Он позволяет скомбинировать в новом словаре значения для одних и тех же ключей в исходных словарях, например:
Вот еще пример эвфемизма (услышал более 20 лет назад от человека, работавшего в Великобритании): у них считалось неприличным говорить disabled в отношении людей. Нужно было говорить «not so body enabled».
Когда я в 1997 году начал работу в авиакомпании KLM, коллеги мне сказали: «Если ты в офисе видишь кого-то в костюме и при галстуке, то это консультант из компании Logica CMG». Все остальные, включая начальство, одевались просто. Эта компания тогда в IT-мире была тем, чем «Роллс-Ройс» является среди автомобилей.
Да, идея фикс «программирование без программистов» по-прежнему не дает покоя менеджерам.
Mendix сейчас активно продвигается здесь в Голландии (что не мудрено, поскольку он в Голландии и разработан) в крупных организациях — банки, министерства.
В одном голландском банке сделали консультанты проект на Mendix, внедрили и разъехались. После их ухода понадобилось что-то в приложении изменить. Попробовали банковские программисты сами это сделать, но не тут-то было, слишком сложно оказалось. Пришлось банку срочно нанимать специалистов по Mendix с оплатой 500 евро в час.
Эта идея, конечно не нова. Книга Джеймса Мартина «Applications Development Without Programmers» была издана еще в 1981 году.
Вспоминаются 90-е годы прошлого века, когда предшественники таких low-code платформ активно продвигались под лозунгами «Языки 4-го поколения», RAD (Rapid Application Development) и CASE (Computer-aided software engineering).
Например, есть такая штука как Uniface — тоже изначально голландская разработка и до сих пор используется во многих голландских компаниях и организациях. Uniface начали разрабатывать в конце 80-х годов.
Я работал в 2013 году в одной финансовой компании, в которой 25% всего программного обеспечения было сделано на Uniface.
Один коллега тогда перешел с Uniface на C#, хотя и сильно потерял при этом в зарплате. По его словам, Uniface с точки зрения программиста — совершенно бесперспективная вещь. Язык программирования так и застрял в своем развитии в начале 90-х.
В финансовой компании хотят это все перевести на Java или .NET, но денег нет. Так и приходится все это поддерживать. При этом Uniface-разработчики стоят дороже .NET-разработчиков.
Кстати, в этой же компании еще 25% программ были созданы при помощи еще одной подобной системы — Blueriq (раньше она называлась Aquima). Ее разработчики использовали «революционную» идею о том, что данные должны храниться не в базе данных, а в одном большом XML-файле. Теперь тоже хотят от всего этого избавиться и тоже денег на это нет.
Но история никого ничему не учит, и вот у нас уже повсюду активно продвигаются Mendix и Betty Blocks — последний писк моды (еще одна голландская разработка).
С языком REXX я познакомился в 1989 году в процессе работы в среде СВМ (Система Виртуальных Машин) на мейнфрейме ЕС <какой-то там номер> (фактически это была OS-360 или 370, конечно).
REXX был языком достаточно удобным и понятным, хотя и не всегда. Например, прочитать строку со стандартного входа, что на языке C выглядело бы так:
s = fgets(in);
на языке REXX выглядело вот так:
parse pull s
'execio 1 diskr in'
Но в целом для своего времени язык был очень хорошим (сейчас, конечно, он морально устарел и начисто проигрывает таким языкам, как Python). В СВМ еще был текстовый редактор XEDIT, в котором можно было писать макросы на языке REXX.
Кстати, существовал клон редактора XEDIT, который работал на персональных компьютерах в среде MS DOS. Он назывался KEDIT, и макросы для него можно было писать на диалекте языка REXX, который назывался KEXX. Я с ним начал работать году в 1990-м.
Дейкстра когда-то сказал (не ручаюсь за точность цитаты): «Использование антропоморфной терминологии по отношению к компьютерам является признаком профессиональной незрелости».
А вы правильно прочитали то что я написал? Безос говорит, что нельзя выбирать 2 из 3х и нужно работать и долго, и с умом, и напрягаясь.
По поводу корпоративных ценностей Amazon:
Bezos told shareholders that employees at other companies "can work long, hard, or smart, but at Amazon.com, you can't choose two out of three."
(взято отсюда: https://www.businessinsider.in/jeff-bezos-once-said-that-in-job-interviews-he-told-candidates-there-are-3-ways-to-work-and-at-amazon-you-have-to-do-all-3/articleshow/65343632.cms )
Если это действительно так, не очень хотелось бы там работать.
Исходный код трудночитаемый, но предлагаемое решение выглядит еще хуже.
Я в таких случаях использую таблицы решений (decision tables). Это наглядный метод табличного описания алгоритмов, который описываются большим количеством логических операторов if и switch.
Я ними познакомился в 2000 году во время работы над проектом, который реализовывался по методологии Хэтли-Пирбхаи. С тех пор я регулярно использую их как для написания нового кода, так и для анализа существующего кода.
Это очень давно известная методика. Хорошее описание можно найти в книге издательства "Мир" 1976 года: Э.Хамби "Программирование таблиц решений".
Методология Хэтли-Пирбхаи, одной из составных частей которых является использование таблиц решений, описана в книге Hatley & Pirbhai "Strategies for Real Time System Specification" https://www.amazon.co.uk/gp/product/0932633110 Есть более свежее издание: https://www.amazon.co.uk/gp/product/0932633412
Маленькое замечание: в русскоязычной литературе фамилию создателя языка Фортран принято писать "Бэкус", а не "Бакус".
По поводу объединения словарей: я давно использую собственную функцию для этих целей, а именно
Здесь имеется дополнительный параметр merge_value_func. Он позволяет скомбинировать в новом словаре значения для одних и тех же ключей в исходных словарях, например:
Результат:
Mendix сейчас активно продвигается здесь в Голландии (что не мудрено, поскольку он в Голландии и разработан) в крупных организациях — банки, министерства.
В одном голландском банке сделали консультанты проект на Mendix, внедрили и разъехались. После их ухода понадобилось что-то в приложении изменить. Попробовали банковские программисты сами это сделать, но не тут-то было, слишком сложно оказалось. Пришлось банку срочно нанимать специалистов по Mendix с оплатой 500 евро в час.
Эта идея, конечно не нова. Книга Джеймса Мартина «Applications Development Without Programmers» была издана еще в 1981 году.
Вспоминаются 90-е годы прошлого века, когда предшественники таких low-code платформ активно продвигались под лозунгами «Языки 4-го поколения», RAD (Rapid Application Development) и CASE (Computer-aided software engineering).
Например, есть такая штука как Uniface — тоже изначально голландская разработка и до сих пор используется во многих голландских компаниях и организациях. Uniface начали разрабатывать в конце 80-х годов.
Я работал в 2013 году в одной финансовой компании, в которой 25% всего программного обеспечения было сделано на Uniface.
Один коллега тогда перешел с Uniface на C#, хотя и сильно потерял при этом в зарплате. По его словам, Uniface с точки зрения программиста — совершенно бесперспективная вещь. Язык программирования так и застрял в своем развитии в начале 90-х.
В финансовой компании хотят это все перевести на Java или .NET, но денег нет. Так и приходится все это поддерживать. При этом Uniface-разработчики стоят дороже .NET-разработчиков.
Кстати, в этой же компании еще 25% программ были созданы при помощи еще одной подобной системы — Blueriq (раньше она называлась Aquima). Ее разработчики использовали «революционную» идею о том, что данные должны храниться не в базе данных, а в одном большом XML-файле. Теперь тоже хотят от всего этого избавиться и тоже денег на это нет.
Но история никого ничему не учит, и вот у нас уже повсюду активно продвигаются Mendix и Betty Blocks — последний писк моды (еще одна голландская разработка).
REXX был языком достаточно удобным и понятным, хотя и не всегда. Например, прочитать строку со стандартного входа, что на языке C выглядело бы так:
s = fgets(in);
на языке REXX выглядело вот так:
parse pull s
'execio 1 diskr in'
Но в целом для своего времени язык был очень хорошим (сейчас, конечно, он морально устарел и начисто проигрывает таким языкам, как Python). В СВМ еще был текстовый редактор XEDIT, в котором можно было писать макросы на языке REXX.
Кстати, существовал клон редактора XEDIT, который работал на персональных компьютерах в среде MS DOS. Он назывался KEDIT, и макросы для него можно было писать на диалекте языка REXX, который назывался KEXX. Я с ним начал работать году в 1990-м.
— Ты захочешь его убить.
(и это не шутка!)
Дейкстра когда-то сказал (не ручаюсь за точность цитаты): «Использование антропоморфной терминологии по отношению к компьютерам является признаком профессиональной незрелости».