Часто большие софтверные проекты характеризуют как «сложные». На самом деле действительно сложные задачи в промышленном программировании встречаются крайне редко, а настоящая проблема состоит в том, что проекты просто гниют. Можно выделить три основных причины загнивания:
Усилия разработчиков слабо связаны с интересами заказчика. В подавляющем большинстве случаев заказчик слабо представляет себе, что же он хочет, а программисты предпочитают заниматься только своими проблемами.
Используются технологии не адекватные решаемым задачам. Например, разработчики пытаются сделать свою библиотеку для применения в следующих проектах или заказчик приобрёл страшную универсальную софтину.
Низкое качество кода.
Наивный подход вроде внедрения 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 раз, морального удовлетворения хватает на сутки.
OT>Почитайте "Программистсткий камень": OT> ИМХО заповедь "не навреди" — самая вредная из заповедей OT> и вообще заповедь для программиста — вредная абстракция
Заповедь у программиста ровно одна, но поскольку она малоцензурная,
я ее цитировать тут не буду.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, GlebZ, Вы писали:
GZ>>Рефакторинг ни в коем случае не должен затрагивать интерфейс.
IT>Не должен затрагивать внешний интерфейс. Теперь осталось только в данном контексте дать определение понятию "внешний"
С внешним то понятно, по крайней мере в компонентном аспекте. А вот что такое внутренний, и насколько он достоен этого звания — уже не очень понятно.
С уважением, Gleb.
PS: чем-то напоминает фильм "Дежавю". "Вот это синкопа? Нет это не синкопа. Вот синкопа!".
Здравствуйте, GlebZ, Вы писали:
GZ>Рефакторинг ни в коем случае не должен затрагивать интерфейс. Это просто улучшение кода при той же функциональности. Правда у каждого нормального программиста есть свои понятия на код с запашком. Поэтому рефакторинг — процесс практически вечный и зависит только от количества программистов.
Рискну возразить. Правда, учитывая некоторую свою специфику, которая заключается вот в чем. Мне платят деньги не за программный код и даже не за функциональность (точнее сказать не просто за функциональность). Мне платят деньги за нетривиальные и эффективные решения, алгоритмические, инженерные и дизайнерские. На том и стоим. И вот с этой моей позиции, так называмое "просто улучшение кода при той же функциональности" является абсурдом. Если требуется улучшать код, значит я схалтурил раньше. Мне крайне неприятно возвращаться к халтурному коду, поэтому я стараюсь халтурить как можно меньше. Так получается дешевле. Конечно же, на стадии экспериментов с алгоримом я пробую всякие-разные промежуточные решения, в том числе и простейшие и заведомо неэффективные. Но эти промежуточные решения никогда не доходят до стадии релиза.
Бывают случаи, когда действительно имеет смысл заменить начинку на более эффективную, но они крайне редки. Ну, типа сообразил, как можно сделать слегка эффективнее.
А вот с интерфейсами, что внешними, что внутренними, все гораздо сложнее. Очень часто по началу весь дизайн является неочевидным, выясняется по ходу работы. Соответственно, приходится вносить изменения и улучшения. Я никогда не поверю в то, что все можно решить и узаконить на стадии проектирования. Не бывает такого, не только в программировании, но и вообще в любой инженерной деятельности. Конечно же, за исключением типовых решений (шаблонов проектирования) — там это возможно. Но во-первых, типовые решения актуальны как правило лишь для тривиальных задач, во-вторых, такие задачи и решения мне не интересны.
Резюмируя, могу сказать следующее. Писать код, который практически не требует улучшений, на порядок проще, чем дизайнить грамотные интерфейсы (внешние, внутренние — не важно). И если приходится существенно (и главное — постоянно) улучшать существующий код, значит что-то не ладно в датском королевстве.
То есть, я не приемлю подход, при котором надо по-быстрому напедалить абы-как, а потом долго и нудно улучшать и переписывать.
- Неладно шьешь, донюшка!
— Я еще пороть буду, матушка!
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Рискну возразить. Правда, учитывая некоторую свою специфику, которая заключается вот в чем. Мне платят деньги не за программный код и даже не за функциональность (точнее сказать не просто за функциональность). Мне платят деньги за нетривиальные и эффективные решения, алгоритмические, инженерные и дизайнерские. На том и стоим. И вот с этой моей позиции, так называмое "просто улучшение кода при той же функциональности" является абсурдом. Если требуется улучшать код, значит я схалтурил раньше. Мне крайне неприятно возвращаться к халтурному коду, поэтому я стараюсь халтурить как можно меньше. Так получается дешевле. Конечно же, на стадии экспериментов с алгоримом я пробую всякие-разные промежуточные решения, в том числе и простейшие и заведомо неэффективные. Но эти промежуточные решения никогда не доходят до стадии релиза.
Везука!!!! А я вот, не особо могу. То ли не так делали, то ли ударился в детсве. В процессе построения решения практически всегда существуют некоторые неправильные решения, о которых начинаешь догадываться только потом, в процессе реализации, или даже после. Сказать что я с первого раза пишу оптимальный код, к сожалению не могу. Иногда в процессе работы, переписываю некоторые куски на которые через некоторое время взглянул с другой стороны. Иногда делаю сначало примерно, чтобы работало, а потом рефакторю чтобы эффективно работало и расширялось. Особенно если это касается как раз, для более менее нетривиальных алгоритмов которые реализуешь в первый раз. Они просто в голове и на бумаге не умещаются. MS>Бывают случаи, когда действительно имеет смысл заменить начинку на более эффективную, но они крайне редки. Ну, типа сообразил, как можно сделать слегка эффективнее.
Это вопрос времени и денег. Которых всегда не хватает.
MS>А вот с интерфейсами, что внешними, что внутренними, все гораздо сложнее. Очень часто по началу весь дизайн является неочевидным, выясняется по ходу работы. Соответственно, приходится вносить изменения и улучшения. Я никогда не поверю в то, что все можно решить и узаконить на стадии проектирования. Не бывает такого, не только в программировании, но и вообще в любой инженерной деятельности. Конечно же, за исключением типовых решений (шаблонов проектирования) — там это возможно. Но во-первых, типовые решения актуальны как правило лишь для тривиальных задач, во-вторых, такие задачи и решения мне не интересны.
На любой итерации для компонента (который конечно может быть библиотекой) выделяю интерфейс. Даже если этим компонентом буду работать только я и он не входит ни в какую официальную документацию. Именно эта вещь максимально продумывается чтобы не было изменений(насчет изменений это конечно сказка, но максимально уменьшаю вероятность и количество будующих изменений). По возможности пишу unit-тесты под этот интерфейс. Это также помогает его продумать. Ну а дальше, если задача сложная, то я пишу как придется. Главное чтобы работало. Многое действительно получается сразу оптимально(опыт все таки сказывается), ну а многое через пень-колоду. Ну а дальше, уже решаю, может ли кто-то кроме меня достигнуть того-же уровня просветления как и я, и сможет понять всю гениальность моего замысла. В процентах 30 — сразу отвечу что нет. Тогда и начинается рефакторинг. И кстати, в этом процессе появляются мысли о которых я почему-то не домыслил до этого и исправляются тараканы которых и в лупу не заметишь.
(Блин, какой-то ХП получилось. Хотя к его апологетам себя не отношу).
Как, наверно, ты уже заметил, что внутренние интерфейсы я за интерфейсы не считаю. Однажды дошло до смешного, посмотрел две версии файла, тот который делал четыре года назад, и тот который работал в данное время. Практически кроме интерфейса(который был только дополнен), ничего общего не осталось.
MS>Резюмируя, могу сказать следующее. Писать код, который практически не требует улучшений, на порядок проще, чем дизайнить грамотные интерфейсы (внешние, внутренние — не важно).
Кому как. Мне например наоборот. Но это еще вопрос относительности, смотря что имеется ввиду под дизайнить грамотные интерфейсы. MS>И если приходится существенно (и главное — постоянно) улучшать существующий код, значит что-то не ладно в датском королевстве.
MS>То есть, я не приемлю подход, при котором надо по-быстрому напедалить абы-как, а потом долго и нудно улучшать и переписывать.
Я бы рад бы, да вот не получается. Я неумный?
Здравствуйте, GlebZ, Вы писали:
MS>>То есть, я не приемлю подход, при котором надо по-быстрому напедалить абы-как, а потом долго и нудно улучшать и переписывать. GZ>Я бы рад бы, да вот не получается. Я неумный?
Здесь дело в другом. Не знаю, как сформулировать получше. В общем, дело в изначальном внутреннем стремлении и складе характера. "Умность" здесь — фактор ортогональный. Мне, например, противопоказано работать в проектах с жесткими сроками и планами-графиками. Разумеется, время от времени приходится участвовать именно в таких проектах. Но я стремлюсь минимизировать это дело и максимизировать количество степеней свободы для творчества. Ну и соответствующим образом выбираю себе места работы. Но это не самый легкий путь к успеху. И иногда чреват боком
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Здесь дело в другом. Не знаю, как сформулировать получше. В общем, дело в изначальном внутреннем стремлении и складе характера. "Умность" здесь — фактор ортогональный.
Да уж. MS>Мне, например, противопоказано работать в проектах с жесткими сроками и планами-графиками. Разумеется, время от времени приходится участвовать именно в таких проектах. Но я стремлюсь минимизировать это дело и максимизировать количество степеней свободы для творчества. Ну и соответствующим образом выбираю себе места работы.
У меня другая напасть. Творчество на меня само нападает. (ну а если не я, то кто-же). В любом проекте (если конечно процесс разработки не довели до высшей степени маразма который описан только в книжках) голова на первом месте. А выполнить это в срок ( и главное определить этот срок) вот это уже искуство.
Теперь по теме разговора. Для меня рефакторить чужой код на порядок легче чем писать свой. Достаточно тупая работа. Алгоритмы уже заложены. Выдумывать ничего не надо. Просто подводишь код к тем шаблонам которые сам используешь. И все... Скукотища, которая просто использует твой предыдущий опыт. То ли дело навернуть алгебру моноидов
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, GlebZ, Вы писали:
GZ>>Рефакторинг ни в коем случае не должен затрагивать интерфейс. Это просто улучшение кода при той же функциональности. Правда у каждого нормального программиста есть свои понятия на код с запашком. Поэтому рефакторинг — процесс практически вечный и зависит только от количества программистов.
MS>Рискну возразить. Правда, учитывая некоторую свою специфику, которая заключается вот в чем. Мне платят деньги не за программный код и даже не за функциональность (точнее сказать не просто за функциональность). Мне платят деньги за нетривиальные и эффективные решения, алгоритмические, инженерные и дизайнерские. На том и стоим.
+1
Завидую белой завистью. Сам мечтаю так работать, только что-то все не сладывается (или , не знаю, что точнее).
MS> И вот с этой моей позиции, так называмое "просто улучшение кода при той же функциональности" является абсурдом. Если требуется улучшать код, значит я схалтурил раньше. Мне крайне неприятно возвращаться к халтурному коду, поэтому я стараюсь халтурить как можно меньше. Так получается дешевле. Конечно же, на стадии экспериментов с алгоримом я пробую всякие-разные промежуточные решения, в том числе и простейшие и заведомо неэффективные. Но эти промежуточные решения никогда не доходят до стадии релиза. MS>Бывают случаи, когда действительно имеет смысл заменить начинку на более эффективную, но они крайне редки. Ну, типа сообразил, как можно сделать слегка эффективнее.
Кроме понятия эффективности, про которую ты уже написал, есть еще и другие факторы, которые могут привести к рефакторингу. Вот, скажем, с чем я сталкиваюсь: создается какой-то вспомогательный инструмент (какая-нибудь библиотека), который используется в решении реальной задачи. Через какое-то время этот инструмент устаревает, его развитие прекращается и выпускается его новый аналог (либо сильно обновленная версия), уже не совместимый со старым инструментом. Если уже созданное решение требуется сопровождать и развивать, то наступает момент, когда проще перевести старый код на использование нового инструмента. Это напоминает историю с программированием под Windows -- сначала самописные классы, затем MFC, затем WTL. Функциональность продукта вроде не меняется, а начинка -- в значительной степени. И нужно это для того, чтобы получить возможность изменить функциональность в последствии.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, McSeem2, Вы писали:
GZ>Везука!!!! А я вот, не особо могу. То ли не так делали, то ли ударился в детсве. В процессе построения решения практически всегда существуют некоторые неправильные решения, о которых начинаешь догадываться только потом, в процессе реализации, или даже после. Сказать что я с первого раза пишу оптимальный код, к сожалению не могу. Иногда в процессе работы, переписываю некоторые куски на которые через некоторое время взглянул с другой стороны. Иногда делаю сначало примерно, чтобы работало, а потом рефакторю чтобы эффективно работало и расширялось. Особенно если это касается как раз, для более менее нетривиальных алгоритмов которые реализуешь в первый раз. Они просто в голове и на бумаге не умещаются.
У меня такая же история. Только я обязательно первую реализацию сложного алгоритма делаю именно на бумаге. Бывает, что уже на бумаге готовый результат получается только с третьей-четвертой попытки. А затем переписываю на компьютер, причем стараюсь делать это на свежую голову или хотя бы через пару часов после написания кода на бумаге -- сразу видны ошибки и промахи. Хотя не все. Бывает, что при "вылизывании" быстродействия/ресурсоемкости приходится что-то переделывать.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>У меня такая же история. Только я обязательно первую реализацию сложного алгоритма делаю именно на бумаге. Бывает, что уже на бумаге готовый результат получается только с третьей-четвертой попытки. А затем переписываю на компьютер, причем стараюсь делать это на свежую голову или хотя бы через пару часов после написания кода на бумаге -- сразу видны ошибки и промахи. Хотя не все. Бывает, что при "вылизывании" быстродействия/ресурсоемкости приходится что-то переделывать.
Чисто любопытно. А что мешает использовать редактор заместо бумаги для написания кода? Чисто привычка? Но ведь на бумаге писать код гораздо более трудоемко! Лично я использую бумагу и ручку для формул, геометрических построений, диаграмм и т.д. Что ни говори, но никакой графический редактор не сравнится по эффективности с бумажным листом А вот текстовый — вполне.
Блок-схемы алгоритмов канули в лету вместе с GOTO. А выписывать на бумаге строчки кода — как-то оно очень трудоемко. Я предпочитаю редактор и компилятор . При этом у меня только около 10-20% написанного кода идет в production, остальное в конечном итоге — в мусорку.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, eao197, Вы писали:
MS>>Рискну возразить. Правда, учитывая некоторую свою специфику, которая заключается вот в чем. Мне платят деньги не за программный код и даже не за функциональность (точнее сказать не просто за функциональность). Мне платят деньги за нетривиальные и эффективные решения, алгоритмические, инженерные и дизайнерские. На том и стоим. E>+1
E>Завидую белой завистью. Сам мечтаю так работать, только что-то все не сладывается (или , не знаю, что точнее).
Ну как я уже сказал, этот путь не самый прямой и простой. И на самом деле, я конечно же слегка приукрасил свою сегодняшнюю ситуацию, но в общем и целом, незначительно.
E>Кроме понятия эффективности, про которую ты уже написал, есть еще и другие факторы, которые могут привести к рефакторингу. Вот, скажем, с чем я сталкиваюсь: создается какой-то вспомогательный инструмент (какая-нибудь библиотека), который используется в решении реальной задачи. Через какое-то время этот инструмент устаревает, его развитие прекращается и выпускается его новый аналог (либо сильно обновленная версия), уже не совместимый со старым инструментом. Если уже созданное решение требуется сопровождать и развивать, то наступает момент, когда проще перевести старый код на использование нового инструмента. Это напоминает историю с программированием под Windows -- сначала самописные классы, затем MFC, затем WTL. Функциональность продукта вроде не меняется, а начинка -- в значительной степени. И нужно это для того, чтобы получить возможность изменить функциональность в последствии.
Да, конечно. Именно поэтому я ненавижу программировать GUI и предпочитаю "ваять нетлеку" (это такой само-сарказм).
Но это бывает чревато. Например, тем, что на интервью я буду выглядеть весьма бледно по сравнению с людьми, съевшими собаку на MFC/COM/WTL/.Net/etc. Но мне не хочется тратить жизнь на освоение API, которые заведомо обречены на вымирание (не потому что они плохи, а потому что будет что-то новое). Но повторюсь еще раз, в моем подходе весьма велик фактор риска.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
IT>>Дело не в методике, дело в здравом смысле, который очень часто бывает трудно найти в судьбоносных решениях наших коллег. Вот что действительно странно, так это то, что автору нравится работа ассенизатора. Это уже смахивает на извращеньице.
MS>А так же противоречит первой заповеди программиста, "не навреди".
Э... заповедь плохого программиста, однако.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IT, Вы писали:
V>>Лично я сталкивался в своей практике со многими методиками. Все они, как и фармацевтические препараты, имеют свои фармакологические свойства, показания к применению, противопоказания, побочные действия и т.д. IT>Дело не в методике, дело в здравом смысле, который очень часто бывает трудно найти в судьбоносных решениях наших коллег. Вот что действительно странно, так это то, что автору нравится работа ассенизатора. Это уже смахивает на извращеньице.
Да не, нормальное следствие "эстетического" подхода к разработке программы. Типа такого: "Не знаю точно что, но что-то мне здесь не нравится. Сильно не нравится. Ergo — надо переписать."
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Voblin, Вы писали:
V>По-видимому, речь идёт о каком-то очередном "лекарстве от всех болезней". Но при этом упорно не говорится, какое именно. Совет "Будем делать хорошо и не будем плохо" — хороший, но совершенно бесполезный.
Прально. Гораздо лучше совет: "Всегда делать настолько хорошо, насколько можем." Просто товарисч пытается описать применение мозгов в разработке ПО.
V>Лично я сталкивался в своей практике со многими методиками. Все они, как и фармацевтические препараты, имеют свои фармакологические свойства, показания к применению, противопоказания, побочные действия и т.д. Так что, осторожней, господа, с сильнодействующими средствами!
Не переживай. У многих с этим средством большой напряг. А у кого не напряг, у тех, как правило, всё получается.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, McSeem2, Вы писали:
MS>>>То есть, я не приемлю подход, при котором надо по-быстрому напедалить абы-как, а потом долго и нудно улучшать и переписывать. GZ>>Я бы рад бы, да вот не получается. Я неумный? MS>Здесь дело в другом. Не знаю, как сформулировать получше. В общем, дело в изначальном внутреннем стремлении и складе характера. "Умность" здесь — фактор ортогональный.
Ну, во всяком случае, "умность" немало помогает в борьбе с менеджментом. Кстати, забавно, но как правило контраргументы умных (в смысле — начитанных, грамотных и т.п., но без э... назовём это "унутренним стержнем", если хочешь — нефритовым ) сводятся к двум постулатам: а) всё равно всё переделывать когда-нибудь, а потому нафига париться? и б) где мы потом найдём таких же умников, так что, валяй давай, как попроще.
MS>Мне, например, противопоказано работать в проектах с жесткими сроками и планами-графиками. Разумеется, время от времени приходится участвовать именно в таких проектах. Но я стремлюсь минимизировать это дело и максимизировать количество степеней свободы для творчества. Ну и соответствующим образом выбираю себе места работы. Но это не самый легкий путь к успеху.
MS>И иногда чреват боком
Ну дык, многим в кайф "давить" такую позицию, как у тебя. Это вообще пунктик в наше время: "Хрен здесь думать? Беги!"
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IT, Вы писали:
GZ>>Рефакторинг ни в коем случае не должен затрагивать интерфейс. IT>Не должен затрагивать внешний интерфейс. Теперь осталось только в данном контексте дать определение понятию "внешний"
А что тут определять? Если интерфейс выставлен для использования кому-то кроме нас самих (команды, компании и т.п.) — он внешний, иначе — внутренний.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, eao197, Вы писали:
E>Если уже созданное решение требуется сопровождать и развивать, то наступает момент, когда проще перевести старый код на использование нового инструмента. Это напоминает историю с программированием под Windows -- сначала самописные классы, затем MFC, затем WTL. Функциональность продукта вроде не меняется, а начинка -- в значительной степени.
Можнет это называется портированием?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, McSeem2, Вы писали:
MS>Если требуется улучшать код, значит я схалтурил раньше.
Это справедливо только если ты точно, на все сто понимаешь требования к задаче, которые никогда не изменятся.
MS>А вот с интерфейсами, что внешними, что внутренними, все гораздо сложнее. Очень часто по началу весь дизайн является неочевидным, выясняется по ходу работы. Соответственно, приходится вносить изменения и улучшения. Я никогда не поверю в то, что все можно решить и узаконить на стадии проектирования.
Вот это гораздо ближе к телу. И тот же рефакторинг казалось бы вполне нормального и удачного кода — это обычное дело, если проходится готовить его к новой функциональности, которая ранее не планировалась.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Геннадий Васильев, Вы писали:
IT>>Не должен затрагивать внешний интерфейс. Теперь осталось только в данном контексте дать определение понятию "внешний"
ГВ>А что тут определять? Если интерфейс выставлен для использования кому-то кроме нас самих (команды, компании и т.п.) — он внешний, иначе — внутренний.
А вот и не угадал Я скорее имею ввиду внешние границы рефакторинга, чем системы в целом.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Да не, нормальное следствие "эстетического" подхода к разработке программы.
Это не нормально. Просто все мы привыкли считать чужой код дерьмом. Ну что поделать? Через неделю работы любой нормальный русский программист уже считает себя экстраординари личностью, после первого же архитектурного решения — Наполеоном Бонапартом. Правильный код только мой, остальное всё дерьмо! Вполне естественно, что в таких условиях можно сделать только карьеру ассенизатора. Это — неправильно! Потом всю жизнь приходится по капле выдавливать из себя экстраординарность, наполеонов и ассенизаторов.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, eao197, Вы писали:
E>>Если уже созданное решение требуется сопровождать и развивать, то наступает момент, когда проще перевести старый код на использование нового инструмента. Это напоминает историю с программированием под Windows -- сначала самописные классы, затем MFC, затем WTL. Функциональность продукта вроде не меняется, а начинка -- в значительной степени.
IT>Можнет это называется портированием?
Да, вероятно, так будет правильнее. Хотя когда речь идет о смене одного своего инструмента на другой, но лучше , то потрирование -- это слишком громко сказано.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, eao197, Вы писали:
E>>У меня такая же история. Только я обязательно первую реализацию сложного алгоритма делаю именно на бумаге. Бывает, что уже на бумаге готовый результат получается только с третьей-четвертой попытки. А затем переписываю на компьютер, причем стараюсь делать это на свежую голову или хотя бы через пару часов после написания кода на бумаге -- сразу видны ошибки и промахи. Хотя не все. Бывает, что при "вылизывании" быстродействия/ресурсоемкости приходится что-то переделывать.
MS>Чисто любопытно. А что мешает использовать редактор заместо бумаги для написания кода? Чисто привычка? Но ведь на бумаге писать код гораздо более трудоемко! Лично я использую бумагу и ручку для формул, геометрических построений, диаграмм и т.д. Что ни говори, но никакой графический редактор не сравнится по эффективности с бумажным листом А вот текстовый — вполне. MS>Блок-схемы алгоритмов канули в лету вместе с GOTO. А выписывать на бумаге строчки кода — как-то оно очень трудоемко. Я предпочитаю редактор и компилятор . При этом у меня только около 10-20% написанного кода идет в production, остальное в конечном итоге — в мусорку.
Я сам иногда удивляюсь, почему мне проще писать на бумаге. Здесь есть, имхо, ряд факторов:
Субъективный:
Привычка. Когда я начинал учиться программировать, машинного времени нам давали три пары на две недели (т.е. всего 6 часов). Естественно, что ничего путного в таких условиях при программировании прямо на машине не получалось. Вот и привык сначала всю программу на бумаге расписывать. Затем весь код писать на бумаге стало уже невозможно физически, но вот самые сложные и/или ответственные куски продолжаю так разрабатывать.
Объективные (имхо):
Навыки письма нам прививают в раннем детстве и для нас они становятся чуть ли не безусловными рефлексами. Я вот совершенно не задумываюсь, как писать карандашом или как вычеркнуть несколько написанных от руки слов или предложений. С редакторами все не так. Набирая текст в редакторе по неволе приходится отвлекаться на разные вспомогательные вещи. Вот как, например, удалить строку текста в редакторе? Если это Turbo C или редактор Far-а -- то ^Y, если Vi -- dd (а перед этим, возможно, ESC), если Emacs (могу ошибиться) -- ^KK, если нотепад -- Home,Shift+Down,Del. Или запись текста (хотя бы не забывать это делать, если autosave нет). Или вот как удалить или заменить неверно написанное слово? На бумаге все очень просто -- берешь и вычеркиваешь не задумываясь. А в редакторе нужно как-то переместиться на нужно слово (мышкой или клавиатурой). Далее нужно как-то решить как слово удалять. Либо просто backspace-ом, либо просто Del-ом, либо Shift+Control+Left(Right) и Del, либо Ctrl+Del, либо Ctrl+Backspace, либо (Vim) dw (dw) или db (dB). Даже если мы не думаем об этом, подсознание все равно отвлекается на такие мелочи от основной работы -- придумывания решения.
Обозримость. На кране, даже с моим разрешением 1400x1050 я могу видеть только ограниченное количество строк всего нескольких файлов. Если же у меня есть решение на бумаге, причем, обязательно написанных только на одной строне листа, то я могу заложить листами весь письменный стол и легко переключаться с одного фрагмента кода на другой, держа при этом в поле зрения большое количество фрагментиков. Особенно это удобно при работе с диаграмами (a-la UML). Здесь получается так же, как с обычными книжками vs. электронными: в обычной книге я могу заложить сразу несколько мест книги и легко смотреть то на одну страницу, то на другую. А вот в элетронной (на Palm-е, скажем) это значительно труднее.
Мобильность . Когда у меня часть кода написана на бумаге, я могу продолжить с ним работать даже не имея под рукой компьютера. Например, заняла его жена, чтобы свою почту проверить, а я забрал свои бумаги, ушел на кухню и работать, работать и еще раз работать .
Пробывал делать так используя вместо бумаги Palm -- обозримость на нем совсем никакая.
Работа над кодом проходит в две итерации. Первая -- на бумаге, вторая при наборе на компьютере. И на второй итерации становяться видны многие огрехи первоначального решения. Причем они исправляются тут же, на лету.
Есть еще один фактор, который я не знаю к чему отнести. И вообще, многие не будут считать его достоинством. Когда пишешь на бумаге, то, естественно, нет никакого intelisence и autocomplite. Поэтому никто не подсказывает ни названий классов, ни названий методов, ни порядка аргументов. За всем этим нужно обращаться к документации. А это приводит к двум важным следствиям. Во-первых, проблемы несовместимости интерфейсов или недостатка информации для вызова какого-то метода выявляется тогда, когда еще не было введено ни одной строчки кода. На бумаге все так легко поправить, нужно только уметь пользоваться ластиком . Во-вторых, лучше узнаешь все, что используешь. И лучше ориентируешься в собственной программе, что позволяет существенно экономить на отладке.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, McSeem2, Вы писали:
IT>>>Дело не в методике, дело в здравом смысле, который очень часто бывает трудно найти в судьбоносных решениях наших коллег. Вот что действительно странно, так это то, что автору нравится работа ассенизатора. Это уже смахивает на извращеньице.
MS>>А так же противоречит первой заповеди программиста, "не навреди".
ГВ>Э... заповедь плохого программиста, однако.
Я бы сказал осторожного (читай опытного) программиста. Имхо, однако
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Уррраа! Новый холивар! Бумага VS редактор.
E> Привычка. Когда я начинал учиться программировать, машинного времени нам давали три пары на две недели (т.е. всего 6 часов). Естественно, что ничего путного в таких условиях при программировании прямо на машине не получалось. Вот и привык сначала всю программу на бумаге расписывать.
Это главный фактор.
E>Объективные (имхо): E> Навыки письма нам прививают в раннем детстве
Нк знаю кому как, а мне эти навыки так толком и не привили. А если учесть что я последние несколько лет к ручке почти не прикосаюсь(за исключанием какихто расчетов и диаграмок)то... E>и для нас они становятся чуть ли не безусловными рефлексами.
Для меня таже фигна с клавиатурой. Ну не замечаю я ее. И на шорткаты жму автоматическии.
E> Обозримость. На кране, даже с моим разрешением 1400x1050 я могу видеть только ограниченное количество строк всего нескольких файлов. Если же у меня есть решение на бумаге, причем, обязательно написанных только на одной строне листа, то я могу заложить листами весь письменный стол и легко переключаться с одного фрагмента кода на другой, держа при этом в поле зрения большое количество фрагментиков.
Лично для меня важнее скорость поиска. А в этом с контекстным поиском никакая бумага тягаться не может. Про инструменты типа ReSharper'а я вобще молчу.
E> Мобильность . Когда у меня часть кода написана на бумаге, я могу продолжить с ним работать даже не имея под рукой компьютера.
Ну не знаю. Както таких проблем не испытываю.
E> Работа над кодом проходит в две итерации.
А я сначало делаю прототип, а потом его мутирую в конечный код. Выбрасывая и переписывая все что не нравится. Причем во время переписывания инструменты типа ReSharper'а очень сильно помогают.
Также я все ключевые моменты заливаю в SVN и имею полную историю того что делал. Иногда экономит кучу времени если вдруг снес что-то лишнее.
E>Во-первых, проблемы несовместимости интерфейсов или недостатка информации для вызова какого-то метода выявляется тогда, когда еще не было введено ни одной строчки кода.
Сомнительно. Код всеравно надо набирать. А подрехтовать его в случае проблем не проблема. E>На бумаге все так легко поправить, нужно только уметь пользоваться ластиком . Во-вторых, лучше узнаешь все, что используешь. И лучше ориентируешься в собственной программе, что позволяет существенно экономить на отладке.
Еще болие сомнительно. Править в редакторе еще легче. Плюс мощная навигация. Плюс контекстная справка.
Кстати, а документация у тебя в каком виде? Электронном или ты весь MSDN распечатал?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, eao197, Вы писали:
WH>Уррраа! Новый холивар! Бумага VS редактор.
Это вряд ли, я просто разсказал как делаю я. У меня совершенно нет желания никому ничего по этому поводу доказывать (в отличии, скажем, от C++, объектных баз данных и моих велосипедов ).
E>> Работа над кодом проходит в две итерации. WH>А я сначало делаю прототип, а потом его мутирую в конечный код. Выбрасывая и переписывая все что не нравится. Причем во время переписывания инструменты типа ReSharper'а очень сильно помогают.
А вот мне нравится писать так, чтобы не выбрасывая. А на создание прототипов обычно времени нет
WH>Также я все ключевые моменты заливаю в SVN и имею полную историю того что делал. Иногда экономит кучу времени если вдруг снес что-то лишнее.
Сам SVN использую. Только это немного из другой области.
WH>Кстати, а документация у тебя в каком виде? Электронном или ты весь MSDN распечатал?
Вот документацию (MSDN, Unix man, Unix info, doxygen-generated) использую исключительно в электронном виде, т.к. тут действительно поиск и быстрая навигация с бумажными вариантами просто не сравнится.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Если нам не помогут, то мы тоже никого не пощадим.
, и должны проходить абсолютно по всем веткам исходников, т.е. в принципе должны быть написаны отталкиваясь от исходников.
* thriving in a production environment *
, не знаю, что точнее).
