Аннотация:
В статье приведен перечень книг, по праву считающихся классикой компьютерной литературы в самых различных областях разработки программного обеспечения
СТ>Авторы: СТ> Сергей Тепляков
СТ>Аннотация: СТ>В статье приведен перечень книг, по праву считающихся классикой компьютерной литературы в самых различных областях разработки программного обеспечения
"Книга стала родоначальником столь популярного ныне принципа постепенного улучшения кода без изменения функциональности".
Родоначальником?
Или дал название тому, чем занимались программисты и ранее?
Когда несколько лет назад я впервые увидел аннотацию этой книги, сразу подумал — вот и название для того "улучшения программ", которым я и занимался частенько, называя это занятие "улучшением [текста] программы".
Думаю, многие программисты занимались этим тоже. А Фаулер — дал название.
Вот только я привык уже к своему "улучшению [текста] программы".
Понимаю, конечно же, что термин Фаулера удобен — все (многие) знают.
Но называть его родоначальником принципа?..
Павел Дворкин, Валерий Лаптев (как известные мне программисты "тех времён"), ведь так и было? Улучшали же (по этому принципу) и до Фаулера?
По поводу алгоритмов:
где Кормен? Классика + более гуманная книжка, чем Кнут.
Общался с Майкрософт по поводу стажировки. Прислали список книг, которые они уважают. Может, кому интересно.
Software Development Recommendations:
Box, Don. Essential .Net, Volume I: The Common Language Runtime. Addison-Wesley Professional, 2003.
Brooks, Fredrick. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley Professional, 1995.
Cormen, T.H., Leiserson, C.E., Reivert, R.L., Stein, Cliff, eds. Introduction to Algorithms. McGraw-Hill, 1990.
Howard, Michael, LeBlanc, David, eds. Writing Secure Code. Microsoft Press, 2001.
McConnell, Steve. Code Complete: A Practical Handbook of Software Construction. Microsoft Press, 1993.
Maguire, Steve. Writing Solid Code: Microsoft’s Techniques for Developing Bug-Free C Programs. Microsoft Press, 1993.
McConnell, Steve. Rapid Development: Taming Wild Software Schedules. Microsoft Press, 1996.
Tanenbaum, Andrew. Modern Operating Systems. 2nd ed. Prentice Hall, 2001.
Program Management Recommendations:
Bentley, Jon. Programming Pearls: Second Edition. Addison-Wesley, Inc., 2000.
Gamma, E., Helm, R., Johnson, R., Vlissides, J., eds. Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994.
Kernighan, Brian, Pike, Rob, eds. The Practice of Programming. Addison-Wesley, 1999
Testing Recommendations:
Kaner, Cem, Bach, James, and Pettichor, Bret, eds. Lessons Learned in Software Testing. John Wiley & Sons, 2002.
Kaner, Cem, Falk, Jack, & Nguyen, Hung Quoc, eds. Testing Computer Software (2nd Ed.). International Thomson Computer Press, 1993.
Myers, Glenford. The Art of Software Testing. John Wiley and Sons, 1979.
Patton, Ron. Software Testing. SAMS Publishing, 2000.
Sistowicz, Jon, Arell, Ray, eds. Change-Based Test Management: Improving the Software Validation Process. Intel Press, 2003.
Viega, John, McGraw, Gary, eds. Building Secure Software: How to Avoid Security Problems the Right Way. Addison-Wesley, 2001.
Странно, что в секции С++ нет книги David Abrahams, Aleksey Gurtovoy: C++ Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond. По-крайней мере, она более внятная и систематическая нежели чем работа Александреску. имхо
SC>"Книга стала родоначальником столь популярного ныне принципа постепенного улучшения кода без изменения функциональности". SC>Родоначальником? SC>Или дал название тому, чем занимались программисты и ранее?
Конечно же вы правы, и очень маловероятно, что какая-либо книга может быть родоначальником чего-то. Вначале проводятся исследования, пишутся статьи, проводятся выступления на конференциях и многое другое. Потом, бывает, появляется книга, которая служит мощным катализатором для развития чего-то нового.
Обо всем этом я знаю и готов с вами поделиться, только в две три строки это не втиснуть
Конечно же, подобные тенденции (течения, новшества) как рефакторинг, обычно строятся на практическом опыте и уже долгие годы многие опытные разработчики пользовались подобными методами для борьбы с проблемами в коде.
Если говорить более формально, то первые специалисты, которые попытались формализовать подход улучшения кода без внесения функциональности (a.k.a рефакторинг), были Кент Бек и Вард Каннингем.
Кроме них, исследованиями в вопросах рефакторинга занимались Ральф Джонсон, Уильям Апдайк, Джон Брант и Дон Робертс.
Опять же, никто низ них не придумал сам подход, но работа каждого из них имела колоссальное влияние на развитие этого направления.
Из всех перечисленных выше только Вард Каннингем не является одним из соавторов этой книги. Сам же Фаулер (как он сам признался) не оказал существенного влияние на развитие понятия рефакторинга (до публикации книги), но он оказался тем человеком, который структурировал эти знания и собрал группу профессионалов в этом вопросе.
Все это я веду к тому, что хотя книга Фаулера и не является родоначальником самого принципа рефакторинга, то именно она стала "катализатором" развития этого понятия. Я думаю нужно отдать должное всем автором, поскольку они сделали многое для популяризации этого принципа среди простых разработчиков. И очень может быть, что именно благодаря этим ребятам, сегодня практически в каждой IDE находится куча функций, упрощающих проведение рефакторинга. Но даже несмотря на подобную автоматизацию я нисколько не умаляю пользу этой книги для простого разработчика.
SC>Когда несколько лет назад я впервые увидел аннотацию этой книги, сразу подумал — вот и название для того "улучшения программ", которым я и занимался частенько, называя это занятие "улучшением [текста] программы". SC>Думаю, многие программисты занимались этим тоже. А Фаулер — дал название. SC>Вот только я привык уже к своему "улучшению [текста] программы".
Я к калькам с английского языка отношусь не слишком хорошо, но термин "рефакторинг" уже стал устойчивым. Если вы скажете на форуме: "Вам нужно улучшение [текста] программы", вас никто не поймет, т.к. что именно вы будете подразумевать под термином "улучшение" — не понятно.
Я за использование устойчивой терминологии, даже если это противоречим моему (или вашему) личному вкусу и предпочтениям.
SC>Понимаю, конечно же, что термин Фаулера удобен — все (многие) знают. SC>Но называть его родоначальником принципа?.. SC>Павел Дворкин, Валерий Лаптев (как известные мне программисты "тех времён"), ведь так и было? Улучшали же (по этому принципу) и до Фаулера?
Здесь можно провести аналогию с шаблонами проектирования. Многие опытные разработчики уже в течении многих лет использовали повторное использование типовых решений. И, конечно же, использовали за долго до того, как эта же мысль возникла в светлых головах некоторых специалистов.
Насколько я знаю, первые опубликованные труды по шаблонам проектирования датированы 87 годом и принадлежат уже знакомым Кенту Беку и Варду Каннингему.
До публикации знаменитой книги банды четырех вопросами шаблонов проектирования занимались множество специалистов, причем занимались уже в течении длительного времени. Но именно GoF Book стала тем катализатором, которая привлекла внимание широкой общественности к этому понятию и именно благодаря им сейчас об этом знает большинство разработчиков.
Я думаю, что можно провести параллель между двумя этими книгами и их влиянием на развитие рефакторинга и шаблонов проектирования, соответственно.
Лично я не считаю подобные аллегории слишком уж существенными (я по поводу "родоначальников")... Я действительно считаю, что это не слишком принципиально, но если это действительно так, то я подумаю над тем, как перефразировать это описание, чтобы подобных негативных эмоций у читателей не возникало.
Здравствуйте, Сергей Тепляков, Вы писали:
СТ>Аннотация: СТ>В статье приведен перечень книг, по праву считающихся классикой компьютерной литературы в самых различных областях разработки программного обеспечения
Что-то у меня в голове есть четкое разделение на "программирование" и "разработку ПО".
Языки/технологии/платформы — это все к разработке. К CS относится "лексический и синтаксический анализ", классика Ахо "Красный дракон".
ООП и управление проектами — это все методологии и относятся только к разработке.
Тот кто рекомендует только Кнута по алгоритмам, уж извините, его точно не читал. Не упомянуть Кормена есть смертельный грех.
Единственное, что хоть как-то соответствует — БД. Только нетривиальный вопрос: относятся ли БД к CS? Реляционная алгебра, логика в том же Дейте рассматривается в пару сотен страниц.
Хотя смотря на предыдущую структуру, почему бы не поделить на всякие oracle/*sql?
Почему-то нет SICP, никакой теории сложности, графов, выч. геометрии, вообще никакой теории (Кнут тут явно в список случайно попал). Но есть winapi&&com.
Здравствуйте, 67108864, Вы писали:
6>Что-то у меня в голове есть четкое разделение на "программирование" и "разработку ПО".
Эти два термина соответствуют англоязычным терминам programming и software development. Которые означают одно и то же:
Описание понятия Software Development:
The term software development is often used to refer to the activity of computer programming.
Я думаю вы имели ввиду разделение на Computer Science (как науку информатика) и прикладное применение этой науки, которая выливается в программирование (или разработку ПО). Вот с этим я совершенно согласен, такое разделение действительно присутствует.
6>Языки/технологии/платформы — это все к разработке. К CS относится "лексический и синтаксический анализ", классика Ахо "Красный дракон". 6>ООП и управление проектами — это все методологии и относятся только к разработке.
Вы все правильно поняли, конечно же это перечень книг, которые относятся не столько к CS, сколько к прикладному искусству (a.k.a programming). Скорее просто не нашлось нормального названия. Назвать, статью "Классика книжек по программированию", как-то не звучит, вот и остановились на таком названии.
Цель была собрать книги, которые являются проверенными, "классическими" книгами в различных областях ... скажем, разработки ПО. Книги, которые будут полезны не в академических кругах, а для профессиональных разработчиков, желающих пополнить свой багаж в той или иной области. Изначально не было никаких намерений давать книги, область применений которых ограничивается университетскими курсами и которые имеют небольшую практическую применимость. Я нисколько не умаляю глубину всех глубин, которые излагаются в таких книгах (и возможно, что некоторые из таких книг, действительно стоит сюда добавить), но цель, все же, была немного другой.
З.Ы. Я очень жду от всех участников форума конструктивных предложений, а не претензий к деталям. Я не отказываюсь от слов, которые написаны во вступлении: этот перечень будет изменяться и развиваться. Главное, чтобы все поняли наши намерения, и что же мы хотим в итоге получить.
Здравствуйте, SergeyT., Вы писали:
ST>Эти два термина соответствуют англоязычным терминам programming и software development. Которые означают одно и то же: ST>Описание понятия Software Development: ST>
ST>The term software development is often used to refer to the activity of computer programming.
ST>Я думаю вы имели ввиду разделение на Computer Science (как науку информатика) и прикладное применение этой науки, которая выливается в программирование (или разработку ПО). Вот с этим я совершенно согласен, такое разделение действительно присутствует.
В нагло-американском все довольно четко "CS && EE" (теория и практика). В русском же под понятием информатика и "компьютерные науки", увы, скрывается все что угодно.
В словосочетании "computer science" второе слово в любом переводе будет означать науку/теорию.
На английском языке выбор поболее.
Отличный перечень идиом языка (это не совсем одно и тоже, что и паттерны) C# есть в книгеFramework Design Guidelines
Многие (в частности на stackoverflow) хвалят книгу Роберта Мартина Agile Principles, Patterns, and Practices in C#, единственная проблема, что она вышла еще в 20006-м, поэтому там ничего не будет о лямбдах и LINQ.
Ну и еще вот эта: Head First Design Patterns, все примеры в ней на Java, поэтому для C# программиста читать ее также должно быть просто (кроме того для этой книги доступны примеры на C#).
Здравствуйте, SergeyT., Вы писали:
ST>З.Ы. Я очень жду от всех участников форума конструктивных предложений, а не претензий к деталям. Я не отказываюсь от слов, которые написаны во вступлении: этот перечень будет изменяться и развиваться. Главное, чтобы все поняли наши намерения, и что же мы хотим в итоге получить.
А по компиляторам что-нибудь у вас есть? Я только одну знаю (книга красного дракона). Несмотря на то, что написанием типа компиляторов С++ мало кто занимается, мне кажется что многие прикладные вещи по разбору текста и создания простейших скриптов не такая уж редкая задача.
Здравствуйте, Fantasist, Вы писали:
F>Здравствуйте, SergeyT., Вы писали:
ST>>З.Ы. Я очень жду от всех участников форума конструктивных предложений, а не претензий к деталям. Я не отказываюсь от слов, которые написаны во вступлении: этот перечень будет изменяться и развиваться. Главное, чтобы все поняли наши намерения, и что же мы хотим в итоге получить.
F>А по компиляторам что-нибудь у вас есть? Я только одну знаю (книга красного дракона). Несмотря на то, что написанием типа компиляторов С++ мало кто занимается, мне кажется что многие прикладные вещи по разбору текста и создания простейших скриптов не такая уж редкая задача.
Сам не читал, как и книгу "красного дракона" к сожалению, но слышал много хороших отзывов — Т.Пратт — Языки программирования. Разработка и реализация.
Вот еще интересный пост на этому тему нашел — http://rsdn.ru/forum/alg/932661.aspx
Здравствуйте, Сергей Тепляков, Вы писали:
СТ>Аннотация: СТ>В статье приведен перечень книг, по праву считающихся классикой компьютерной литературы в самых различных областях разработки программного обеспечения
Я бы постеснялся называть эту статью "классика Computer Science".
Лучше назвать "классика Software Engineering".
Computer Science — это уж очень широкое понятие.
Гляньте в Википедию.
Извините за сравнение, но это так же,
как назвать учебник по черчению "Классикой математики".
PS. И добавьте Кормена в алгоритмы. Это не меньшая классика, чем Кнут.
PPS. Ещё будет полезно добавить SICP в "общие вопросы".
исправим
