Здравствуйте, McSeem2, Вы писали:

MS>А так же противоречит первой заповеди программиста, "не навреди".

Почитайте "Программистсткий камень":
ИМХО заповедь "не навреди" — самая вредная из заповедей
и вообще заповедь для программиста — вредная абстракция

OT>Почитайте "Программистсткий камень":
OT> ИМХО заповедь "не навреди" — самая вредная из заповедей
OT> и вообще заповедь для программиста — вредная абстракция

Заповедь у программиста ровно одна, но поскольку она малоцензурная,
я ее цитировать тут не буду.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, GlebZ, Вы писали:

GZ>>Рефакторинг ни в коем случае не должен затрагивать интерфейс.

IT>Не должен затрагивать внешний интерфейс. Теперь осталось только в данном контексте дать определение понятию "внешний"
С внешним то понятно, по крайней мере в компонентном аспекте. А вот что такое внутренний, и насколько он достоен этого звания — уже не очень понятно.

С уважением, Gleb.
PS: чем-то напоминает фильм "Дежавю". "Вот это синкопа? Нет это не синкопа. Вот синкопа!".

Здравствуйте, GlebZ, Вы писали:

GZ>Рефакторинг ни в коем случае не должен затрагивать интерфейс. Это просто улучшение кода при той же функциональности. Правда у каждого нормального программиста есть свои понятия на код с запашком. Поэтому рефакторинг — процесс практически вечный и зависит только от количества программистов.

Рискну возразить. Правда, учитывая некоторую свою специфику, которая заключается вот в чем. Мне платят деньги не за программный код и даже не за функциональность (точнее сказать не просто за функциональность). Мне платят деньги за нетривиальные и эффективные решения, алгоритмические, инженерные и дизайнерские. На том и стоим. И вот с этой моей позиции, так называмое "просто улучшение кода при той же функциональности" является абсурдом. Если требуется улучшать код, значит я схалтурил раньше. Мне крайне неприятно возвращаться к халтурному коду, поэтому я стараюсь халтурить как можно меньше. Так получается дешевле. Конечно же, на стадии экспериментов с алгоримом я пробую всякие-разные промежуточные решения, в том числе и простейшие и заведомо неэффективные. Но эти промежуточные решения никогда не доходят до стадии релиза.
Бывают случаи, когда действительно имеет смысл заменить начинку на более эффективную, но они крайне редки. Ну, типа сообразил, как можно сделать слегка эффективнее.

А вот с интерфейсами, что внешними, что внутренними, все гораздо сложнее. Очень часто по началу весь дизайн является неочевидным, выясняется по ходу работы. Соответственно, приходится вносить изменения и улучшения. Я никогда не поверю в то, что все можно решить и узаконить на стадии проектирования. Не бывает такого, не только в программировании, но и вообще в любой инженерной деятельности. Конечно же, за исключением типовых решений (шаблонов проектирования) — там это возможно. Но во-первых, типовые решения актуальны как правило лишь для тривиальных задач, во-вторых, такие задачи и решения мне не интересны.

Резюмируя, могу сказать следующее. Писать код, который практически не требует улучшений, на порядок проще, чем дизайнить грамотные интерфейсы (внешние, внутренние — не важно). И если приходится существенно (и главное — постоянно) улучшать существующий код, значит что-то не ладно в датском королевстве.

То есть, я не приемлю подход, при котором надо по-быстрому напедалить абы-как, а потом долго и нудно улучшать и переписывать.

- Неладно шьешь, донюшка!
— Я еще пороть буду, матушка!

Здравствуйте, McSeem2, Вы писали:

MS>Рискну возразить. Правда, учитывая некоторую свою специфику, которая заключается вот в чем. Мне платят деньги не за программный код и даже не за функциональность (точнее сказать не просто за функциональность). Мне платят деньги за нетривиальные и эффективные решения, алгоритмические, инженерные и дизайнерские. На том и стоим. И вот с этой моей позиции, так называмое "просто улучшение кода при той же функциональности" является абсурдом. Если требуется улучшать код, значит я схалтурил раньше. Мне крайне неприятно возвращаться к халтурному коду, поэтому я стараюсь халтурить как можно меньше. Так получается дешевле. Конечно же, на стадии экспериментов с алгоримом я пробую всякие-разные промежуточные решения, в том числе и простейшие и заведомо неэффективные. Но эти промежуточные решения никогда не доходят до стадии релиза.
Везука!!!! А я вот, не особо могу. То ли не так делали, то ли ударился в детсве. В процессе построения решения практически всегда существуют некоторые неправильные решения, о которых начинаешь догадываться только потом, в процессе реализации, или даже после. Сказать что я с первого раза пишу оптимальный код, к сожалению не могу. Иногда в процессе работы, переписываю некоторые куски на которые через некоторое время взглянул с другой стороны. Иногда делаю сначало примерно, чтобы работало, а потом рефакторю чтобы эффективно работало и расширялось. Особенно если это касается как раз, для более менее нетривиальных алгоритмов которые реализуешь в первый раз. Они просто в голове и на бумаге не умещаются.
MS>Бывают случаи, когда действительно имеет смысл заменить начинку на более эффективную, но они крайне редки. Ну, типа сообразил, как можно сделать слегка эффективнее.
Это вопрос времени и денег. Которых всегда не хватает.

