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

[dimrub]

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

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

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

Comments

[alexcohn.livejournal.com]

Посетил я это собрание, вышел оттуда разочарованным. В качестве курьеза, как можно рассказывать про технологии "сделать всё быстро и по расписанию", медленно пережевывая очевидное с бессмысленным, и затянув лекцию на час против заявленного времени?

Тахлис - не может работать Scrum при разработке GUI, потому что каждый этап растягивается втрое.

[white-lee.livejournal.com]

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

А почему каждый этап растягивается втрое?

Тут есть пространный обзор этого мероприятия. Там третий комментарий - от человека, который довольно много занимался разработкой UI в разных проектах Agile.

[alexcohn.livejournal.com]

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

Втрое спринт растягивается потому, что разработчики, в описанной Талем компромиссной модели, ждут для своего спринта результатов спринта дизайнеров, а usability testing результата разработки попадает в sprint backlog дизайнеров только на следующей итерации. Если учесть длинный - три-четыре недели вариант спринта, про который рассказывал Таль, эти задержки и согласования сводят, по-моему, смысл Agile к минимуму.

Дискуссия по ссылке действительно толковая. Я, как и Асаф, рассчитывал услышать не про Agile Manifesto плюс неубедительные заходы в сторону разделения ролей разработчиков и дизайнеров, а что-то про концепции UI дизайна, позволяющие вписать его в Agile процесс. Жаль, что у Таля таковых не нашлось.