Часто большие софтверные проекты характеризуют как «сложные». На самом деле действительно сложные задачи в промышленном программировании встречаются крайне редко, а настоящая проблема состоит в том, что проекты просто гниют. Можно выделить три основных причины загнивания:
Усилия разработчиков слабо связаны с интересами заказчика. В подавляющем большинстве случаев заказчик слабо представляет себе, что же он хочет, а программисты предпочитают заниматься только своими проблемами.
Используются технологии не адекватные решаемым задачам. Например, разработчики пытаются сделать свою библиотеку для применения в следующих проектах или заказчик приобрёл страшную универсальную софтину.
Низкое качество кода.
Наивный подход вроде внедрения RUP или получения сертификата CMM предполагает недопущения гнилости путём создания стерильной атмосферы на производстве. Joel Test и eXtreme Programming описывают практики, которые действительно позволяют предотвращать появление проблем в реальных условиях, а если нужно — то решать их.
Лично мне нравится находить плохо пахнущий кода и исправлять его. Свою миссию на работе я вижу в том, чтобы бороться с гниением, как превентивными мерами, так и в явном виде. Такой подход имеет ряд трудностей:
Заказчики не готовы к тщательному обсуждению проекта и не любят идиотских вопросов, особенно когда не могут на них ответить.
Задачи решаются слишком быстро и возникает недозагрузка, особенно в конце проекта.
У стабильной системы очень маленький объём работ по сопровождению.
Люди с низкой квалификацией плохо приживаются в проекте.
Хроническое отсутствие пафоса, что мешает производить хорошее впечатление на потенциального заказчика.
Но есть один большой плюс: успешно завершённые в срок проекты.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Часто большие софтверные проекты характеризуют как «сложные». На самом деле действительно сложные задачи в промышленном программировании встречаются крайне редко, а настоящая проблема состоит в том, что проекты просто гниют.
Не понравилось. Похоже на то, что автор с какой-то целью решил заняться саморекламой. 50% текста — в стиле "магазина на диване".
По-видимому, речь идёт о каком-то очередном "лекарстве от всех болезней". Но при этом упорно не говорится, какое именно. Совет "Будем делать хорошо и не будем плохо" — хороший, но совершенно бесполезный.
Лично я сталкивался в своей практике со многими методиками. Все они, как и фармацевтические препараты, имеют свои фармакологические свойства, показания к применению, противопоказания, побочные действия и т.д. Так что, осторожней, господа, с сильнодействующими средствами!
Здравствуйте, Voblin, Вы писали:
V>Лично я сталкивался в своей практике со многими методиками. Все они, как и фармацевтические препараты, имеют свои фармакологические свойства, показания к применению, противопоказания, побочные действия и т.д.
Дело не в методике, дело в здравом смысле, который очень часто бывает трудно найти в судьбоносных решениях наших коллег. Вот что действительно странно, так это то, что автору нравится работа ассенизатора. Это уже смахивает на извращеньице.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Дело не в методике, дело в здравом смысле, который очень часто бывает трудно найти в судьбоносных решениях наших коллег. Вот что действительно странно, так это то, что автору нравится работа ассенизатора. Это уже смахивает на извращеньице.
А так же противоречит первой заповеди программиста, "не навреди".
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, IT, Вы писали:
IT>>Дело не в методике, дело в здравом смысле, который очень часто бывает трудно найти в судьбоносных решениях наших коллег. Вот что действительно странно, так это то, что автору нравится работа ассенизатора. Это уже смахивает на извращеньице.
MS>А так же противоречит первой заповеди программиста, "не навреди".
Предпочитаю активный code-review в течении всего времени разработки проекта.
Полностью полагаться на юнит-тестинг и другой тестинг не могу, это ненадежно в принципе. Даже сами исходники юнит-тестов должны так же подвергаться постоянному review.
Основная проблема, которую замечаю у ребят при разработке юнит-тестов, что то, что юнит-тесты зачастую направлены на тестирование функциональности, а не кода.
Код обычно гораздо богаче своей основной функциональности. Методология "тесты вперед" выглядит красиво, но должна использоваться аккуратно, ибо не обыгрывает все возможные варианты реальной имплементации. Самые последние тесты должны быть написаны по зеркальной методологии "тесты назад" , и должны проходить абсолютно по всем веткам исходников, т.е. в принципе должны быть написаны отталкиваясь от исходников.
Ввиду того, что полное покрытие кода юнит-тестами потенциально может отнять в несколько раз (во много раз) больше трудоемкости, чем сама разработка системы, придпочитаю комбинированный подход: code review и "сплошной" юнит тестинг (местами )
Акценты расставляются так: чем выше уровень задачи, тем более "сплошным" должно быть покрытие юнит-тестами, т.е. юнит-тесты под прикладную часть пишутся отталкиваясь от кода, и обязаны покрыть все ветки всех алгоритмов. Чем ниже уровень, тем более юнит-тесты близки к функциональным и тем жестче code-review. В этой области рулят методологии, далекие от eXtreme. Жесткая дисциплина проектирования и т.д.
--------
Кстати, интересное наблюдение. Чаще всего наблюдаю "жесткое" проектирование на самом верху и на самом низу. Вся "средняя" часть так и просится на экстрим, не зря жависты его обожают.
Здравствуйте, McSeem2, Вы писали: IT>>Дело не в методике, дело в здравом смысле, который очень часто бывает трудно найти в судьбоносных решениях наших коллег. Вот что действительно странно, так это то, что автору нравится работа ассенизатора. Это уже смахивает на извращеньице. MS>А так же противоречит первой заповеди программиста, "не навреди".
А как же рефакторинг? В лес?
under «*none*»,
... << RSDN@Home 1.1.4 beta 7 rev. 455>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Voblin, Вы писали:
V>>Лично я сталкивался в своей практике со многими методиками. Все они, как и фармацевтические препараты, имеют свои фармакологические свойства, показания к применению, противопоказания, побочные действия и т.д.
IT>Дело не в методике, дело в здравом смысле, который очень часто бывает трудно найти в судьбоносных решениях наших коллег. Вот что действительно странно, так это то, что автору нравится работа ассенизатора. Это уже смахивает на извращеньице.
Я тоже получаю удовольствие от работы "асенизатором" Если покопаться то мотивов можно найти порядочно.
Здравствуйте, GarryIV, Вы писали:
IT>>Дело не в методике, дело в здравом смысле, который очень часто бывает трудно найти в судьбоносных решениях наших коллег. Вот что действительно странно, так это то, что автору нравится работа ассенизатора. Это уже смахивает на извращеньице.
GIV>Я тоже получаю удовольствие от работы "асенизатором" Если покопаться то мотивов можно найти порядочно.
Я же не сказал что это плохо, я сказал что это странно
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
GIV>>Я тоже получаю удовольствие от работы "асенизатором" Если покопаться то мотивов можно найти порядочно. IT>Я же не сказал что это плохо, я сказал что это странно
Здравствуйте, Igor Sukhov, Вы писали:
GIV>>>Я тоже получаю удовольствие от работы "асенизатором" Если покопаться то мотивов можно найти порядочно. IT>>Я же не сказал что это плохо, я сказал что это странно
IS>Почему странно то ? Поясни, пожалуйста.
Я смотрю тут компашка собирается... тогда я лучше помолчу
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
IT>>>Я же не сказал что это плохо, я сказал что это странно
IS>>Почему странно то ? Поясни, пожалуйста.
IT>Я смотрю тут компашка собирается... тогда я лучше помолчу
куда ты денешься с подводной лодки, все равно долго не вытерпишь, так что лучше говори сейчас =)
Здравствуйте, IT, Вы писали:
IT>Дело не в методике, дело в здравом смысле, который очень часто бывает трудно найти в судьбоносных решениях наших коллег. Вот что действительно странно, так это то, что
автору нравится работа ассенизатора. Это уже смахивает на извращеньице.
По поводу статьи согласен. Эх не видишь ты романтики ассенизаторства...
Здравствуйте, _FRED_, Вы писали:
MS>>А так же противоречит первой заповеди программиста, "не навреди".
_FR>А как же рефакторинг? В лес?
Рефакторинг это все-таки нечто другое. Это связано как правило с существенными изменениями в дизайне и интерфейсах (а иначе какой же это рефакторинг?). Рефакторинг происходит, когда накапливается определенный, критический уровень энтропии. А просто переписывать куски чужого кода, которые вполне работают, но просто тебе не нравятся — это неправильно. Мало того, что это неинтересно (лично мне), так можно и дров наломать.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Рефакторинг это все-таки нечто другое. Это связано как правило с существенными изменениями в дизайне и интерфейсах (а иначе какой же это рефакторинг?). Рефакторинг происходит, когда накапливается определенный, критический уровень энтропии. А просто переписывать куски чужого кода, которые вполне работают, но просто тебе не нравятся — это неправильно. Мало того, что это неинтересно (лично мне), так можно и дров наломать. Рефакторинг ни в коем случае не должен затрагивать интерфейс. Это просто улучшение кода при той же функциональности. Правда у каждого нормального программиста есть свои понятия на код с запашком. Поэтому рефакторинг — процесс практически вечный и зависит только от количества программистов.
Нужно ли переписывать куски чужого кода, если он работает, не знаю. Надо просто оценивать риски. Рефакторинг уменьшает риски по развитию программного продукта. Но если нет достаточных условий, в виде ходя бы unit и функциональных тестов по основной функциональности, то можно риски внесения новых ошибок значительно увеличить и получить совершенно обратный результат.
Здравствуйте, McSeem2, Вы писали:
MS>>>А так же противоречит первой заповеди программиста, "не навреди".
_FR>>А как же рефакторинг? В лес?
MS>Рефакторинг это все-таки нечто другое. Это связано как правило с существенными изменениями в дизайне и интерфейсах (а иначе какой же это рефакторинг?). Рефакторинг происходит, когда накапливается определенный, критический уровень энтропии. А просто переписывать куски чужого кода, которые вполне работают, но просто тебе не нравятся — это неправильно. Мало того, что это неинтересно (лично мне), так можно и дров наломать.
Это, имхо, вопрос методологии ака способ работы. Во всяких agile методологиях (к которым я, например, неровно дышу) рефакторинг — это постоянный процесс, часть процесса разработки: "написать тест — заставить его работать хоть как-нибудь — заставить его работать хорошо — убрать/порефакторить дублирование кода и неоптимальности".
По большому счету, исходное спаслание было именно о таких методологиях.
Здравствуйте, Igor Sukhov, Вы писали:
IS>куда ты денешься с подводной лодки, все равно долго не вытерпишь, так что лучше говори сейчас =)
Ну я как бы в подобных случаях предпочитаю другие аналогии, проект или код может быть горящим, быть весь в болячках, быть сиротой и т.п. Автор же предпочитает "находить плохо пахнущий код" и "бороться с гниением". Т.е. делая тоже самое я как бы предпочитаю думать, что я помогаю людям, а он предпочитает думать, что он ковыряется в фикалиях. Вот это мне и странно
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Дело не в методике, дело в здравом смысле, который очень часто бывает трудно найти в судьбоносных решениях наших коллег.
Все мы не без греха. Перед дедлайном чего только не наворотишь...
IT>Вот что действительно странно, так это то, что автору нравится работа ассенизатора. Это уже смахивает на извращеньице.
Отнюдь. Если, например, удаётся снять с программы тормознутость путём разгона критического участка в 10 раз, морального удовлетворения хватает на сутки.
Если нам не помогут, то мы тоже никого не пощадим.
, и должны проходить абсолютно по всем веткам исходников, т.е. в принципе должны быть написаны отталкиваясь от исходников.
* thriving in a production environment *