MS>А вот с интерфейсами, что внешними, что внутренними, все гораздо сложнее. Очень часто по началу весь дизайн является неочевидным, выясняется по ходу работы. Соответственно, приходится вносить изменения и улучшения. Я никогда не поверю в то, что все можно решить и узаконить на стадии проектирования. Не бывает такого, не только в программировании, но и вообще в любой инженерной деятельности. Конечно же, за исключением типовых решений (шаблонов проектирования) — там это возможно. Но во-первых, типовые решения актуальны как правило лишь для тривиальных задач, во-вторых, такие задачи и решения мне не интересны.
На любой итерации для компонента (который конечно может быть библиотекой) выделяю интерфейс. Даже если этим компонентом буду работать только я и он не входит ни в какую официальную документацию. Именно эта вещь максимально продумывается чтобы не было изменений(насчет изменений это конечно сказка, но максимально уменьшаю вероятность и количество будующих изменений). По возможности пишу unit-тесты под этот интерфейс. Это также помогает его продумать. Ну а дальше, если задача сложная, то я пишу как придется. Главное чтобы работало. Многое действительно получается сразу оптимально(опыт все таки сказывается), ну а многое через пень-колоду. Ну а дальше, уже решаю, может ли кто-то кроме меня достигнуть того-же уровня просветления как и я, и сможет понять всю гениальность моего замысла. В процентах 30 — сразу отвечу что нет. Тогда и начинается рефакторинг. И кстати, в этом процессе появляются мысли о которых я почему-то не домыслил до этого и исправляются тараканы которых и в лупу не заметишь.
(Блин, какой-то ХП получилось. Хотя к его апологетам себя не отношу).

Как, наверно, ты уже заметил, что внутренние интерфейсы я за интерфейсы не считаю. Однажды дошло до смешного, посмотрел две версии файла, тот который делал четыре года назад, и тот который работал в данное время. Практически кроме интерфейса(который был только дополнен), ничего общего не осталось.

MS>Резюмируя, могу сказать следующее. Писать код, который практически не требует улучшений, на порядок проще, чем дизайнить грамотные интерфейсы (внешние, внутренние — не важно).
Кому как. Мне например наоборот. Но это еще вопрос относительности, смотря что имеется ввиду под дизайнить грамотные интерфейсы.
MS>И если приходится существенно (и главное — постоянно) улучшать существующий код, значит что-то не ладно в датском королевстве.

MS>То есть, я не приемлю подход, при котором надо по-быстрому напедалить абы-как, а потом долго и нудно улучшать и переписывать.
Я бы рад бы, да вот не получается. Я неумный?

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

MS>>То есть, я не приемлю подход, при котором надо по-быстрому напедалить абы-как, а потом долго и нудно улучшать и переписывать.
GZ>Я бы рад бы, да вот не получается. Я неумный?

Здесь дело в другом. Не знаю, как сформулировать получше. В общем, дело в изначальном внутреннем стремлении и складе характера. "Умность" здесь — фактор ортогональный. Мне, например, противопоказано работать в проектах с жесткими сроками и планами-графиками. Разумеется, время от времени приходится участвовать именно в таких проектах. Но я стремлюсь минимизировать это дело и максимизировать количество степеней свободы для творчества. Ну и соответствующим образом выбираю себе места работы. Но это не самый легкий путь к успеху. И иногда чреват боком

Здравствуйте, McSeem2, Вы писали:

