Самое обидное — когда постоянно находишь фатальные ошибки в архитектуре, а тебя же считают дятловидным споруном. Хотя ошибки действительно фатальные, и после их обсуждения архитектуру меняют. За что, интересно? Ну да, нервничал, ну ведь не слушали сначала. А потом оказалось, что был прав. И так несколько раз. А теперь проект давно сдали, а осадочек остался…
ИМХО, не имеет. Но никто Вам не мешает попробовать. Просто если чтение не пойдёт — не отчаивайтесь, эта книга не всем подходит. У профессиональных математиков свой образ мышления, с отзвуками аксиоматических теорий, проходящих проверку логическим анализом и вот этим всем. Поэтому в книге будет много лишнего и неочевидного, представляющего эстетическую ценность для математика и неудобство для кодера-практика. Лучше какой-нибудь справочник по алгоритмам годный почитать, где будут те же алгоритмы, но без теоретической воды.
Само определение качества как «соответствие ожиданиям потребителя» ошибочно. Ну, вообще-то если добавить мясо в колбасу, хмель в пиво и т.д., то согласно Вашему определению качество продукта упадет…
Потому что покупатель ожидает, что продукт будет ДЕШЕВЫМ. И да, он придёт в магазин, посмотрит состав сырокопченых колбас, увидит в них свиные шкуры и кур. Потом он посмотрит состав Вашей колбасы, потом посмотрит на цену Вашей колбасы, вздохнёт и купит докторскую.
Если говорить про функции ОТК (мне больше нравится ОТК, т.к. после введения на моем предприятии СЛк качество стало падать, упираясь лишь в требовательного директора по качеству, бывшего начальника ОТК, которого потом уволили, т.к. в конфликте между директором производства и директором СЛк руководство заняло позицию директора производства), то оно заключается в:
— Контроль соответствия продукции требованиям государственных стандартов и отраслевых требований;
— Контроль соответствия продукции конструкторской и другой внутренней документации, например, технических условий;
Т.е. «требования потребителя» здесь вообще мимо. Требования потребителя обеспечивает, в зависимости от рода деятельности, отдел, ПРОЕКТИРУЮЩИЙ продукт. Т.е. те, кто составляет рецептуру и технологию изготовления колбасы. ОТК при этом следит лишь за тем, чтобы по техпроцессу свиные шкуры не хранились дольше прописанного в СанПИНах каких-нибудь.
Проблема соответствия требованиям потребителя — это проблема отдела маркетинга, если он есть. Если его нет — проблема руководства, директора, да кого угодно, кто хочет не просто просидеть рабочий день, получить зарплату и уйти, а того, кто хочет ПРОДАТЬ продукт. И они эту проблему решают — варят пиво из хмелепродуктов и пихают свиные шкуры в колбасу. Потому что иначе продукция будет меньше соответствовать требованиям потребителя. Который хочет, чтобы продукция была дешевой.
Спасибо Вам за попытку разобраться в такой щекотливой теме, как качество, но вообще говоря, по моему опыту, 90% проблем качества связаны с нарушением технологии. А нарушения связаны с тем, что люди не могут делать правильно, им не объяснили, не показали. Им дали бумажку с абстрактными обязанностями типа «Знать и выполнять требования государственных и отраслевых стандартов». Но человек с бумажки плохо работает. Покажи ему руками, что совать и куда жать. И будет качественнее. А для этого на производстве должны быть люди, которые по «Требованиям стандартов» могут понять, какие должны быть действия рабочих…
Чтобы на производстве был порядок, каждый должен заниматься своим делом. Качество — это, по большому счёту, соответствие технологическому процессу. Потому что техпроцесс не может нарушать нормативные документы, конструкция заложена конструктором в соответствии с указаниями маркетологов. Если на предприятии маркетинг, конструктора и технологи — фуфло, то никакая служба качества Вам не поможет. Задача СЛк — «игра в любопытного заказчика», который заглянет, как выполняется техпроцесс, испытает контрольные образцы продукции. И если на предприятии главное — не потребитель, а план, то задача СЛк — не выделяться, чтобы не уволили.
ИМХО.
Вы знаете, мне очень неловко, но я наступил на свои любимые грабли — высказался о термине, значения которого не знал. Скорее это была экстраполяция дурных переводов, которые я видел, но ведь Кнута переводили при СССР, а там переводили качественно. Я посмотрел, что означает термин, и действительно «Литературное программирование» подходит лучше всего… Ещё можно это назвать «Образовательное программирование» или «Объясняющее программирование», но никак не грамотное… Более того, это именно то, что я обычно делаю в своем коде. Недавно даже мысль была, мол, жаль в комменты в коде нельзя вставлять картинки и даже анимацию, для пояснений… Народ даже ругается, говорят, много комментариев. Вот такой вот анекдот у меня вышел… Я был неправ.
ИМХО, «литературное программирование» — это оксюморон. Вроде «живого трупа». А программисты и Кнута-то не читали, в подавляющем большинстве. Когда-то давно среди переводчиков закрепился перевод «библиотеки динамической связи». И ничего, перезакрепили.
Главный недостаток его книг — занудство и высокий порог входа. Я вот кодингом увлекался с детства, и мне посоветовали Кнута почитать… Ну что сказать, мутота. Книга для людей с математическим образованием. Отдельные лучи поноса за предложение доказать великую теорему Ферма. Я, блин, ее несколько недель доказывал, задание же, потом бросил на хрен эту книгу. Откуда было знать студенту первого курса, да еще и не математику и не программисту, что ее нереально обычному человеку доказать. Зачем нужно вводить какую-то машину, на которой будут выполняться все примеры в книге? Реальных машин мало? Вся эта попытка построить строгую теорию программирования мало кому нужна, т.к. программеры в первую очередь практики, а не теоретики. Да, возможно, сейчас, имея образование и опыт (в первую очередь жизненный опыт пропускать мимо ушей всякую чепуху), я бы осилил этот труд.
К примеру, «Алгоритмы. Построение и анализ» Кормена мне гораздо лучше подошли. Или Седжвик с его «Фундаментальными алгоритмами на C++». Недаром именно эти две книги считаются стандартом при обучении программированию.
Заминусуют — ну и плевать.
Да, это так. В Питоне лично мне понравилось то, что в нем не нужно объявлять переменные, а также поля классов. Этим он мне и напомнил Бейсик. А «очарование» здесь в том, что это снижает бюрократическую составляющую при написании кода. В этом есть определенное удовольствие, просто садиться и «фристайлить». Необходимость объявлять переменные это удовольствие резко снижает. ИМХО.
Строгость типизации — это да, это тоже немного мешает, т.к. усложняет текст программы явными преобразованиями.
Это не значит, что я говорю, что Python лучше чем Си. Скорее, мне кажется наоборот. Как перфекционист я бы вообще кодил на Асме, но увы, это коммерчески нежизнеспособная идея. А в Python как и в Бейсике есть своё очарование. Я знал классных кодеров, которые начинали с Бейсика. Именно потому, что неявная типизация позволяет сосредоточиться на задаче, а не на бюрократии… Это как кафе открыть — одно дело классно готовить и людей кормить, а другое — соблюдать положенный документооборот. Немного разные задачи. Хотя конечным итогом должно стать именно классное обслуживание клиента.
Респект Вашему труду, но не ясна концепция языка. Вот в Python всё ясно — это современный крутой аналог бейсика, типизации нет, переменные объявлять не надо, даже поля классов объявлять не обязательно, пиши функционал, никакого занудства. В Си тоже ясно — строгая типизация, переменные объявлять обязательно, ну Вы понимаете. У Вас получилось нечто среднее, причём не ясно, а в чем изюминка? Т.е. для Вас это крутой учебный проект? Тогда ок… На первый взгляд, он ничего не даёт. Никакой крутой концепции, кроме того, что Вы написали свой язык, а я не написал.
И да, у Вас ведь нет компилятора под некоторую ОС? Ни байт-кода… Т.е. есть синтаксический анализатор, который разбирает строку на команды и тут же исполняет инструкции? Ну мне почти всё ясно тогда, кроме того, как Вы реализовали динамическое построение классов в трансляторе. На чём транслятор написан?
Т.е. на мой взгляд самое ценное здесь — реализация транслятора, но эта тема в статье не раскрыта. А так — Вашему уровню респект, конечно…
Небольшая инсайдерская информация… На моем предприятии используют Компас3D, но конструктора не очень-то его жалуют. Почему — не знаю, лично я программист. Начинал своё знакомство с машиностроительными САПР именно с Компас3D, за что огромное Вам спасибо, очень годная «Азбука». Основная претензия лично у меня — необходимость при редактировании моделей переводить взгляд на панель редактирования, которая внизу появляется. Это ломает весь творческий кайф, вот честно. Немного меньше напрягает медленность работы, особенно с большим количеством объектов. В целом, я задал конструкторам вопрос, что «нормальное» можно освоить из машиностроительных САПР, т.к. Компас неудобный, мне пожали руку и сказали: «SolidWorks или Inventor, ну или вообще любой зарубежный САПР, который сейчас в тренде». Вот так. Без обид, я надеюсь. Если человек покупает продукт, он хочет получить максимально удобную среду. У Компаса с этим есть проблемы, хотя программа всё равно крутая. И даже на предприятии среди директоров появился человек, который планирует соскочить с Вашей продукции (а у нас она используется довольно интенсивно). Если хотите, могу у конструкторов спросить, что именно им в Компас не нравится, может быть будет полезно…
ИМХО, если хотите, САПР нужна для того, чтобы разгрузить абстрактное мышление разработчика, чтобы он видел то, что получит. Вот когда редактируешь параметры на панели редактирования, то в это время не видишь, что получишь, и приходится напрягать воображение (ну или взгляд переводить, что тоже нагружает). Мышью двигать, опять же. Это напряг, причем лишний, и без него можно обойтись. И он реально портит удовольствие от процесса проектирования, а для разработчика удовольствие очень много значит.
Вообще говоря, KPI — штука обоюдоострая. Можно руки порезать.
Какие ключевые показатели эффективности у художников? Количество полотен в единицу времени? Видимо, шедевральность. А шедевральность часто становится видна спустя долгое время. Поэтому лично мне недавно пришла в голову идея платить разработчикам дивиденды. Т.е. есть стоимость продукта, в него заложено столько-то процентов от каждого разработчика. Пока модуль не переписан, с каждой продажи разраб получает бонус, даже после увольнения. Как только модуль переписали, бонус получает другой разраб. Разумеется, замена модуля должна быть обусловлена технической необходимостью. Если модуль доработали, то бонус делится между разработчиком и доработчиком. Я не обдумывал, да и не мое дело над таким думать, но кажется, что тогда разрабу будет выгодно писать код, который будет работать десятилетиями, учитывать все возможные пожелания, которые могут возникнуть в будущем. Да и вообще сопровождать проект, даже после увольнения. Да, это дополнительные расходы. Может статься, что качество продукта оправдает эти расходы.
Мягко говоря не понятно, если KPI вычисляется по формуле, то зачем разработчику знать свои показатели KPI? Ему больше заняться нечем? Разве только чтобы он сказал Вам, что показатели эти — туфта. Навскидку, реальные показатели эффективности у программиста — наукоемкость решаемой задачи, трудоемкость решаемой задачи, качество решения (низкие требования к ресурсам, переносимость, сопровождаемость, малое число ошибок), время выполнения работы. Как оценить эти параметры? Только во время Code Review, т.е. методом экспертной оценки. А для этого нужно быть экспертом в области, либо нужно программиста-консультанта привлекать, а лучше — всю команду для оценки вклада каждого сотрудника в общее дело. Какой вес у каждого показателя — зависит от отрасли и от типа задачи.
Лично у меня получается так: мне ставят задачу, я говорю: Ок. Специалисты других отделов говорят, что задачу решить в указанное время у меня не получится. Я задачу в указанное время решаю. Так что моих показателей KPI в работе реально — два. Первый — уровень страха перед задачей у одних людей (как косвенная оценка наукоемкости и трудоемкости), второй — все работает в указанный срок (как комплексная оценка малого количества ошибок и сроков). На бумаге у меня показателей больше, я их не знаю, если честно. У меня все работает, начальство довольно. По результатам меня премируют, я доволен.
Сначала обыграйте в виде худлит-истории, а потом можно и список. Иначе контекст будет не понятен, зачем эти книги нужны.
З.Ы. Рассказики годные. Нет, ЧСВ программера так и прёт изо всех щелей, но вообще занятно и познавательно.
Наверное вы правы… И осадочка бы не было… Спасибо, применю при случае :))
Потому что покупатель ожидает, что продукт будет ДЕШЕВЫМ. И да, он придёт в магазин, посмотрит состав сырокопченых колбас, увидит в них свиные шкуры и кур. Потом он посмотрит состав Вашей колбасы, потом посмотрит на цену Вашей колбасы, вздохнёт и купит докторскую.
Если говорить про функции ОТК (мне больше нравится ОТК, т.к. после введения на моем предприятии СЛк качество стало падать, упираясь лишь в требовательного директора по качеству, бывшего начальника ОТК, которого потом уволили, т.к. в конфликте между директором производства и директором СЛк руководство заняло позицию директора производства), то оно заключается в:
— Контроль соответствия продукции требованиям государственных стандартов и отраслевых требований;
— Контроль соответствия продукции конструкторской и другой внутренней документации, например, технических условий;
Т.е. «требования потребителя» здесь вообще мимо. Требования потребителя обеспечивает, в зависимости от рода деятельности, отдел, ПРОЕКТИРУЮЩИЙ продукт. Т.е. те, кто составляет рецептуру и технологию изготовления колбасы. ОТК при этом следит лишь за тем, чтобы по техпроцессу свиные шкуры не хранились дольше прописанного в СанПИНах каких-нибудь.
Проблема соответствия требованиям потребителя — это проблема отдела маркетинга, если он есть. Если его нет — проблема руководства, директора, да кого угодно, кто хочет не просто просидеть рабочий день, получить зарплату и уйти, а того, кто хочет ПРОДАТЬ продукт. И они эту проблему решают — варят пиво из хмелепродуктов и пихают свиные шкуры в колбасу. Потому что иначе продукция будет меньше соответствовать требованиям потребителя. Который хочет, чтобы продукция была дешевой.
Спасибо Вам за попытку разобраться в такой щекотливой теме, как качество, но вообще говоря, по моему опыту, 90% проблем качества связаны с нарушением технологии. А нарушения связаны с тем, что люди не могут делать правильно, им не объяснили, не показали. Им дали бумажку с абстрактными обязанностями типа «Знать и выполнять требования государственных и отраслевых стандартов». Но человек с бумажки плохо работает. Покажи ему руками, что совать и куда жать. И будет качественнее. А для этого на производстве должны быть люди, которые по «Требованиям стандартов» могут понять, какие должны быть действия рабочих…
Чтобы на производстве был порядок, каждый должен заниматься своим делом. Качество — это, по большому счёту, соответствие технологическому процессу. Потому что техпроцесс не может нарушать нормативные документы, конструкция заложена конструктором в соответствии с указаниями маркетологов. Если на предприятии маркетинг, конструктора и технологи — фуфло, то никакая служба качества Вам не поможет. Задача СЛк — «игра в любопытного заказчика», который заглянет, как выполняется техпроцесс, испытает контрольные образцы продукции. И если на предприятии главное — не потребитель, а план, то задача СЛк — не выделяться, чтобы не уволили.
ИМХО.
К примеру, «Алгоритмы. Построение и анализ» Кормена мне гораздо лучше подошли. Или Седжвик с его «Фундаментальными алгоритмами на C++». Недаром именно эти две книги считаются стандартом при обучении программированию.
Заминусуют — ну и плевать.
Строгость типизации — это да, это тоже немного мешает, т.к. усложняет текст программы явными преобразованиями.
Это не значит, что я говорю, что Python лучше чем Си. Скорее, мне кажется наоборот. Как перфекционист я бы вообще кодил на Асме, но увы, это коммерчески нежизнеспособная идея. А в Python как и в Бейсике есть своё очарование. Я знал классных кодеров, которые начинали с Бейсика. Именно потому, что неявная типизация позволяет сосредоточиться на задаче, а не на бюрократии… Это как кафе открыть — одно дело классно готовить и людей кормить, а другое — соблюдать положенный документооборот. Немного разные задачи. Хотя конечным итогом должно стать именно классное обслуживание клиента.
В этом есть своё очарование. Иногда это очень удобно. Возможно, мне так кажется лишь потому, что Бейсик был одним из первых языков, который я освоил.
И да, у Вас ведь нет компилятора под некоторую ОС? Ни байт-кода… Т.е. есть синтаксический анализатор, который разбирает строку на команды и тут же исполняет инструкции? Ну мне почти всё ясно тогда, кроме того, как Вы реализовали динамическое построение классов в трансляторе. На чём транслятор написан?
Т.е. на мой взгляд самое ценное здесь — реализация транслятора, но эта тема в статье не раскрыта. А так — Вашему уровню респект, конечно…
ИМХО, если хотите, САПР нужна для того, чтобы разгрузить абстрактное мышление разработчика, чтобы он видел то, что получит. Вот когда редактируешь параметры на панели редактирования, то в это время не видишь, что получишь, и приходится напрягать воображение (ну или взгляд переводить, что тоже нагружает). Мышью двигать, опять же. Это напряг, причем лишний, и без него можно обойтись. И он реально портит удовольствие от процесса проектирования, а для разработчика удовольствие очень много значит.
Какие ключевые показатели эффективности у художников? Количество полотен в единицу времени? Видимо, шедевральность. А шедевральность часто становится видна спустя долгое время. Поэтому лично мне недавно пришла в голову идея платить разработчикам дивиденды. Т.е. есть стоимость продукта, в него заложено столько-то процентов от каждого разработчика. Пока модуль не переписан, с каждой продажи разраб получает бонус, даже после увольнения. Как только модуль переписали, бонус получает другой разраб. Разумеется, замена модуля должна быть обусловлена технической необходимостью. Если модуль доработали, то бонус делится между разработчиком и доработчиком. Я не обдумывал, да и не мое дело над таким думать, но кажется, что тогда разрабу будет выгодно писать код, который будет работать десятилетиями, учитывать все возможные пожелания, которые могут возникнуть в будущем. Да и вообще сопровождать проект, даже после увольнения. Да, это дополнительные расходы. Может статься, что качество продукта оправдает эти расходы.
Лично у меня получается так: мне ставят задачу, я говорю: Ок. Специалисты других отделов говорят, что задачу решить в указанное время у меня не получится. Я задачу в указанное время решаю. Так что моих показателей KPI в работе реально — два. Первый — уровень страха перед задачей у одних людей (как косвенная оценка наукоемкости и трудоемкости), второй — все работает в указанный срок (как комплексная оценка малого количества ошибок и сроков). На бумаге у меня показателей больше, я их не знаю, если честно. У меня все работает, начальство довольно. По результатам меня премируют, я доволен.
З.Ы. Рассказики годные. Нет, ЧСВ программера так и прёт изо всех щелей, но вообще занятно и познавательно.