Неа. Трудоёмкость в коммерческих компаниях вообще никто не считает. Для технической документации у них действительно есть технические писатели. И отчёты в хороших коммерческих компаниях тоже не пишут. В них есть компетентные лидеры, которые без всякой ерунды могут отличить хорошего сотрудника от балбеса.
Трудоёмкость очень любит проверять госзаказчик. Государство ни хрена не умеет эффективно управлять ни разработкой, ни производством, но при этом очень любит всё измерять и взвешивать. Но их можно понять. А вот для начальника вешать эту работу на разрабов — непродуктивно.
Особенно бесят тупые работодатели, которые заставляют конструкторов считать трудоёмкость своей работы, писать какие-то планы, отчёты и т.п… Это просто выбешивает. Конструктор должен заниматься конструированием. Программист — программированием. Электронщик — электроникой. А планы с отчётами должны писать технические писатели. Максимум план разработки может писать руководитель разработки, а план работы сотрудников отдела — начальник отдела. Трудоёмкость может посчитать нормоконтроллёр. Поэтому мы и делаем барахло. Зато отчёт прикреплён…
А что поменяется в результате рефакторинга? Код отдельно взятой функции оптимизируется? Всякую мелочёвку не обязательно разрисовывать в виде блок-схем. Изменится объектная модель, появятся новые процессы, изменятся данные, которые обрабатываются процессами — да, это будет нужно отразить в документации. Но почему с нуля? Если у Вас программа представляет собой «портянку» из одной функции, которая разрисована в виде блок-схемы и описана текстом в виде последовательности операторов, тогда придётся переписывать с нуля. Если у Вас модульная программа, то нужно будет поправить описание одного модуля. Это — неизбежная плата за переносимость. Опять же, технические писатели на это есть.
К примеру, если у Вас есть функция… Эммм… Скажем, преобразования Фурье некоторого семпла данных. И Вы хотите провести рефакторинг. Вы можете описать эту функцию просто: данная подпрограмма выполняет быстрое прямое преобразование Фурье. Использует следующие переменные: указатель на структуру данных, число записей, период сигнала. Результатом преобразования является указатель на структуру данных, содержащую действительные и мнимые части образов Фурье гармоник входного сигнала. Блок схема функции не приводится ввиду её простоты. В тексте подпрограммы приведены соответствующие комментарии. После рефакторинга Вам ничего не нужно переписывать в этом описании.
На мой взгляд, идеальная ситуация, когда в команде программистов есть технический писатель, который подчиняется руководителю разработки. Этот технический писатель имеет познания в программировании, и сидит на каждом код-ревью. В части структуры всего документа он консультируется с руководителем разработки, в части описания модулей руководствуется тем, что услышал на код-ревью, а также консультируется с разработчиками. Оформление документа по какому-либо стандарту лежит полностью на нём. Таким образом, общая канва документа будет задаваться стратегами и тактиками разработки, при этом они будут освобождены от возни со стандартами оформления и набором текста, подбором формулировок и т.п. Я своё описание рисовал и писал сам. Времени ушло едва ли не больше, чем на написание кода (при условии, что ГОСТы мне близки). Сначала я психовал, но сейчас я уже больше года работаю в другом отделе, а мой код живёт и развивается другими разработчиками. Т.е. вроде бы затраты окупились, программа превратилась почти в продукт.
По-хорошему, ГОСТ требует описания основополагающих принципов программы. Концепцию и обобщённый алгоритм. Диаграмму классов/объектов (с полями, методами, взаимосвязями). Описание структур данных. Описание состава и назначения программных модулей и их API. Структуру программы (службы, процедуры, и данные, входящие в программу и взаимосвязи между ними). Блок-схемы алгоритмов сложных функций или процессов. А также текстовое описание всего этого дела. Если всё это сделать, то получится очень даже неплохо. Я в обычных проектах не видел такого, если честно. Там обычно не ясна концепция продукта. Т.к. хорошая программа — это некоторая объектная модель, которую можно визуализировать в виде диаграммы классов и объектной диаграммы. Вот эту объектную модель в визуальном виде я нигде пока не встречал (правда я открытые проекты почти не копал).
Ну, всё зависит от того, кто пишет документацию. Если пишется для того, чтобы отвязались, тогда документация получается такая, как Вы пишете. Если пишут на совесть, то получается хорошо сопровождаемый продукт.
У меня получилось норм, что-то из моего кода портировали на другие железки. Повозиться мне, конечно, пришлось, и я не верил в смысл всего этого дела, но теперь вижу, что смысл есть. Если делать хорошо. И не по требованиям ГОСТ… Кстати, в ГОСТ написаны обязательные разделы, но никто не мешает вводить свои разделы. И писать туда что угодно.
Ну, если подойти к делу творчески, то получается вполне неплохо. Я бы даже сказал, что это стоит потраченного времени. Но только после написания кода. Например, я свой код очень легко передал коллеге, т.к. у меня было вменяемое описание программы, её назначения, структуры, модулей и их API, и даже алгоритмы были разрисованы. Другое дело, что заниматься этим следует не программисту, а техническому писателю. Я сейчас для рисования блок-схем нанимаю фрилансеров. В принципе, ничего страшного ГОСТ на ИТ не требует — руководства программиста, руководство оператора, и прочее. Но для его использования ГОСТ нужно, по-сути, переписывать на ходу, подгоняя под современные реалии, т.к. многое писалось ещё с оглядкой на ЕС ЭВМ, не под GUI, там у них какие-то сообщения постоянно, команды и прочие консольные реалии. Для описания консольных утилит вполне подойдёт. Если у Вас GUI и ООП — тогда нужно творчески переосмысливать, придумывать на ходу. Это можно делать — ГОСТ устарел, значит он сам виноват.
По работе приходится использовать ГОСТы. Приходилось оформлять по ним и схемы, и текстовые документы — инструкции, эксплуатационные документы. Когда стал заниматься программированием, приходилось заниматься и оформлением программной документации по ЕСПД.
Общее впечатление от этого дела — нужная штука там, где необходима поддержка продукта. Т.е. если жизненный цикл продукта будет дольше, чем время работы специалиста на предприятии, то нужно оформлять документацию по какому-либо стандарту. Именно ГОСТ, наверное, не обязательно, но некоторый стандарт должен быть. Опять же, зависит от изделия. Если Вы делаете сложный продукт или продукт для массового производства — тогда необходимо. Если Вы делаете что-то для кустарного производства, то не обязательно строго следовать стандартам, достаточно заметок «на полях». Если программа или продукт — это что-то простое, тогда документация вообще не нужна — быстрее его реверснуть в уме или перепроектировать, нежели копаться в документации.
В целом, ГОСТы во много устарели. В частности, ЕСПД требует разработку алгоритмов до написания программы. Ф. Брукс осуждает такой подход (он, видимо, списан с ИСО-шных гостов), говорит, что блок-схемы вообще не нужны. ГОСТ не предусматривает диаграмм классов, и прочего. Только блок-схемы, имеющие смысл лишь для процедурной парадигмы. Если у Вас ООП, то приходится изобретать.
Плюсы применения ГОСТов появляются лишь тогда, когда продукт живёт долго. Старый разработчик ушёл, пришёл новый, ему дали папку с доками, он всё прочитал и врубился в продукт. Минус ГОСТов — время на разработоку документации по стандарту (и время на внедрение стандарта).
ГОСТы часто приходится применять и усовершенствовать с оглядкой на современные технологии. Запилить диаграмму классов в ГОСТовской рамке — вот Вам и новый программный документ. Хотя все диаграммы идут в составе инструкций программиста и описаний. Просто для них не предусмотрены обозначения. Придумываете сами (или заимствуете у иностранцев). ГОСТ это позволяет делать, если в самом ГОСТе нет обозначений.
В целом, ГОСТ вполне себе неплох. Современные САПР позволяют лепить КД в ГОСТе, прямо в процессе построения схем, эмуляции и построении трёхмерных моделей. С технологией производства это тоже сопрягут со временем, т.е. можно будет по модели листового тела получить и чертёж, программу для лазерного станка, и т.п.
По сути, КД и ПД — это продукт. И только владельцу предприятия решать, какой продукт должно производить его предприятие — отгружаемый заказчику или бумажный. И распределять усилия сотрудников.
Да, самое главное — на большинстве предприятий для оформления текстовых документов держат специальных технических писателей. Для оформления чертежей раньше были чертёжники, которые работали на инженеров. С развитием САПР стало считаться, что конструктор сам в состоянии справится с оформлением КД.
Не ясно, каков контекст статьи. Откуда Вы скачиваете установочный файл? С интернета? Куда устанавливаете? На компьютер? На экране логи чего у Вас изображены? Логи установки на Ваш компьютер этого софта?
Не ясно, что за устройство и каков контекст выполняемых действий. То ли эта плата с видеовыходом, и Вы на ней работаете. По какому интерфейсу Вы её шьёте? Что представляет собой лог её работы в Вашем случае? Строки в терминале? Статья явно написана в каком-то контексте, который читателю не сообщается, но ведь не факт, что читателю это известно.
Мне кажется, Линукс здесь совсем не к месту, как и «сборки» из командной строки. Юзабилити нулевое.
Хорошо хоть не пришлось сборку линукса делать с Байкаловским софтом :)
А под винду у них средства разработки есть? Можно как софт писать? Какова архитектура платы? Что на ней есть, какие интерфейсы, какие модули аппаратные стоят? ПЗУ какое у платы? Винчестер, флеш, или у микропроцессора (микроконтроллера?) своя флеш?
В общем, понятно, что это паровоз, не понятно, куда лошадей запрягать.
Трудоёмкость очень любит проверять госзаказчик. Государство ни хрена не умеет эффективно управлять ни разработкой, ни производством, но при этом очень любит всё измерять и взвешивать. Но их можно понять. А вот для начальника вешать эту работу на разрабов — непродуктивно.
К примеру, если у Вас есть функция… Эммм… Скажем, преобразования Фурье некоторого семпла данных. И Вы хотите провести рефакторинг. Вы можете описать эту функцию просто: данная подпрограмма выполняет быстрое прямое преобразование Фурье. Использует следующие переменные: указатель на структуру данных, число записей, период сигнала. Результатом преобразования является указатель на структуру данных, содержащую действительные и мнимые части образов Фурье гармоник входного сигнала. Блок схема функции не приводится ввиду её простоты. В тексте подпрограммы приведены соответствующие комментарии. После рефакторинга Вам ничего не нужно переписывать в этом описании.
У меня получилось норм, что-то из моего кода портировали на другие железки. Повозиться мне, конечно, пришлось, и я не верил в смысл всего этого дела, но теперь вижу, что смысл есть. Если делать хорошо. И не по требованиям ГОСТ… Кстати, в ГОСТ написаны обязательные разделы, но никто не мешает вводить свои разделы. И писать туда что угодно.
Общее впечатление от этого дела — нужная штука там, где необходима поддержка продукта. Т.е. если жизненный цикл продукта будет дольше, чем время работы специалиста на предприятии, то нужно оформлять документацию по какому-либо стандарту. Именно ГОСТ, наверное, не обязательно, но некоторый стандарт должен быть. Опять же, зависит от изделия. Если Вы делаете сложный продукт или продукт для массового производства — тогда необходимо. Если Вы делаете что-то для кустарного производства, то не обязательно строго следовать стандартам, достаточно заметок «на полях». Если программа или продукт — это что-то простое, тогда документация вообще не нужна — быстрее его реверснуть в уме или перепроектировать, нежели копаться в документации.
В целом, ГОСТы во много устарели. В частности, ЕСПД требует разработку алгоритмов до написания программы. Ф. Брукс осуждает такой подход (он, видимо, списан с ИСО-шных гостов), говорит, что блок-схемы вообще не нужны. ГОСТ не предусматривает диаграмм классов, и прочего. Только блок-схемы, имеющие смысл лишь для процедурной парадигмы. Если у Вас ООП, то приходится изобретать.
Плюсы применения ГОСТов появляются лишь тогда, когда продукт живёт долго. Старый разработчик ушёл, пришёл новый, ему дали папку с доками, он всё прочитал и врубился в продукт. Минус ГОСТов — время на разработоку документации по стандарту (и время на внедрение стандарта).
ГОСТы часто приходится применять и усовершенствовать с оглядкой на современные технологии. Запилить диаграмму классов в ГОСТовской рамке — вот Вам и новый программный документ. Хотя все диаграммы идут в составе инструкций программиста и описаний. Просто для них не предусмотрены обозначения. Придумываете сами (или заимствуете у иностранцев). ГОСТ это позволяет делать, если в самом ГОСТе нет обозначений.
В целом, ГОСТ вполне себе неплох. Современные САПР позволяют лепить КД в ГОСТе, прямо в процессе построения схем, эмуляции и построении трёхмерных моделей. С технологией производства это тоже сопрягут со временем, т.е. можно будет по модели листового тела получить и чертёж, программу для лазерного станка, и т.п.
По сути, КД и ПД — это продукт. И только владельцу предприятия решать, какой продукт должно производить его предприятие — отгружаемый заказчику или бумажный. И распределять усилия сотрудников.
Да, самое главное — на большинстве предприятий для оформления текстовых документов держат специальных технических писателей. Для оформления чертежей раньше были чертёжники, которые работали на инженеров. С развитием САПР стало считаться, что конструктор сам в состоянии справится с оформлением КД.
Проблема статьи, на мой взгляд, как раз в том, что нужно сначала собрать и залить дистрибутив на Raspberry, а потом читать эту статью.
Не ясно, что за устройство и каков контекст выполняемых действий. То ли эта плата с видеовыходом, и Вы на ней работаете. По какому интерфейсу Вы её шьёте? Что представляет собой лог её работы в Вашем случае? Строки в терминале? Статья явно написана в каком-то контексте, который читателю не сообщается, но ведь не факт, что читателю это известно.
Хорошо хоть не пришлось сборку линукса делать с Байкаловским софтом :)
А под винду у них средства разработки есть? Можно как софт писать? Какова архитектура платы? Что на ней есть, какие интерфейсы, какие модули аппаратные стоят? ПЗУ какое у платы? Винчестер, флеш, или у микропроцессора (микроконтроллера?) своя флеш?
В общем, понятно, что это паровоз, не понятно, куда лошадей запрягать.