MS>Здесь дело в другом. Не знаю, как сформулировать получше. В общем, дело в изначальном внутреннем стремлении и складе характера. "Умность" здесь — фактор ортогональный.
Да уж.
MS>Мне, например, противопоказано работать в проектах с жесткими сроками и планами-графиками. Разумеется, время от времени приходится участвовать именно в таких проектах. Но я стремлюсь минимизировать это дело и максимизировать количество степеней свободы для творчества. Ну и соответствующим образом выбираю себе места работы.
У меня другая напасть. Творчество на меня само нападает. (ну а если не я, то кто-же). В любом проекте (если конечно процесс разработки не довели до высшей степени маразма который описан только в книжках) голова на первом месте. А выполнить это в срок ( и главное определить этот срок) вот это уже искуство.

Теперь по теме разговора. Для меня рефакторить чужой код на порядок легче чем писать свой. Достаточно тупая работа. Алгоритмы уже заложены. Выдумывать ничего не надо. Просто подводишь код к тем шаблонам которые сам используешь. И все... Скукотища, которая просто использует твой предыдущий опыт. То ли дело навернуть алгебру моноидов

С уважением, Gleb.

Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, GlebZ, Вы писали:

GZ>>Рефакторинг ни в коем случае не должен затрагивать интерфейс. Это просто улучшение кода при той же функциональности. Правда у каждого нормального программиста есть свои понятия на код с запашком. Поэтому рефакторинг — процесс практически вечный и зависит только от количества программистов.

MS>Рискну возразить. Правда, учитывая некоторую свою специфику, которая заключается вот в чем. Мне платят деньги не за программный код и даже не за функциональность (точнее сказать не просто за функциональность). Мне платят деньги за нетривиальные и эффективные решения, алгоритмические, инженерные и дизайнерские. На том и стоим.
+1

Завидую белой завистью. Сам мечтаю так работать, только что-то все не сладывается (или , не знаю, что точнее).

MS> И вот с этой моей позиции, так называмое "просто улучшение кода при той же функциональности" является абсурдом. Если требуется улучшать код, значит я схалтурил раньше. Мне крайне неприятно возвращаться к халтурному коду, поэтому я стараюсь халтурить как можно меньше. Так получается дешевле. Конечно же, на стадии экспериментов с алгоримом я пробую всякие-разные промежуточные решения, в том числе и простейшие и заведомо неэффективные. Но эти промежуточные решения никогда не доходят до стадии релиза.
MS>Бывают случаи, когда действительно имеет смысл заменить начинку на более эффективную, но они крайне редки. Ну, типа сообразил, как можно сделать слегка эффективнее.

Кроме понятия эффективности, про которую ты уже написал, есть еще и другие факторы, которые могут привести к рефакторингу. Вот, скажем, с чем я сталкиваюсь: создается какой-то вспомогательный инструмент (какая-нибудь библиотека), который используется в решении реальной задачи. Через какое-то время этот инструмент устаревает, его развитие прекращается и выпускается его новый аналог (либо сильно обновленная версия), уже не совместимый со старым инструментом. Если уже созданное решение требуется сопровождать и развивать, то наступает момент, когда проще перевести старый код на использование нового инструмента. Это напоминает историю с программированием под Windows -- сначала самописные классы, затем MFC, затем WTL. Функциональность продукта вроде не меняется, а начинка -- в значительной степени. И нужно это для того, чтобы получить возможность изменить функциональность в последствии.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, McSeem2, Вы писали:

GZ>Везука!!!! А я вот, не особо могу. То ли не так делали, то ли ударился в детсве. В процессе построения решения практически всегда существуют некоторые неправильные решения, о которых начинаешь догадываться только потом, в процессе реализации, или даже после. Сказать что я с первого раза пишу оптимальный код, к сожалению не могу. Иногда в процессе работы, переписываю некоторые куски на которые через некоторое время взглянул с другой стороны. Иногда делаю сначало примерно, чтобы работало, а потом рефакторю чтобы эффективно работало и расширялось. Особенно если это касается как раз, для более менее нетривиальных алгоритмов которые реализуешь в первый раз. Они просто в голове и на бумаге не умещаются.

У меня такая же история. Только я обязательно первую реализацию сложного алгоритма делаю именно на бумаге. Бывает, что уже на бумаге готовый результат получается только с третьей-четвертой попытки. А затем переписываю на компьютер, причем стараюсь делать это на свежую голову или хотя бы через пару часов после написания кода на бумаге -- сразу видны ошибки и промахи. Хотя не все. Бывает, что при "вылизывании" быстродействия/ресурсоемкости приходится что-то переделывать.

Здравствуйте, eao197, Вы писали:

