caxapa.ru :: Трудозатраты на оформление, документирование и структурирование кода не должны значительно превосходить трудозатраты на написание кода. При очень сильном документировании начнут разбегаться программеры.

st232bd (03.11.2008 17:28, просмотров: 97) ответил Shura на Раз с документированием пока не сложилось, давайте обсудим более простой вопрос - какие требования должны предъявляться к оформлению и структурированию кода?

Трудозатраты на оформление, документирование и структурирование кода не должны значительно превосходить трудозатраты на написание кода. При очень сильном документировании начнут разбегаться программеры.

Ответить

- Будем считать трудозатраты на собственно написание кода ничтожно малыми. - Shura(03.11.2008 17:28)
  - Я требовал техописание алгоритмики (матобеспечения, в том числе и всей эвристики с анализом реашемой задачи известными средстами) - хотя не все программеры самостоятельно могли это сделать. Пытались UML-диаграммы рисовать, но... POV(455 знак., 03.11.2008 19:08)
    - Блин, промахнулся с темой, тут же не про документирование :) - POV(03.11.2008 19:10)
  - А зачем тогда это чудо документировать? По нашему опыту, более менее полезными оказались общие описания на алгоритм работы прибора с времянками и формылами. А код - может через год ты семейство контроллеров сменишь. - st232bd(03.11.2008 17:33)
    - Затем чтоб знать как оно работает :-) - Shura(03.11.2008 17:32)
      - Мы пытались документировать, но не дошли до победного. - st232bd(03.11.2008 17:35)
        
        Проехали пока документирование, см. вопрос - Shura(03.11.2008 17:36)
        
        Я на АСМ придерживаюсь примерно таких структурных подходов/понятий --> - MBedder(03.11.2008 17:41, ссылка, ссылка)
        
        Похвально. Интересно другое. До какой длины программы есть вероятность постороннему программеру полностью разобраться? Кто может похвастаться, что прочитал чужую программу на 5000 строк асма, вставил свой кусок и рабочий цикл не слетел? - st232bd(03.11.2008 17:50)
        
        Я могу только обратным хвастаться - обычно в моих проектах несколько десятков тысяч АСМ-строк, и у меня никогда не возникало проблем с добавлением/изменением кода даже через много лет после завершения проекта. То есть пишу для себя лучше, MBedder(24 знак., 03.11.2008 18:27)
        
        Будем объективны. 10 тысяч строк на ассемблере - это не программа, а лажа. AlexandrY(274 знак., 03.11.2008 22:28, ссылка)
        
        Лажа - это твоя колхозная писанина, за которую я бы тебя немедленно уволил без выходного пособия, невзирая на "сверхутоптанность". Использование абсолютных equ для определения переменных, идиотские имена, никакие комментарии, MBedder(124 знак., 03.11.2008 23:39)
        
        Хорошо, покажу разработку на твоем любом AVR, чтоб уж в полный ступор. AlexandrY(185 знак., 04.11.2008 00:51, картинка)
        
        Не надо тока меня за идиота держать. Это дизассемблированный (= драный) код, в котором для понимания процесса некоторые переменные/метки просто были названы осмысленными именами. Мало того, исходник, похоже, был писан на IAR С - MBedder(03.11.2008 23:53)
        
        Ну как знаешь, я просто хотел показать как реально работают и чего стоят 10 тыс. строк ассемблера - AlexandrY(04.11.2008 00:54)
        
        Как кто работает - дизассемблеры? Так это я и без твоих 10 тыс. строк знаю. Кроме того, я еще знаю, как из твоих 10 тыс. строк сделать гораздо меньше :)) - MBedder(04.11.2008 00:58)
        
        Это зависит от "оптимизированности". Я вам могу простую программу написать в виде case в одну строку, за год не разберётесь. - General(03.11.2008 22:30)
        
        Так прогу то кодеры для себя пишут, а не для саботажа, поначалу хотя бы. AlexandrY(83 знак., 03.11.2008 22:40)
        
        интересно послушать - koyodza(05.11.2008 23:46)
        
        Да че слушать, у нас воодушевленные бездокументационными технологиями хотят ввести 3-х сменный режим работы. AlexandrY(130 знак., 06.11.2008 01:20)
        
        Отдельная тема? Так создавайте и рассказывайте! - diper(05.11.2008 11:51)
        
        Даже через много лет после завершения у тебя остаются общие представления о структуре и понимание своих стереотипов. Обычно когда нужно въезжать в объёмное чужое - народ норовит откосить и под любым предлогом доказать, что проще переписать. Меня лично st232bd(77 знак., 03.11.2008 18:35)
        
        Ну, ХЗ. Я всегда честно изучал чужое и сдавал заказчику. И только потом для себя сам решеал переписывать заново или продолжить поддерживать то, что есть... POV(203 знак., 03.11.2008 20:06)
        
        Не сказал бы так категорично. Но элементарная самодисциплина и уважение/соблюдение собственных ~~понятий~~ принципов, разумеется, необходимы - культура производства должна быть на высоте - MBedder(03.11.2008 19:57)
        
        Пусть хоть раз пререпишут настоящее ОБЬЁМНОЕ, тогда и говорят. - Т.Достоевский(03.11.2008 18:41)
        
        Спасибо, кузяво. Надо только перевести теперь в формальные требования :-) - Shura(03.11.2008 17:48)
        
        Из первой ссылки - литературный английский. - st232bd(03.11.2008 17:51)
        
        По ссылке пример. А мне надо требования - Shura(03.11.2008 18:09)
        
        Формальные требования - могут дать формальный результат. Всё равно полностью зависишь от степени ясности мысли программера. Если он завёрнутый - ничего не поможет. Требования - типа программа должна сопровождаться подробными и понятными коментариями. А st232bd(104 знак., 03.11.2008 18:21)
        
        Сам читать буду обязательно. Но для начала требования надо составить формальные, чтобы пипл представлял что от них требуется. - Shura(03.11.2008 20:01)
        
        Даже сверхподробные комментарии к коряво написанной и плохо структурированной программе ни на йоту не добавят стороннего понимания - MBedder(03.11.2008 19:54)
        
        Т.е. имеет смысл начать структурирование программ с пересмотра кадрового состава. Шуре нужно выбрать из всех программера с мозгами, а остальных - на подсобные работы. - st232bd(04.11.2008 09:20)
        
        Ну, кадровое решение уже предлагалось :-) По поводу комментариев - я почти все комментарии удаляю из заимствованного кода. Раздражает формальное комментирование. Главное - структура кода. А еще важнее системное проектирование - события, их обработка, Vladimir Ljaschko(124 знак., 04.11.2008 10:15)
        
        А почитать про требования к структурированию где? - Shura(05.11.2008 09:59)
        
        А вот тут засада... Есть структурирование как часть стиля (файлы, процедуры, комментарии, наконец) - поверхностное, и про это почитать хватает, а есть структурирование как реализация всех функций прибора как набора приоритетных и не очень приоритетных Vladimir Ljaschko(514 знак., 05.11.2008 15:40, ссылка)
        
        Каротче, из обсуждения я вынес удивительную вещь. Вопросами качества ПО никто толком не занимается, всё отдано на откуп разработчику. Есть даже ГОСТ довольно свежий на эту тему, но он абсолютно пустой и бесполезный. Вопчем, программеры устроились круче Shura(50 знак., 05.11.2008 16:00)
        
        Ты абсолютно прав. Особо свободолюбивые программеры могут потерять в зарплате, но продолжают жрать свой кактус. - Vladimir Ljaschko(05.11.2008 18:13)
        
        По рассказам, программеры, поработавшие в Мотороле (CMMI level 5, все охрененно "зрело" и формализовано дальше некуда, правда самой Мотороле это не очень помогает) еще долго отпускают мрачные шуточки по поводу этой системы. =) - she(05.11.2008 18:20)
        
        Истина посередине - как в большинстве споров. - Vladimir Ljaschko(05.11.2008 18:47)
        
        Так где же, где эта золотая середина? Рассказываю как у нас - все грят "уёво". Спрашиваю, как у вас - никто ничего внятного сказать не может... ;-) - Shura(05.11.2008 22:44)
        
        в каждой организации/или отдельном крупном (открытом) проекте стиль складывается не за один час, а постепенно. Рекомендаций по стилю в сети масса -- читать не перечитать. Все равно придется адаптировать к вашей компании. bialix_(451 знак., 06.11.2008 13:03)
        
        Наша цель - ~~коммунизм~~ ~~капитализм~~ социализьм с человеческимъ эбломъ Shura(409 знак., 06.11.2008 13:49)
        
        Малой кровью формализовать такие требования невозможно. Поэтому насобирай примеров, отбери наиболее и наименее ТЕБЕ приглянувшиеся, и раздай исполнителям в виде наглядных пособий "Как надо" и "Как не надо/нельзя" - толк будет, уверяю - MBedder(06.11.2008 13:58)
        
        Тута вот какое дело Shura(164 знак., 06.11.2008 14:03)
        
        не пытайтесь съесть слона за один присест. его надо кушать маленькими кусочками. нужны формальные требования? начинайте писать по-немногу. bialix_(1133 знак., 06.11.2008 19:30)
        
        формально плохо. он, если что, скажет "у меня пули вылетели". Придется придумывать кучу доков регламентирующих методики проверки и испытаний, а потом эти испытания проводить. - POV(06.11.2008 17:41)
        
        Шура, ну это же утопия! Ну не получится от него добиться внятного кода силовыми методами! Будут формальные требования - будет до точки их выполнять, но код, если захочет, как был, так и остянется нечитаемым. Про то, что можно навернуть читаемый код jaga-jaga(134 знак., 06.11.2008 15:17)
        
        "требования к структурированию кода" - если вдуматься, то это же, как требования к рисованию картин, есть они?? - jaga-jaga(06.11.2008 15:19)
        
        Ну не надо софт с картиной сравнивать. Скорее с чертежом, к которому требования как раз есть, абсолютно чёткие. - Shura(06.11.2008 17:10)
        
        требования по оформлению, т.е. стиль. а вот где разрез сделать, а сколько их сделать - никаких почти требований. от рисующего зависит будет хня или внятный читаемый чертеж. - jaga-jaga(06.11.2008 17:34)
        
        Везде не очень хорошо. У меня так - с отпетыми ассемблерщиками работать не смог. Особенность проектов - удаленный заказчик. После нескольких серьезных влетов (например, залило водой больницу в Дрездене) понял - или я лично отвечаю за весь проект и все Vladimir Ljaschko(842 знак., 06.11.2008 10:55)
        
        Рассказать как научить мыслить системно, писать программы??? Надежность повышаем формализованным и единообразным окружением разработчиков. На картинке содержание инструкции по написанию кода. Она короткая, но ссылается еще на инструкцию по cvs (тоже Алексей Мусин(87 знак., 06.11.2008 07:57)

Микроконтроллеры