Учебники/книги по программированию
- Автор темы Shomma
- Дата начала
maxx
Активный пользователь
парни, спасибо!!!
sami
Местный
В общем случае не ясно, что подразумевается под попсовыми книжками. Но начинать с попсы плохо. Она как-правило дает поверхностные знания.
Например, изучив попсовую книжку по SQL, можно научиться писать запросы и создавать таблицы. Но без фундамента по реляционной алгебре это будет обезьянничество без понимания сути процессов, происходящих под капотом.
Это не попса. В принципе, там дается курс дискретной оптимизации, но как-то очень зубодробительно и длинно. Мой препод по дискретке уложил примерно тот же материал в объем методички, просто и понятно.
По поводу Майника - не пойму, как он отнес линейное программирование к оптимизации на сетях и графах? Линейное программирование - вообще дисциплина векторных пространств!!!
Вообще дискретная оптимизация необходима для подготовки программиста, но, как-правило, с ней не приходится сталкиваться ежедневно. Потому начинать с нее не советую. Тем более, что для программирования задач дискретной оптимизации требуются более фундаментальные знания такие как структуры данных, оценка алгоритмической сложности, основы композиции кода и понимание барьеров абстракций. Одно поможет в освоении материала, другое позволит избежать лишней работы и подойти к алгоритмам оптимизации обобщенно.
То есть, да, сети и графы знать желательно, но начинать с них не стоит. Конкретно эту книгу я бы не стал советовать. Объем большой, подача материала не очень.
SICP - самое то для начала. Не требует предварительной подготовки, доступен для понимания даже старшеклассниками, знакомит с разными парадигмами и формирует правильное отношение к ним, показывает сильные и слабые черты. В двух словах - ставит мозги, с которыми после можно критически относиться к разной попсе.
Вот отличная рецензия на русском.
Моё начало - в 16 лет прочитал от корки до корки толстенную книгу по языку С (автора не помню, переводная книга и очень легко написана была), но из компьютеров у меня тогда был только советский программируемый калькулятор :huh:
В 17 прочитал книжку в 350 страниц "Системный подход к программированию" (автора тоже сейчас не вспомню, тоже переводная) - эта книга дала мне очень многое, можно сказать перевернула взгляд на программирование, она позволила понять что программирование бывает разным и подходы к проектированию ПО зачастую являются решающим фактором в успехе или неуспехе вашей программы, то что проектирование это самый важный процесс.
Потом (в 17,5
) начал работать в институте и всё это на практике постиг - у нас в отделе была отдельная группа проектирования, я был в группе программистов.
В 17 прочитал книжку в 350 страниц "Системный подход к программированию" (автора тоже сейчас не вспомню, тоже переводная) - эта книга дала мне очень многое, можно сказать перевернула взгляд на программирование, она позволила понять что программирование бывает разным и подходы к проектированию ПО зачастую являются решающим фактором в успехе или неуспехе вашей программы, то что проектирование это самый важный процесс.
Потом (в 17,5
) начал работать в институте и всё это на практике постиг - у нас в отделе была отдельная группа проектирования, я был в группе программистов.
sami
Местный
Вот это интересно. Прямо таки группа проектирования?
Я в институте попал с совхоз где каждый сам за себя выполнял план. Давали 3-4 задачи на грудь из разряда что сдать надо вчера, а ТЗ никто не видел, и вперед с песнями.
Да, отдельная группа в отделе, в которой (в этой группе) больше 10 чел. работало.
Как сейчас там в отделе - не знаю.
Это было время 85-95 - годы.
Отдел в Управлении (где экономику и зарплату всему институту считают) - там мне посчастливилось работать.
Начальники были удивительными но странными людьми (для моих 17,5 лет).
Причём, я туда пришёл именно "из совхоза" - без образования и прямо из школы, без блата и "лапы".
Я просто хотел работать с компьютерами и ходил тогда и обивал пороги везде - начальник отдела 32 в Управлении (нет его уже, человек был уникальный и я его вспоминаю часто - он меня очень многому научил и в жизни и в части программирования) меня взял на свою ответственность и оформил оператором ЭВМ, потом должность сменилась.
sami
Местный
Про своих бывших начальников я в основном могу сказать что они были удивительно странными людьми (для их должностей и научных степеней). А повезло мне с моим непосредственным руководителем - женщиной, у которой удивительное чутье к качественному коду. Чутье - потому что в то время читать о качестве было нечего. Удивительное - потому как до сих пор я редко встречаю людей, настолько трепетно и ответственно относящихся к своему коду.
Согласен, "чутье к коду" - это непонятная штука.
Человек бросает взгляд на листинг программы, блок-схему, структуру данных в проекте и сразу говорит - что это ерунда.
Кодировщика который трепетно "вылизывает" каждую строчку я бы не назвал трепетными - это скорее перфекционизм, зачастую никому совершенно не нужный.
Проектирование, кодирование, оптимизация, тестирование - нормальные этапы написания ПО, причём это не однозначно последовательные этапы - реверс и циклы тут изначально задуманы :huh: если софт хорошим должен получиться на выходе.
Человек бросает взгляд на листинг программы, блок-схему, структуру данных в проекте и сразу говорит - что это ерунда.
Кодировщика который трепетно "вылизывает" каждую строчку я бы не назвал трепетными - это скорее перфекционизм, зачастую никому совершенно не нужный.
Проектирование, кодирование, оптимизация, тестирование - нормальные этапы написания ПО, причём это не однозначно последовательные этапы - реверс и циклы тут изначально задуманы :huh: если софт хорошим должен получиться на выходе.
sami
Местный
Я не говорил про излишний перфекционизм. Однако, если качеству кода не уделять внимания, то проект скорее всего рухнет, невзирая на качество проектирования. Особенно это касается длительных проектов, которые развиваются во время эксплуатации, а не написаны и сданы под ключ.
Забавно, но давайте задумаемся как и когда появилось само понятие "качество кода" ?
Почему вдруг эта "проблема" возникла ?
Если задуматьтя и серьёзно подойти к этому вопросу, то ответ будет довольно не популярный.
:huh:
sami
Местный
Давайте!
На мой взгляд все довольно просто. Код пишется не для компьютера. Ему пофигу, какой код хранить, компилировать, исполнять. Компьютер сделает с кодом то что от него требуется. Проблема возникла от того, что код необходимо модифицировать. Для того чтобы внести в код изменения, его нужно понять. Для того чтобы его понять, его нужно прочитать. Боб Мартин пытался оценить отношение кода, которого приходится читать к коду, который нужно написать. Он вывел коэффициент 10. Т.е. читать приходится в 10 раз больше, чем писать (полагаю, что этот коэффициент может варьироваться).
Потому, то что и как мы пишем, влияет на скорость разработки в целом. Проблема усугубляется при количестве разработчиков больше одного.
Решать проблему можно двумя способами:
1) писать код с первого раза и навсегда. Боюсь, что это практически невозможно. Требования меняются, модифицировать код часто дешевле, чем писать новый.
2) проводить комплекс мер по улучшению качества кода.
По-моему все популярно. Или я недостаточно серьезно подошел к вопросу?
Это верно, но я о другом.
Я о эфимерном понятии - идеальный код.
Когда вы пишете на asm - код может быть некачественным? НЕТ - он может быть не эффективным, о его качестве судить может только спец по данному и конкретному процессору, но это никому совершенно не нужно.
Когда вы пишите на языке высокого уровня - чем выше уровень абстракции, тем выше вероятность что вы пишете отвратительный код.
К чему всё это я - конечно не к тому, что нужно запретить языки высокого уровня.
Я всё веду к проектированию и постановке - именно это является главным процессом в нынешнем программировании.
Кодировщиков "на $100-200 в месяц" на любой язык сейчас пруд-пруди, в очереди стоят, а постановщиков и проектировщиков нет - такие люди на вес золота.
Я о эфимерном понятии - идеальный код.
Когда вы пишете на asm - код может быть некачественным? НЕТ - он может быть не эффективным, о его качестве судить может только спец по данному и конкретному процессору, но это никому совершенно не нужно.
Когда вы пишите на языке высокого уровня - чем выше уровень абстракции, тем выше вероятность что вы пишете отвратительный код.
К чему всё это я - конечно не к тому, что нужно запретить языки высокого уровня.
Я всё веду к проектированию и постановке - именно это является главным процессом в нынешнем программировании.
Кодировщиков "на $100-200 в месяц" на любой язык сейчас пруд-пруди, в очереди стоят, а постановщиков и проектировщиков нет - такие люди на вес золота.
sami
Местный
Объективного идеала нет, т.к. у всех своя точка зрения и она еще и меняется со временем. Но даже у ассемблерного кода есть цена изменения и поддержки, которая будет варьироваться в зависимости от усилий автора по приведению кода в порядок.
Чем ниже уровень абстракции, тем больше придется код дублировать, тем сложнее его будет поддерживать. Повышение уровня абстракции - единственный способ борьбы со сложностью. Голова у человека устроена так, что она не может удерживать во внимании много деталей.
Проектирование не избавит от необходимости модифицировать и поддерживать написанный код. Требования меняются, и даже самый грамотный и детальный проект перестанет их удовлетворять к тому моменту когда заказчик увидит код в работе и уточнит либо изменит ТЗ. Это не говоря уж об изменениях связанными с багами и оптимизацией (да и цены сейчас другие. Кодеры от килобакса стоят в РФ).
Я не пытаюсь преуменьшить значимость проектирования. Каждый день вижу как неудачные решения приводят к хаосу. Но вот работать с чистым кодом всегда быстрее и приятнее. Безусловно, качество проектирования сказывается и на чистоте тоже.
CoderA
Местный
For Dummies
Я не говорю, что данная книга должна быть первой, обязательной или единственной. Просто привел пример стиля изложения материала, когда повествование отталкивается от реальных задач. Типа: "Вот задача из реального мира ... вот алгоритм, с помощью которого она решается ... этот алгоритм реализуется так-то ... суть алгоритма и его реализация основаны на таком-то математическом аппарате"
Забавно, но давайте задумаемся как и когда появилось само понятие "качество кода" ?
Почему вдруг эта "проблема" возникла ?
Если задуматьтя и серьёзно подойти к этому вопросу, то ответ будет довольно не популярный.
Паттерны и антипаттерны, вроде бы, сформулированы достаточно давно. Хочешь, чтобы код жил долго, а его рефакторинг был легким, делай так и не делай по-другому.
Впервые о качестве кода прочитал в книге Алена Голуба "Enough Rope to Shoot Yourself in the Foot". (2Mike22 в этой книге основная масса примеров "плохого" кода взята из MFC :huh: )
sami
Местный
У меня предвзятое отношение к этой серии.
Книга как раз очень серьезная, и ее нельзя относить к серии For Dummies. Глубина материала значительно превышает уровень, необходимый для решения повседневных задач в неспецифических областях программирования. У меня за плечами 4-х семестровый курс дискретной оптимизации, и несколько спецкурсов типа NP-полных задач, матройдов и графов. Случаев применения этих знаний в моей практике - по пальцам одной руки. Да и то, все сводится к тому что все забывается кроме того, что искать для решения конкретной задачи. И этого мне пока достаточно.
sami
Местный
Вот это как раз подход For Dummies. Паттерны - это типичные решения, обладающие своими показаниями и противопоказаниями. Паттерны позволяют добиваться каких-то целей, но как-правило неминуема расплата. Нельзя делать так как написано в паттернах просто потому что там так написано. Нужно каждый раз включать голову, взвешивать что приобретешь, чего лишишься.
Самое интересное то, что люди, изучающие паттерны, как правило не знают что проблемы, решаемые паттернами в ООП, в соседней парадигме (ФП) не стоят внимания, т.к. решаются с помощью инструментов, предоставляемых функциональными языками из коробки. Т.е. паттерны - это костыли, позволяющие кое-как решать некоторые стандартные задачи из функционального мира. Да, знать их для программирования в ООП необходимо, но это не фундаментальные знания, т.к. описывают местячковые решения конкретных иснтрументов (статически типизированных ООП языков). Шаг в сторону (например динамическая типизация, аспектно-ориентированное программирование) и эти проблемы решаются опять-таки по-другому.
CoderA
Местный
Термин "паттерны" я применил в более широком смысле нежели "оbject-oriented design patterns" ... что-то типа каждый юз кейс имеет свои паттерны и антипаттерны.
А за лекцию спасибо конечно.
Free Pascal и Lazarus
Это учебник по программированию на языке Free Pascal, который представляется авторам ясным, логичным и гибким языком и приучает к хорошему стилю программирования. Свободно распространяемые компиляторы языка Free Pascal реализованы во многих дистрибутивах Linux и для ОС Windows. Кроме того, в этой книге авторы знакомят читателя с принципами создания визуальных приложений в среде Lazarus.
«Мы попытались написать учебник по алгоритмизации и программированию, насколько нам это удалось — судить читателю».
Скачать книгу - http://www.altlinux.org/Books:FreePascal
Это учебник по программированию на языке Free Pascal, который представляется авторам ясным, логичным и гибким языком и приучает к хорошему стилю программирования. Свободно распространяемые компиляторы языка Free Pascal реализованы во многих дистрибутивах Linux и для ОС Windows. Кроме того, в этой книге авторы знакомят читателя с принципами создания визуальных приложений в среде Lazarus.
«Мы попытались написать учебник по алгоритмизации и программированию, насколько нам это удалось — судить читателю».
Скачать книгу - http://www.altlinux.org/Books:FreePascal