Сообщений 5 
Оценка 29 
Оценить 
| Сообщений 5 Оценка 29 Оценить
|
Находясь на переднем крае программирования, книга «Программист-прагматик» абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса — требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы — от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.
Прочитав эту книгу, вы научитесь:
Есть книги, которые учат нас определенным аспектам нашей профессии. Одни говорят о какой-то конкретной технологии или языке программирования, который может стать не актуальным в тот момент, когда вы ее принесли из книжного магазина. Другие учат нас, своим методологиям, говорят, что они самые лучшие, приводя примеры, которые обязательно подтверждают правоту их слов. Третьи знакомят нас с операционными системами, их преимуществами и недостатками. Четвертые рассказывают о модных системах управлениях базами данных и правильными способами их применения.
Все это просто чудесно. Каждая из этих книг оставляет след в нашей душе. Одни забываются после того, как мы их дочитываем, другие мы бросаем, не дочитав и половины, третьи продолжают вспоминаться спустя долгие годы. Все это делает нас сильнее, увереннее, мы строим все новые и новые системы, решаем все более и более сложные задачи.
Но очень часто нам не хватает «клея», который склеил бы все наши знания и позволил бы перейти на новый уровень. Ведь развитие человека, как и многое в этом мире идет по спирали, является итеративным и поступательным процессом. И эта одна из немногих книг, которая позволит подняться на несколько уровней вверх и двигаться по этой спирали в более быстром темпе.
Основной лозунг книги – никогда не останавливайтесь в своем развитии. Если вы знакомы с одним языком программирования и чувствуете, что дальнейшее изучение в рамках текущего проекта просто невозможно, начните изучать другой язык. И пусть он вам никогда не пригодится, но эти знания никогда не будут лишними. Вот что говорит в одном из своих интервью Бьерн Страуструп по этому поводу:
«Мне кажется, что языки, используемые нами для выражения своих идей, становятся частью нас самих, поэтому, если вы знаете только один язык, может показаться, будто сторонники других языков представляют опасность лично для вас. Мне представляется, что выход из этой ситуации – освоение других языков. Сомневаюсь, что можно быть профессионалом в области ПО и знать лишь один язык программирования. Может быть и экономическая причина: фундаментальные знания выходят за границы языка программирования в отличие от многих практических навыков. Поэтому, если я знаю только язык X и его наборы инструментов, а вы являетесь сторонником языка Y и его наборов инструментов, вы представляете угрозу для источника моего заработка. И вновь решение, как мне кажется, - в знании нескольких языков и наборов инструментов (а также твердое понимание фундаментальных концепций)».
Той же точки зрения придерживаются и авторы этой книги, но несколько в более широком контексте. Ведь наш «набор инструментов» не ограничивается лишь языками программирования.
«К сожалению, знания и опыт представляют собой истекающие активы. Ваше знание устаревает по мере того, как разрабатываются новые методики, языки, технологии и операционные среды. Изменение расстановки сил на рынке может сделать ваш опыт устаревшим или полностью неприменимым. Принимая во внимание скорость, с которой промчались годы Интернета, это может произойти довольно быстро».
Единственный выход из сложившейся ситуации – инвестирование в собственный "портфель знаний" на регулярной основе.
Многие авторы поднимают проблему модульности и связанности. Авторы этой книги не исключение. Но они используют несколько непривычный термин «ортогональность».
«Термин "ортогональность" заимствован из геометрии. Две линии являются ортогональными, если они пересекаются под прямым углом, например оси координат на графике… Этот термин был введен в информатике для обозначения некой разновидности независимости или несвязанности. Два или более объекта ортогональны, если изменения, вносимые в один из них, не влияют на любой другой».
Не было ли у вас случая, когда вы за месяц до завершения проекта понимаете, что DCOM для построения клиент-серверной архитектуры не подходит? И нужно искать альтернативные решения… Я был в такой ситуации, и только ортогональность системы позволили перейти на .Net Remoting за неделю и не сорвать сроки.
Ситуация, в которой оказалось моя команда не отличается оригинальностью. Такое происходит сплошь и рядом, и дело не только в опыте (которого в моем случае явно не доставало), но и в том, что принятие "окончательного решения" - дело рискованное. Основные принципы объектно-ориентированного проектирования, итеративный процесс разработки, модульность и многое другое направлено на то, чтобы отложить на более поздний срок принятие многих решений. На самом деле, эту проблему можно рассматривать несколько шире, не только в контексте некоторого проектного решения, но и в контексте взглядов человека на окружающий мир вообще и процесс разработки программного обеспечения в частности.
Крис Дейт в предисловии к своей замечательной книге "Введение в системы баз данных" приводит следующую выдержку Бертрана Рассела:
«Меня обвиняли в привычке менять свои суждения… Но разве мог бы физик, работающий с 1900 года, например, похвастаться в середине двадцатого века тем, что его суждения не изменились за последние полстолетия?... Та философия, которую я ценю и которой стараюсь следовать, научна в том смысле, что мы должны всегда стремиться получить неопровержимые знания, но новые открытия могут выявить прежние ошибки, неизбежные для любого беспристрастного разума. Когда бы и что бы я ни говорил, сейчас или в прошлом, я никогда не утверждал, что это – окончательная истина. Я утверждаю лишь то, что в свое время высказанное мной мнение было вполне обоснованным… Я был бы очень удивлен, если бы дальнейшие исследования не показали, что его необходимо пересмотреть. К тому же я никогда не высказывал свое мнение как окончательный вердикт, а просто подчеркивал, что это – лучшее, что я мог сделать в то время для достижения ясного и точного понимания. Моей целью было, прежде всего, полная ясность во всем».
Поэтому никогда не стесняйтесь признаваться (и прежде всего себе) в том, что вы совершили ошибку. Быть может это и не ошибка вовсе, может быть в тех условиях, с тем опытом и знаниями – это был единственно правильный выход?
А разве не были вы в такой ситуации, когда менеджер проекта, представитель заказчика или кто-то из руководства подходит к вам и спрашивает: "Сколько тебе нужно времени, на завершение того-то и того-то?" И как часто вы отвечали: "Неделя" или "Три дня", когда совершенно точно понимали, что вы совершенно не понимали (простите за каламбур), что от вас требуется?
Авторы советуют говорить: "Я вернусь к вам с этим позже".
"Вы почти всегда сможете добиться лучших результатов, если не будете торопиться и потратите некоторое время, чтобы пройтись по всем стадиям, описанным в этой книге. К оценкам, сделанным на ходу (например, у офисной кофеварки), придется возвращаться вновь и вновь "как, впрочем, и к кофе", теряя при этом покой".
А что вы думаете по поводу требований? Может быть, ваши требования нужно было "добывать в карьере"? А может, быть вы столкнулись с проблемой чрезмерной спецификации? Может быть, вы сталкивались с документами, которые занимали десятки страниц, в которых было определено, сколько "битиков" должно быть отведено на тот или иной параметр, в которых выдумывалась собственная терминология, полностью противоречащая предметной области? Когда за всем за этим просто невозможно разглядеть семантику… что же должна делать система в конечном итоге? К сожалению, не все стремятся постоянно пополнять свой багаж знаний…
Полезных советов в книге много. Если я буду продолжать описывать все, что произвело на меня впечатление в том же духе, описание само потянет на небольшую книгу.
Многое из того, что описывают авторы интуитивно понятные каждому из нас, многое способно изменить нашу точку зрения на какой-то аспект разработки программного обеспечения. Авторы не предлагают "серебряных пуль" и никто не гарантирует, что путь от подмастерья к мастеру может быть простым. Нет, это не так…
Главное, что хотят авторы, это то, "чтобы вы гордились правом собственности. "Я это написал, и я стою за своей работой". Ваша подпись должна стать признанным знаком качества. Люди должны увидеть ваше имя в заголовке программы и рассчитывать на то, что она будет солидной, хорошо составленной, проверенной и документированной. Это должна быть поистине профессиональная работа. Написанная настоящим профессионалом своего дела.
Программистом-прагматиком".
| Сообщений 5 Оценка 29 Оценить
|