Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 38
Классный рассказ, жду продолжения!
Где же вас, Валер, в Москве найти можно? :)
Где же вас, Валер, в Москве найти можно? :)
Кхм, все мысли из этого поста, почти под копирку из названных книг. + к ним, я бы посоветовал Кент Бек «Экстремальное программирование: разработка через тестирование», там очень хорошо описана борьба со сложностью, и + Марк Сииман «Dependency Injection in .NET»
Я имею в виду, чтобы оказаться на месте Ержана. До Валеры еще далеко :)
В статье не ставилось цели придумать новые идеи. Она больше ориентирована на то, чтобы в интересной форме дать основную информацию и замотивировать молодых специалистов на развитие. Плюс я описываю свое видение, как нужно работать со стажерами. Очень часто их садят на баги и успокаиваются на этом. Я применяю другой подход, который, на мой взгляд, хорошо работает.
Спасибо за отзыв! Если в Москве нет, приезжайте в Астану ;)
Вместо Совершенного кода, я бы джуниору дал «Принципы паттерны и методики гибкой разработки», того же Мартина. Не потому что они равноценны, а потому что «Совершенный код» очень тяжелый к прочтению, и на нем можно надолго застрять.
Можете описать тяжесть прочтения «Совершенный код»?
Как вы себе это описание представляете?
Книгу просто тяжело читать. Почти также тяжело как спецификацию С++ от Страуструпа. Язык хороший, но читать все равно тяжело.
Я раза четыре брался… До сих пор целиком не осилил. :(
Книгу просто тяжело читать. Почти также тяжело как спецификацию С++ от Страуструпа. Язык хороший, но читать все равно тяжело.
Я раза четыре брался… До сих пор целиком не осилил. :(
В обучении чему-либо я использую итеративное усложняющееся чтение.
Когда по одному и тому же материалу сначала берется самый простой вариант изложения, чтобы построить каркас для знаний, потом более сложный, потом еще более сложный и т.д. Потому что информация лучше запоминается, тогда когда она связывается с уже какой-то другой запомненной информацией, иначе уже через несколько дней она забудется (кривая забывания эббингауза).
«Совершенный код» — это огромный объем информации написанный сухим языком. Тяжесть чтения в том, что у джуниора нет необходимого бэкграунда к которому эту информацию можно привязывать, он просто все забудет после прочтения или надолго застрянет на этой книге, пытаясь качественно усвоить материал.
Когда по одному и тому же материалу сначала берется самый простой вариант изложения, чтобы построить каркас для знаний, потом более сложный, потом еще более сложный и т.д. Потому что информация лучше запоминается, тогда когда она связывается с уже какой-то другой запомненной информацией, иначе уже через несколько дней она забудется (кривая забывания эббингауза).
«Совершенный код» — это огромный объем информации написанный сухим языком. Тяжесть чтения в том, что у джуниора нет необходимого бэкграунда к которому эту информацию можно привязывать, он просто все забудет после прочтения или надолго застрянет на этой книге, пытаясь качественно усвоить материал.
Сухой язык, много воды, отступлений, отсылок и размышлений автора. Приходит понимание, что поверхностное чтение не принесет пользы, что надо основательно проникнуться каждой страницой. Но потом смотришь на количество страниц, и возникает вопрос: а что, если это пустая трата времени? Краткость — сестра таланта. Например, «55 верных способов улучшить программу на C++» гораздо приятнее для прочтения книга.
Тут я полностью опираюсь на свой опыт. Как раз джуниором читал «Совершенный код» и он помог мне значительно улучшить качество кода. И в своей нынешней работе советую эту книгу приходящим к нам молодым разработчикам. Они высоко оценивают эту книгу.
На хабре её как-то ругали.
Еще одна хорошая книжка для начинающих и не только — «Программист-прагматик» Эндрю Ханта и Дэвида Томаса. Классика, читается легко, дает ценные советы как по подходу к работе программиста в целом, так и по проектированию.
Да, согласен с вами. Думал про нее, когда выбирал, какие книги упомянуть.
«Программист-прагматик» — отличная книга, как для начинающих, так и для более опытных разработчиков.
По чистоте и качестве кода лучше читать статьи и блоги от разных авторов, в какой то момент можно увидеть и осознать, что в статьях разных авторов, написанных о разных языках и парадигмах (ООП, ФП) есть некие общие мысли — это и есть общие критерии чистоты и качества кода, ну и, конечно, потребуется пара лет программирования.
«Совершенный код» для начинающих как-то полезен и понятен первые страниц 50-100, а для опытных разработчиков читать сухой текст о довольно очевидных вещах неинтересно и плохо цепляет.
Вот это всё, конечно же, имхо.
Кстати, лайфхак для студентов — в универе есть библиотека! Экономьте деньги на книгах по разработке, методологиям и, особенно, по языкам программирования (самые одноразовые книги, потом просто пылятся на полке и устаревают с бесконечной скоростью).
По чистоте и качестве кода лучше читать статьи и блоги от разных авторов, в какой то момент можно увидеть и осознать, что в статьях разных авторов, написанных о разных языках и парадигмах (ООП, ФП) есть некие общие мысли — это и есть общие критерии чистоты и качества кода, ну и, конечно, потребуется пара лет программирования.
«Совершенный код» для начинающих как-то полезен и понятен первые страниц 50-100, а для опытных разработчиков читать сухой текст о довольно очевидных вещах неинтересно и плохо цепляет.
Вот это всё, конечно же, имхо.
Кстати, лайфхак для студентов — в универе есть библиотека! Экономьте деньги на книгах по разработке, методологиям и, особенно, по языкам программирования (самые одноразовые книги, потом просто пылятся на полке и устаревают с бесконечной скоростью).
Так, он узнал, что существует магическая аббревиатура SOLID, описывающая основные принципы объектно-ориентированного проектирования. А еще оказывается умные люди придумали готовые рецепты для решения разных задач программирования. Они называются паттерны проектирования. Конечно, Ержан сразу мало что понял, у него лишь появилось стойкое желание во всем этом разобраться и научиться писать крутой софт.
Вот серьёзно? где-то в ВУЗах это не дают? (Ержан вроде как мотивированный и изучил бы если б давали)
Тут акцент на казахстанских реалиях. К сожалению, они таковы, что в большей части случаев люди узнают про эти вещи только когда приходят на производство.
Нам тоже такого не давали, а ведь, на минуточку, МГУ и все-такое. В России тоже с computer science все довольно таки плохо. И я, наоборот, очень рад, что есть факультеты, где такое рассказывают, чем печалюсь обратному.
А еще. А еще у меня есть стойкое подозрение того, что есть некоторые концепты, которые можно реально понять только лишь собственной болью. SOLID — один из них. Вообще, это довольно таки поздний концепт, по моему мнению. По крайней мере я не знал людей, которые начинали писать действительно SOLID код до тех пор, пока они не начинали писать грамотные тесты, пока они не осваивали методологий разработки(в боевой обстановке, ессно), как например Code-Review и так далее. Так что в университете о них, конечно, рассказывать, прикольно, но рано. (Если вы, конечно, не про MIT)
А еще. А еще у меня есть стойкое подозрение того, что есть некоторые концепты, которые можно реально понять только лишь собственной болью. SOLID — один из них. Вообще, это довольно таки поздний концепт, по моему мнению. По крайней мере я не знал людей, которые начинали писать действительно SOLID код до тех пор, пока они не начинали писать грамотные тесты, пока они не осваивали методологий разработки(в боевой обстановке, ессно), как например Code-Review и так далее. Так что в университете о них, конечно, рассказывать, прикольно, но рано. (Если вы, конечно, не про MIT)
Я про НГУ и колледж информатики при нем. Тот же SOLID нам рассказывали на занятиях по проектированию, понятное дело полностью его осознать там трудно.
По паттернам был отдельный курс с семинарами и прочими радостями. Правда читал его молодой парень по бумажке, но реальный прогер из Алавара. Да и на других предметах преподы старались про них говорить.
Вероятно дело в том, что наш универ старается привлекать практикующих специалистов на все дисциплины.
По паттернам был отдельный курс с семинарами и прочими радостями. Правда читал его молодой парень по бумажке, но реальный прогер из Алавара. Да и на других предметах преподы старались про них говорить.
Вероятно дело в том, что наш универ старается привлекать практикующих специалистов на все дисциплины.
О, НГУ это здорово :-) Да и то, что людей из индустрии привлекают — тоже здорово. Поздравляю с хорошим и правильным образованием :-)
Но общего тезиса это не отменяет. Знание правильных концепций без правильного опыта приводит к очень разнообразным и интересным ошибкам. Видел довольно много кода, который порочит концепции паттернов, ООП, ФП и другие.
Вообще, все больше прихожу к необходимости групповых дипломов на IT специальностях)
Но общего тезиса это не отменяет. Знание правильных концепций без правильного опыта приводит к очень разнообразным и интересным ошибкам. Видел довольно много кода, который порочит концепции паттернов, ООП, ФП и другие.
Вообще, все больше прихожу к необходимости групповых дипломов на IT специальностях)
Но общего тезиса это не отменяет. Знание правильных концепций без правильного опыта приводит к очень разнообразным и интересным ошибкам. Видел довольно много кода, который порочит концепции паттернов, ООП, ФП и другие.
Безусловно
Вообще, все больше прихожу к необходимости групповых дипломов на IT специальностях
если вы про то, что несколько человек над одним проектом работают, то оно у нас у большинства, наверное, так и было. У нас ещё часто дипломы пишутся при лаборатории Parallels(иногда даже связанные с внутренними продуктами компании) или Intel(вот тут обычно с интелом никак не связанные), и просто при местных фирмах. Возможности научиться есть. Было бы у студентов желание.
Каждый раз что то подобное объясняю новым сотрудникам, будем надеется наконец то вы изложите это литературно :)
С удовольствием почитал бы книгу в таком стиле изложения. Возможно, такие есть?
Тот же самый «Идеальный программист» Роберта Мартина написан в похожем формате. Автор рассказывает истории, правда про себя. Еще «Принципы, паттерны и методики гибкой разработки на языке C#» того же автора. Там истории вперемешку с обычным стилем. А кроме этого подобных книг не встречал.
Я написал две статьи в этом стиле и планирую писать дальше. Кто знает, может постепенно появится и книга про Валеру :)
Я написал две статьи в этом стиле и планирую писать дальше. Кто знает, может постепенно появится и книга про Валеру :)
Жалко, что того же Идеального программиста и Программиста-прагматика давно не переиздавали и в продаже их не найти.
Кстати, с «Идеальным программистом» произошла интересная ситуация. Ребята из издательства «Питер» прочитали мою первую статью про Валеру, ссылка на которую есть в этом посте. И после этого оперативно выпустили электронную версию русского издания книги. Вот пост, где они про это говорят habrahabr.ru/company/piter/blog/245345 Так что теперь можно без проблем купить электронную книгу.
Спасибо. Будем читать.
О, если б всё в этом мире было идеально…
Нам досталась на поддержку система которую наверно специально проектировали так чтобы в ней никто не разобрался. Без документации. Состоит на вскидку на 90% из костылей.
Нам досталась на поддержку система которую наверно специально проектировали так чтобы в ней никто не разобрался. Без документации. Состоит на вскидку на 90% из костылей.
Это еще раз доказывает, что еще есть люди, не сильно понимающие, как нужно проектировать системы. И значит тема развития в этой области весьма актуальна. Я тоже насмотрелся на такой софт. Но после того, как мы плотно взялись за практики разработки и проектирования, много проблем ушло.
У нас есть команда, которую мы практически полностью сформировали из стажеров. Несколько месяцев интенсивного обучения и они разработали систему, которая сейчас весьма успешно внедрена в одном из городов Казахстана. Поддержка ее не доставляет особых проблем, так же как и развитие.
У нас есть команда, которую мы практически полностью сформировали из стажеров. Несколько месяцев интенсивного обучения и они разработали систему, которая сейчас весьма успешно внедрена в одном из городов Казахстана. Поддержка ее не доставляет особых проблем, так же как и развитие.
Вопросы могут показаться троллингом, но на самом деле нет.
1. Вот есть у нас код программы, системы. Как понять это хороший код или нет?
2. Чем отличается «Хоршее» ООП от «Плохого» ООП.
Интересуют субъективные! Критерии, управляющие метафоры. Т.е. не надо меня отсылать к книгам, статьям и стандартным определениям. Нужен ответ которые пропущен через субъективный опыт. И желательно не слишком обобщённый.
Дело в том, что, например, книга «Совершенный код» В процессе прочтения трансформируется в мозгу в набор неких утверждений(поверхностные структуры), а потом трансформируется(«проваливается») в некую систему в виде визуальных образов внутри сознания. И через неё пропускается в процессе написания программного кода.
Или например, чем отличается хороший и опытный программист от плохого и не опытного?
В процессе изучения платформы, системы, языка программирования программист строит некое представление — модель о том как работает платформа, язык программирования. У хорошего и опытного программиста эта модель более «точная» и «полная», более связная и разветвлённая. Нежели у неопытного и плохого.
Цель вопросов, достать вот эту модель из сознания\бесознательного. Что сложно. Т.к. Обычно начинают сыпать стандартными определениями, понимая под ним совсем другое.
1. Вот есть у нас код программы, системы. Как понять это хороший код или нет?
2. Чем отличается «Хоршее» ООП от «Плохого» ООП.
Интересуют субъективные! Критерии, управляющие метафоры. Т.е. не надо меня отсылать к книгам, статьям и стандартным определениям. Нужен ответ которые пропущен через субъективный опыт. И желательно не слишком обобщённый.
Дело в том, что, например, книга «Совершенный код» В процессе прочтения трансформируется в мозгу в набор неких утверждений(поверхностные структуры), а потом трансформируется(«проваливается») в некую систему в виде визуальных образов внутри сознания. И через неё пропускается в процессе написания программного кода.
Или например, чем отличается хороший и опытный программист от плохого и не опытного?
В процессе изучения платформы, системы, языка программирования программист строит некое представление — модель о том как работает платформа, язык программирования. У хорошего и опытного программиста эта модель более «точная» и «полная», более связная и разветвлённая. Нежели у неопытного и плохого.
Цель вопросов, достать вот эту модель из сознания\бесознательного. Что сложно. Т.к. Обычно начинают сыпать стандартными определениями, понимая под ним совсем другое.
Я приведу аналогию с текстом. Если вы посмотрите на структуру моих статей, то увидите, что она состоит из небольших абзацев примерно равного размера, каждый из которых несет некую законченную мысль. И эти абзацы постепенно раскрывают ту картину и историю, которую я задумал. Может быть не всегда получается, но я иду по этому пути. И многие отмечают, что статьи читаются легко.
Та же самая история и с кодом. Если я открыл код и вижу небольшие блоки (классы, методы), которые написаны просто и имеют четкую и понятную цель, то я понимаю, что код хороший. Дальше я начинаю по ним идти и если они постепенно раскрывают передо мной замысел автора, то я еще больше утверждаюсь в своем мнении. То есть для меня хороший код — это такой код, который легко читать и понимать.
Что касается ООП, то в дополнение к вышеописанному я ожидаю увидеть там минимальное использование статических конструкций, активное использование интерфейсов, отсутствие злоупотребления наследованием. Ну и некие четкие уровни абстракции. Чтобы на каждом уровне я понимал, что делает система. И в детали углублялся только тогда, когда сам этого захотел.
Это мое метафорическое и субъективное восприятие. Было бы очень хорошо услышать такое видение от других людей, чтобы более полно раскрыть тему.
Та же самая история и с кодом. Если я открыл код и вижу небольшие блоки (классы, методы), которые написаны просто и имеют четкую и понятную цель, то я понимаю, что код хороший. Дальше я начинаю по ним идти и если они постепенно раскрывают передо мной замысел автора, то я еще больше утверждаюсь в своем мнении. То есть для меня хороший код — это такой код, который легко читать и понимать.
Что касается ООП, то в дополнение к вышеописанному я ожидаю увидеть там минимальное использование статических конструкций, активное использование интерфейсов, отсутствие злоупотребления наследованием. Ну и некие четкие уровни абстракции. Чтобы на каждом уровне я понимал, что делает система. И в детали углублялся только тогда, когда сам этого захотел.
Это мое метафорическое и субъективное восприятие. Было бы очень хорошо услышать такое видение от других людей, чтобы более полно раскрыть тему.
Спасибо, прекрасная статья, прекрасная задумка! Надеюсь, цикл не будет заброшен, как это часто бывает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как Валера взял в команду стажера и начал учить его проектированию