E>У меня такая же история. Только я обязательно первую реализацию сложного алгоритма делаю именно на бумаге. Бывает, что уже на бумаге готовый результат получается только с третьей-четвертой попытки. А затем переписываю на компьютер, причем стараюсь делать это на свежую голову или хотя бы через пару часов после написания кода на бумаге -- сразу видны ошибки и промахи. Хотя не все. Бывает, что при "вылизывании" быстродействия/ресурсоемкости приходится что-то переделывать.

Чисто любопытно. А что мешает использовать редактор заместо бумаги для написания кода? Чисто привычка? Но ведь на бумаге писать код гораздо более трудоемко! Лично я использую бумагу и ручку для формул, геометрических построений, диаграмм и т.д. Что ни говори, но никакой графический редактор не сравнится по эффективности с бумажным листом А вот текстовый — вполне.
Блок-схемы алгоритмов канули в лету вместе с GOTO. А выписывать на бумаге строчки кода — как-то оно очень трудоемко. Я предпочитаю редактор и компилятор . При этом у меня только около 10-20% написанного кода идет в production, остальное в конечном итоге — в мусорку.

Здравствуйте, eao197, Вы писали:

MS>>Рискну возразить. Правда, учитывая некоторую свою специфику, которая заключается вот в чем. Мне платят деньги не за программный код и даже не за функциональность (точнее сказать не просто за функциональность). Мне платят деньги за нетривиальные и эффективные решения, алгоритмические, инженерные и дизайнерские. На том и стоим.
E>+1

E>Завидую белой завистью. Сам мечтаю так работать, только что-то все не сладывается (или , не знаю, что точнее).

Ну как я уже сказал, этот путь не самый прямой и простой. И на самом деле, я конечно же слегка приукрасил свою сегодняшнюю ситуацию, но в общем и целом, незначительно.

E>Кроме понятия эффективности, про которую ты уже написал, есть еще и другие факторы, которые могут привести к рефакторингу. Вот, скажем, с чем я сталкиваюсь: создается какой-то вспомогательный инструмент (какая-нибудь библиотека), который используется в решении реальной задачи. Через какое-то время этот инструмент устаревает, его развитие прекращается и выпускается его новый аналог (либо сильно обновленная версия), уже не совместимый со старым инструментом. Если уже созданное решение требуется сопровождать и развивать, то наступает момент, когда проще перевести старый код на использование нового инструмента. Это напоминает историю с программированием под Windows -- сначала самописные классы, затем MFC, затем WTL. Функциональность продукта вроде не меняется, а начинка -- в значительной степени. И нужно это для того, чтобы получить возможность изменить функциональность в последствии.

Да, конечно. Именно поэтому я ненавижу программировать GUI и предпочитаю "ваять нетлеку" (это такой само-сарказм).
Но это бывает чревато. Например, тем, что на интервью я буду выглядеть весьма бледно по сравнению с людьми, съевшими собаку на MFC/COM/WTL/.Net/etc. Но мне не хочется тратить жизнь на освоение API, которые заведомо обречены на вымирание (не потому что они плохи, а потому что будет что-то новое). Но повторюсь еще раз, в моем подходе весьма велик фактор риска.

Здравствуйте, McSeem2, Вы писали:

IT>>Дело не в методике, дело в здравом смысле, который очень часто бывает трудно найти в судьбоносных решениях наших коллег. Вот что действительно странно, так это то, что автору нравится работа ассенизатора. Это уже смахивает на извращеньице.

MS>А так же противоречит первой заповеди программиста, "не навреди".

Э... заповедь плохого программиста, однако.

Здравствуйте, IT, Вы писали:

V>>Лично я сталкивался в своей практике со многими методиками. Все они, как и фармацевтические препараты, имеют свои фармакологические свойства, показания к применению, противопоказания, побочные действия и т.д.
IT>Дело не в методике, дело в здравом смысле, который очень часто бывает трудно найти в судьбоносных решениях наших коллег. Вот что действительно странно, так это то, что автору нравится работа ассенизатора. Это уже смахивает на извращеньице.

Да не, нормальное следствие "эстетического" подхода к разработке программы. Типа такого: "Не знаю точно что, но что-то мне здесь не нравится. Сильно не нравится. Ergo — надо переписать."

Здравствуйте, Voblin, Вы писали:

V>По-видимому, речь идёт о каком-то очередном "лекарстве от всех болезней". Но при этом упорно не говорится, какое именно. Совет "Будем делать хорошо и не будем плохо" — хороший, но совершенно бесполезный.

