Здравствуйте, lexer_lx, Вы писали:
_>в верху иерархии распределения работ/фондов оплаты труда стоит зам директора, инженер-электроник, уже несколько лет как на пенсии. _>.... _> это принципиальный для меня вопрос, попробовать просветлить этого человека, хотя бы чтобы тем, кто после меня останется, было легче.
Просветить человека в пенсионном возрасте против его воли, может, и можно, хотя очень трудно. Но только с чего Вы взяли, что он изменит поведение, будучи более просвещенным? В чем его мотив к смене подхода? Вы думаете, взяткодатели, скажем, непросвещенные и не знают, что коррупция — это плохо? Знают, но им надо проблему решить здесь и сейчас. Так и тут.
Выбери одну вещь, не спорь обо всём сразу
приходиш и говориш
1. "Пал Палыч, доверьте мне как лидеру группы сделать систему локализации на своё усмотрение"
2. Система которую я сделаю позволит легче локализировать нашу программу
3. Мне надо на работу х времени
4. Не используй слова "сложно", говри что ты хочеш сделать и какая от этого будет практическая полза
Здравствуйте, lexer_lx, Вы писали:
_>Вот конкретная работа: есть у нас несколько проектов, некоторые — крупные, написанные уже довольно давно (C++, MFC, wxWidgets, Qt). Все — с русскоязычным интерфейсом. Никакого юникода (то есть, нагромождение строковых типов — char*, CString и т.п.). Необходимо адаптировать исходники к локализации на другие языки. Кода много — в перспективе светит адова работенка. По мнению замдиректора — это "обезьянья работа", заключающаяся в тупой замене содержимого кавычек новым текстом. О разных типах, о универсальной подсистеме локализации (при добавлении нового языка — будем копировать проект и еще раз менять содержимое кавычек) он слышать не желает. Тычет свой фортран, на котором он текст в кавычках очень просто когда-то выводил и там нет ничего сложного. Это просто пример, аналогичная ситуация возникает постоянно. Никакие, повторяю, никакие доводы не работают, даже если мы ему покажем наши исходники — его логика элементарна (текст -> кавычки — замена всего что в кавычках -> если у нас не так, то мы дебилы).
Лично я, в такой ситуации, исхожу из предпосылки, что все правы. Тогда, в Вашем случае, выносим все строки в один header локализации, в коде остаются константы, при сборке подсовываем нужный header локализации. Так и переводчику работать легче будет, и быстродействие не пострадает, вполне здоровый подход для систем реального времени (намек ведь на них?). И, что немаловажно, все довольны.
_>Так сложилось исторически, что высшее руководство предприятия — выходцы из старых времен (инженеры, электроники). То есть, о современном программировании понятия не имеют практически никакого.
когда доростёшь до их возраста и должностей поймёшь что сильно ошибался в оценках
_>Вследствие истории происхождения предприятия, схем отмывания денег, получения договоров и т.п., качество производимой продукции стоит не в приоритете
это значит что им твоё "просвящение" в куй не упёрлось. Будешь мешать им делать их дело своими хотелками — выгонят. Это же их дело а не твоё. Такчт занимайся самообразованием и вали туда где больше понравится.
_>Что можно придумать? Как убедительно убедить в том, что программирование — это сложно, что качественный подход — необходим, что программа сейчас — это не просто последовательность строк на фортране? Личные доводы не работают, или же я еще не придумал правильные доводы. Возможно, есть какие-то авторитетные статьи такого плана? Литература?
— программирование это не сложней проектирования трубопроводов
— качественный подход в данном случае не нужен
— программа это просто последовательность строк
— чтобы личные доводы заработали нужно сделать что-то полезное для других а не для своего самообразования
_И первая же проблема — как убедить его в том, что процесс программирования в настоящее время некоторым образом отличается от процесса, который был 30 лет назад и заключался в кодировании прямоугольников-ромбиков-переходов?
Если это не просто эмоции, то, пожалуйста, убедите в этом меня.
Здравствуйте, Victor Ivanidze, Вы писали:
VI>_И первая же проблема — как убедить его в том, что процесс программирования в настоящее время некоторым образом отличается от процесса, который был 30 лет назад и заключался в кодировании прямоугольников-ромбиков-переходов?
VI>Если это не просто эмоции, то, пожалуйста, убедите в этом меня.
Имеем: куча проектов на mfc, wxWidgets, Qt, WinApi. Для текста используются char*, CString, QString, wxString — как попало и где попало.
Просто замена текста в кавычках не годится — нужна кодировка, отличная от однобайтной.
Но допустим, что мы нашли способ просто менять текст в кавычках и таким образом получать проект, локализованный на требуемый язык. Процесс перевода будет проходить в несколько этапов — получаем первый вариант, подставляем в кавычки, отдаем заказчику, он смотрит что все выглядит как надо (естественно будет куча замечаний и править текст в кавычках придется много раз). В дальнейшем появятся другие языки. Придется снова править все тексты (вносить в них ошибки, естественно, мы же не роботы).
Можно реализовать подсистему локализации, продумать гибкий интерфейс, использовать ее в других проектах, существующих и будущих. Модификация исходных кодов программ будет сделана один раз, и последующие добавления новых языков коды программ не затронут.
В первом случае мы "меняем текст в кавычках", "обезьянья работа", как выражается босс. В нашем случае — универсальный многофункциональный модуль, который может сэкономить много часов нашей работы.
Пример с переводами — просто пример. Можно придумать способ, например, держать тексты в файлах в unicode, загружать их и перекодировать в однобайтную кодировку в соответствии с нужным языком, и не править существующий код. Это не столь важно.
Возможно, я не совсем точно выразился, когда говорил о ромбиках — но суть такая, что нас пытаются заставить решать любую задачу "в лоб", не смотря вперед ни на шаг. По мере возможности мы пытаемся делать "хорошо" — но не всегда успеваем, иногда узкие временные рамки заставляют делать "в лоб". Но потом с нас же и спрашивают — почему все так плохо, почему не успеваем, куда уперлись, ведь сделали же ранее, почему теперь надо переделывать, ведь ромбики же, переходы, какая разница, там программа, тут программа...
Здравствуйте, lexer_lx, Вы писали:
_>Здравствуйте, Victor Ivanidze, Вы писали:
VI>>_И первая же проблема — как убедить его в том, что процесс программирования в настоящее время некоторым образом отличается от процесса, который был 30 лет назад и заключался в кодировании прямоугольников-ромбиков-переходов?
VI>>Если это не просто эмоции, то, пожалуйста, убедите в этом меня.
_>В первом случае мы "меняем текст в кавычках", "обезьянья работа", как выражается босс. В нашем случае — универсальный многофункциональный модуль, который может сэкономить много часов нашей работы.
этот "универсальный многофункциональный модуль" криво написанный студентом добавит сотни проблем из-за твоей неопытности (первый блин комом обычно). Потом, когда ты сбежишь в москву и на твоё место возьмут такого же студента за гроши, ему будет трудно всё твоё добро переписывать заново.
А обезьянью работу сможет выполнить любой низкоквалифицированный работник. Время твоё стоит дёшево, посидишь лишний десяток часов и сделаешь.
Твоё начальство это понимает, ты поймёшь через пяток лет тоже.
PS
в описании проблем не увидел никаких отличий от того что было 10, 20, 30 лет назад. Да и в непрограммировании примерно так же — дешёвый труд снижает потребность в автоматизации, это закон.
Здравствуйте, lexer_lx, Вы писали:
_>Здравствуйте, Victor Ivanidze, Вы писали:
VI>>_И первая же проблема — как убедить его в том, что процесс программирования в настоящее время некоторым образом отличается от процесса, который был 30 лет назад и заключался в кодировании прямоугольников-ромбиков-переходов?
VI>>Если это не просто эмоции, то, пожалуйста, убедите в этом меня.
....
Не убедили. Всё вами описанное есть ваша внутрифирменная специфика (или политика), которая не имеет никакого отношения к вашему громкому утверждению про процесс программирования. Если бы у вас был разрешён только Fortran в качестве языка разработки и текстовый редактор MultiEdit как среда разработки, проблемы были бы такие же.
Здравствуйте, Victor Ivanidze, Вы писали:
>Не убедили. Всё вами описанное есть ваша внутрифирменная специфика (или политика), которая не имеет никакого отношения к вашему громкому утверждению про процесс программирования.
Ну вот, уже двоих нужно убеждать =)
Еще раз повторяю, что я не совсем точно выразился о процессе программирования. Суть состоит в том, чтобы искать более качественные подходы к процессу разработки ПО. Вместо 10к строк кода написать 6к, которые будут понятнее и гораздо проще поддерживаемые при наличии должной документации. Но с немного большими затратами на реализацию. Както так. По сути — да, это все тот же набор геометрических фигур.
А что касается 30-летнего прошлого, то я очень сомневаюсь в том, использование концепций ООП, паттернов проектирования в том или ином видах и прочих прелестей современного процесса разработки ПО было в то время повсеместным.
>Если бы у вас был разрешён только Fortran в качестве языка разработки и текстовый редактор MultiEdit как среда разработки, проблемы были бы такие же.
Да, потому как исходная предпосылка — максимальный уровень экономии. И эта экономия нашла свой выход в непрофильном для предприятия направлении. Потому необходимо обосновать, к чему может привести дальнейший отказ от более качественного подхода к написанию ПО, чтобы экономия свернула на другую ветку.
Здравствуйте, lexer_lx, Вы писали:
_>Что можно придумать? Как убедительно убедить в том, что программирование — это сложно, что качественный подход — необходим, что программа сейчас — это не просто последовательность строк на фортране? Личные доводы не работают, или же я еще не придумал правильные доводы. Возможно, есть какие-то авторитетные статьи такого плана? Литература?
От правильного выбора слов на 100% зависит произведённый эффект.
Надо поставить себя на место этого руководителя. Представь: тебе надо выполнять задачу, а к тебе приходит вьюноша с горящими глазами и начинает грузить тебя неведомой фигнёй да ещё с намёком, что твои знания устарели. Тебе бы это понравилось? Вот и ему нет.
Ему что надо — чтобы задача была решена качественно и в срок. И ему абсолютно не интересно вникать в детали реализации. Не надо ему говорить о супер-пупер системе локализации. Скажи: придумал простое и дешевое решение, которое позволит избавится от проблемы локализации навсегда. Это для руководителя как бальзам на душу. Только это должно быть действительно простое и дешевое решение, а не какой-нибудь универсальный всемогутор. И желательно с цифрами. Например: сейчас процесс локализации занимает 1 месяц и правка багов на 3 месяца, потом будет занимать 1 неделю и править баги не надо. А на реализацию самого решения надо 3 дня. Вот это будет конструктивный разговор.
Здравствуйте, Dufrenite,
D>Например: сейчас процесс локализации занимает 1 месяц и правка багов на 3 месяца, потом будет занимать 1 неделю и править баги не надо. А на реализацию самого решения надо 3 дня.
А если — "на реализацию самого решения надо 3 месяца"? А если при обещанных 3 месяцах реальный срок разработки и правки багов в этом самом "простом и дешевом решении" будет уже месяцев этак 10?
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, Dufrenite,
D>>Например: сейчас процесс локализации занимает 1 месяц и правка багов на 3 месяца, потом будет занимать 1 неделю и править баги не надо. А на реализацию самого решения надо 3 дня.
V_S>А если — "на реализацию самого решения надо 3 месяца"?
Я вас умоляю. Загрузить и распарсить xml-файл за 3 месяца?
V_S>А если при обещанных 3 месяцах реальный срок разработки и правки багов в этом самом "простом и дешевом решении" будет уже месяцев этак 10?
В этом случае разработчик, как настоящий самурай, обязан совершить харакири.
V_S>>Здравствуйте, Dufrenite,
V_S>>А если при обещанных 3 месяцах реальный срок разработки и правки багов в этом самом "простом и дешевом решении" будет уже месяцев этак 10?
D>В этом случае разработчик, как настоящий самурай, обязан совершить харакири.
У нас возможны более действенные меры — отправят реализовывать непосредственно на объект, а там радиационный фон, быстренько все за пару дней сделаем и без багов =)
Здравствуйте, lexer_lx, Вы писали:
_>У нас возможны более действенные меры — отправят реализовывать непосредственно на объект, а там радиационный фон, быстренько все за пару дней сделаем и без багов =)
