-
- Ну, кадровое решение уже предлагалось :-) По поводу комментариев - я почти все комментарии удаляю из заимствованного кода. Раздражает формальное комментирование. Главное - структура кода. А еще важнее системное проектирование - события, их обработка, 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(164 знак., 06.11.2008 14:03)
- Малой кровью формализовать такие требования невозможно. Поэтому насобирай примеров, отбери наиболее и наименее ТЕБЕ приглянувшиеся, и раздай исполнителям в виде наглядных пособий "Как надо" и "Как не надо/нельзя" - толк будет, уверяю - MBedder(06.11.2008 13:58)
- Наша цель -
- Везде не очень хорошо. У меня так - с отпетыми ассемблерщиками работать не смог. Особенность проектов - удаленный заказчик. После нескольких серьезных влетов (например, залило водой больницу в Дрездене) понял - или я лично отвечаю за весь проект и все Vladimir Ljaschko(842 знак., 06.11.2008 10:55)
- Рассказать как научить мыслить системно, писать программы??? Надежность повышаем формализованным и единообразным окружением разработчиков. На картинке содержание инструкции по написанию кода. Она короткая, но ссылается еще на инструкцию по cvs (тоже Алексей Мусин(87 знак., 06.11.2008 07:57)
- в каждой организации/или отдельном крупном (открытом) проекте стиль складывается не за один час, а постепенно. Рекомендаций по стилю в сети масса -- читать не перечитать. Все равно придется адаптировать к вашей компании. bialix_(451 знак., 06.11.2008 13:03)
- Так где же, где эта золотая середина? Рассказываю как у нас - все грят "уёво". Спрашиваю, как у вас - никто ничего внятного сказать не может... ;-) - Shura(05.11.2008 22:44)
- Истина посередине - как в большинстве споров. - Vladimir Ljaschko(05.11.2008 18:47)
- По рассказам, программеры, поработавшие в Мотороле (CMMI level 5, все охрененно "зрело" и формализовано дальше некуда, правда самой Мотороле это не очень помогает) еще долго отпускают мрачные шуточки по поводу этой системы. =) - she(05.11.2008 18:20)
- Ты абсолютно прав. Особо свободолюбивые программеры могут потерять в зарплате, но продолжают жрать свой кактус. - Vladimir Ljaschko(05.11.2008 18:13)
- Каротче, из обсуждения я вынес удивительную вещь. Вопросами качества ПО никто толком не занимается, всё отдано на откуп разработчику. Есть даже ГОСТ довольно свежий на эту тему, но он абсолютно пустой и бесполезный. Вопчем, программеры устроились круче Shura(50 знак., 05.11.2008 16:00)
- А вот тут засада... Есть структурирование как часть стиля (файлы, процедуры, комментарии, наконец) - поверхностное, и про это почитать хватает, а есть структурирование как реализация всех функций прибора как набора приоритетных и не очень приоритетных Vladimir Ljaschko(514 знак., 05.11.2008 15:40, ссылка)
- А почитать про требования к структурированию где? - Shura(05.11.2008 09:59)
- Ну, кадровое решение уже предлагалось :-) По поводу комментариев - я почти все комментарии удаляю из заимствованного кода. Раздражает формальное комментирование. Главное - структура кода. А еще важнее системное проектирование - события, их обработка, Vladimir Ljaschko(124 знак., 04.11.2008 10:15)