Прально. Гораздо лучше совет: "Всегда делать настолько хорошо, насколько можем." Просто товарисч пытается описать применение мозгов в разработке ПО.

V>Лично я сталкивался в своей практике со многими методиками. Все они, как и фармацевтические препараты, имеют свои фармакологические свойства, показания к применению, противопоказания, побочные действия и т.д. Так что, осторожней, господа, с сильнодействующими средствами!

Не переживай. У многих с этим средством большой напряг. А у кого не напряг, у тех, как правило, всё получается.

Здравствуйте, McSeem2, Вы писали:

MS>>>То есть, я не приемлю подход, при котором надо по-быстрому напедалить абы-как, а потом долго и нудно улучшать и переписывать.
GZ>>Я бы рад бы, да вот не получается. Я неумный?
MS>Здесь дело в другом. Не знаю, как сформулировать получше. В общем, дело в изначальном внутреннем стремлении и складе характера. "Умность" здесь — фактор ортогональный.

Ну, во всяком случае, "умность" немало помогает в борьбе с менеджментом. Кстати, забавно, но как правило контраргументы умных (в смысле — начитанных, грамотных и т.п., но без э... назовём это "унутренним стержнем", если хочешь — нефритовым ) сводятся к двум постулатам: а) всё равно всё переделывать когда-нибудь, а потому нафига париться? и б) где мы потом найдём таких же умников, так что, валяй давай, как попроще.

MS>Мне, например, противопоказано работать в проектах с жесткими сроками и планами-графиками. Разумеется, время от времени приходится участвовать именно в таких проектах. Но я стремлюсь минимизировать это дело и максимизировать количество степеней свободы для творчества. Ну и соответствующим образом выбираю себе места работы. Но это не самый легкий путь к успеху.


MS>И иногда чреват боком
Ну дык, многим в кайф "давить" такую позицию, как у тебя. Это вообще пунктик в наше время: "Хрен здесь думать? Беги!"

Здравствуйте, IT, Вы писали:

GZ>>Рефакторинг ни в коем случае не должен затрагивать интерфейс.
IT>Не должен затрагивать внешний интерфейс. Теперь осталось только в данном контексте дать определение понятию "внешний"

А что тут определять? Если интерфейс выставлен для использования кому-то кроме нас самих (команды, компании и т.п.) — он внешний, иначе — внутренний.

Здравствуйте, eao197, Вы писали:

E>Если уже созданное решение требуется сопровождать и развивать, то наступает момент, когда проще перевести старый код на использование нового инструмента. Это напоминает историю с программированием под Windows -- сначала самописные классы, затем MFC, затем WTL. Функциональность продукта вроде не меняется, а начинка -- в значительной степени.

Можнет это называется портированием?

Здравствуйте, McSeem2, Вы писали:

MS>Если требуется улучшать код, значит я схалтурил раньше.

Это справедливо только если ты точно, на все сто понимаешь требования к задаче, которые никогда не изменятся.

MS>А вот с интерфейсами, что внешними, что внутренними, все гораздо сложнее. Очень часто по началу весь дизайн является неочевидным, выясняется по ходу работы. Соответственно, приходится вносить изменения и улучшения. Я никогда не поверю в то, что все можно решить и узаконить на стадии проектирования.

Вот это гораздо ближе к телу. И тот же рефакторинг казалось бы вполне нормального и удачного кода — это обычное дело, если проходится готовить его к новой функциональности, которая ранее не планировалась.

Здравствуйте, Геннадий Васильев, Вы писали:

IT>>Не должен затрагивать внешний интерфейс. Теперь осталось только в данном контексте дать определение понятию "внешний"

ГВ>А что тут определять? Если интерфейс выставлен для использования кому-то кроме нас самих (команды, компании и т.п.) — он внешний, иначе — внутренний.

А вот и не угадал Я скорее имею ввиду внешние границы рефакторинга, чем системы в целом.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Да не, нормальное следствие "эстетического" подхода к разработке программы.

Это не нормально. Просто все мы привыкли считать чужой код дерьмом. Ну что поделать? Через неделю работы любой нормальный русский программист уже считает себя экстраординари личностью, после первого же архитектурного решения — Наполеоном Бонапартом. Правильный код только мой, остальное всё дерьмо! Вполне естественно, что в таких условиях можно сделать только карьеру ассенизатора. Это — неправильно! Потом всю жизнь приходится по капле выдавливать из себя экстраординарность, наполеонов и ассенизаторов.