Программистские книжки

[dimrub]

Читаю по наводке object уже третью книгу подряд. Вот они в порядке прочтения:

1. Agile software development
2. Test driven development by example
3. Refactoring (это та, которую сейчас читаю)

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

Comments

[avva.livejournal.com]

А какие бывают виды? Я представляю себе один вид:

1. Это написано черед задницу.
2. (напряженная работа мысли)
3. Это должно быть написано вот так!
4. Меняем.

[dimrub.livejournal.com]

Интересный подход :). Увы, я так не умею. Я начинаю думать: ну вот этот код должен быть в отдельной функции. А вот тот и этот, наоборот, вызывать одну и ту же функцию, которой должны делегировать всю свою логику. А вот тут вместо здоровенного свича должен быть полиморфизм. А вот там вместо полиморфизма - стейт машин. И так далее. Но если я это делаю сам, я, во-первых, делаю все вместе, и получается каша (это еще полбеды, идея о том, чтобы делать не все сразу, а по шагам, каждый раз прогоняя тесты даже мне в голову приходила). Во-вторых, что-нибудь при этом да забуду. А они позволяют всю эту головную боль из головы изъять. Так я это понимаю, я еще только в начале этой книги.

[dumalkin.livejournal.com]

А у меня это работает на уровне эстетического чувства.
Вот вижу код, и вижу что "кривой". Почему - если начать думать то можно и отыскать логические доводы, но проще не объясняя переписать так, чтобы стало "красиво".
Причем часто вижу код который в жизни бы "так" не написал, но ощущения что "криво" нет - просто не мой стиль.

У нас один есть - любитель ООП в извращенной форме. В одном модуле он использовал 3 вида базовых классов - template, prototype & base (в смысле этими словами оканчивались названия базовых классов).
Я его попросил объяснить разницу (чем ВеникTemplate концептуально отличается от МетелкиPrototype), ее никто не понял. В итоге я его уговорил писать по принципу KISS, и вся красота была поругана - остался один вид, который ради умиротворения я ему дал назвать template (дав в качестве домашнего задания разобраться чем С++ template отличается от generics, и как они живут вместе в managed c++.)

[avnik.livejournal.com]

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

[avva.livejournal.com]

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