Программистские книжки
Dec. 28th, 2008 08:51 pmЧитаю по наводке
object уже третью книгу подряд. Вот они в порядке прочтения:
1. Agile software development
2. Test driven development by example
3. Refactoring (это та, которую сейчас читаю)
Мне, такому всему из себя "матерому зубру", должно быть немного неловко, но эти книги были для меня настоящим eye opener-ом. В отличие от традиционных книг по программированию, которые либо описывают конкретную технологию, либо говорят о дизайне в идеальном мире (см., скажем, Буч либо гэнг оф фор), эти книги говорят о том, как решать проблемы, с которыми большинство программистов вынуждены сталкиваться на практике в течении 90% своей профессиональной деятельности (время, потраченное на заседания, перекуры и тренинги - не в счет). Например - как быть, когда приходится иметь дело с кодом, написанным годы назад неизвестно кем, а потом поддерживающимся еще кучей народу, мало кто из которых до конца понимал, как работает код, который он изменяет. Как вести себя в условиях постоянно меняющихся требований, в условиях, когда эти новые требования тянут код в направлении, о котором не думали при певоначальном дизайне. И так далее. Очень рекомендую всем, кто еще не (и кто не дошел до всего своим умом).
1. Agile software development
2. Test driven development by example
3. Refactoring (это та, которую сейчас читаю)
Мне, такому всему из себя "матерому зубру", должно быть немного неловко, но эти книги были для меня настоящим eye opener-ом. В отличие от традиционных книг по программированию, которые либо описывают конкретную технологию, либо говорят о дизайне в идеальном мире (см., скажем, Буч либо гэнг оф фор), эти книги говорят о том, как решать проблемы, с которыми большинство программистов вынуждены сталкиваться на практике в течении 90% своей профессиональной деятельности (время, потраченное на заседания, перекуры и тренинги - не в счет). Например - как быть, когда приходится иметь дело с кодом, написанным годы назад неизвестно кем, а потом поддерживающимся еще кучей народу, мало кто из которых до конца понимал, как работает код, который он изменяет. Как вести себя в условиях постоянно меняющихся требований, в условиях, когда эти новые требования тянут код в направлении, о котором не думали при певоначальном дизайне. И так далее. Очень рекомендую всем, кто еще не (и кто не дошел до всего своим умом).
no subject
on 2008-12-28 07:09 pm (UTC)Рыдать?
no subject
on 2008-12-28 07:10 pm (UTC)Змеиное масло
on 2008-12-28 07:18 pm (UTC)Re: Змеиное масло
on 2008-12-28 07:20 pm (UTC)Re: Змеиное масло
Posted byRe: Змеиное масло
Posted byНе сисадмины, не айтишники мы
Posted byRe: Не сисадмины, не айтишники мы
Posted byDuck and cover
Posted byRe: Duck and cover
Posted byRe: Duck and cover
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted byRe: Змеиное масло
Posted byno subject
on 2008-12-28 08:54 pm (UTC)Однажды мне пришлось добавлять некий замысловатый фичер в систему, после тщательного изучения системы мне удалось добавить сотню-другую строчек кода и стереть полторы тысячи без потери предыдущей функциональности. Так что рефакторинг изучал на практике. В упомянутой книжке открытий для себя не нашел, но книжка и впрямь славная.
no subject
on 2008-12-28 07:24 pm (UTC)no subject
on 2008-12-28 08:21 pm (UTC)TDD хорош именно для рефакторинга. Насколько он хорош для кода, который пишется с нуля - я пока не поняла. Если у тебя будут какие-то соображения, я бы их с удовольствием послушала. Вообще тема интересная.
Хотя, как и во всех таких делах, здравый смысл - условие хоть и недостаточное, но необходимое для хоть сколько-нибудь осмысленного применения любой системы. Вон ООР вроде тоже неплохая штука - а сколько народу на ней погорела.
no subject
on 2008-12-28 08:22 pm (UTC)Очень хорош. Причем TDD в чистом виде только для нового кода и применим :).
no subject
on 2008-12-28 08:28 pm (UTC)no subject
on 2008-12-28 08:30 pm (UTC)(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted byno subject
on 2008-12-28 08:29 pm (UTC)no subject
on 2008-12-28 08:35 pm (UTC)no subject
on 2008-12-29 11:05 am (UTC)no subject
on 2009-01-25 11:24 am (UTC)Тахлис - не может работать Scrum при разработке GUI, потому что каждый этап растягивается втрое.
no subject
on 2009-01-25 07:00 pm (UTC)А почему каждый этап растягивается втрое?
Тут есть пространный обзор этого мероприятия. Там третий комментарий - от человека, который довольно много занимался разработкой UI в разных проектах Agile.
(no subject)
Posted byВагиф - это голова!
on 2008-12-28 09:21 pm (UTC)Это был
on 2008-12-28 10:01 pm (UTC)no subject
on 2008-12-28 09:59 pm (UTC)no subject
on 2008-12-28 10:00 pm (UTC)no subject
on 2008-12-28 10:13 pm (UTC)(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted by(no subject)
Posted byno subject
on 2009-01-03 02:36 pm (UTC)Но очень интересует твое мнение: стоит ли писать в резюме о том, что среди всего прочего есть опыт с рефакторингом.
Я уверена, конечно, что это важная вещь, и актуальная, в свете взросления отрасли.. Но грызут сомнения, что это выглядит достаточно внушительно при описании своего опыта.
no subject
on 2009-01-03 11:09 pm (UTC)no subject
on 2009-01-25 11:25 am (UTC)no subject
on 2009-01-25 05:17 pm (UTC)no subject
on 2009-01-26 08:49 am (UTC)