Комментарии 46
Если пользоваться любым фреймворком, то все-равно упрешься в то, что он что-то не может делать. Начинаешь разбираться как это доработать, для чего начинаешь разбираться как он работает. Это весьма помогает. А уж если знаешь несколько фреймворков, то понимания их работы становится вообще весьма прозрачно.
Интересная статья, спасибо!
Знающие хаброжители, помогите советом. Вот я сейчас (на самом деле немного ранее, но это сути не меняет) осознал себя фреймворкером, нашел пробелы в знаниях и стараюсь над ними работать. Но вот мне не дает покоя то, что я наметил себе изучать технологии, а не само "программирование". Как понять что важно выучить? Как понять, что я учу нужную вещь, а не углубляюсь во "фреймворкерство"? Где найти полезные материалы?
Г.Буч: Объектно-ориентированное проектирование - пробуйте проектировать с нуля
Макконел: Совершенный код - много полезного, плюс куча ссылок на другие книги по разным темам по тексту
И много практики с поддержкой того, что создали, чтобы получать обратную связь, а не написали и забыли.
Многие книги "заходят" программисту "А", но не заходят программисту "Б". Поэтому книг придётся читать много и многие из них лично вам не понравятся, но это нормально.
Купить можно много чего. Извиняюсь за качество фото
Я бы добавил к предыдущему комментарию "Чистый код" Роберта Мартина. Из всех его книг мой уровень подняла только эта.
Одна книга на любую тему даст большую фору десяти статьям этой же темы, поэтому лучше делать акцент именно на книгах, а статьями уже "оттачивать" полученный навык.
Но одних книг мало. Их ценность без практики околонулевая, поэтому нужно много программировать. Практика практике - рознь. Лучшая - это когда вы долго-долго поддерживаете какой-то проект. На поддержке вы получите более ценный опыт, чем на разработке с нуля.
«Чистый код» Роберта Мартина
Более разрушительного влияния на индустрию не оказала ни одна книга вообще. Мне не доводилось пока видеть ни одного человека, который хотя бы не начал программировать хуже после ее прочтения. Если кандидат всерьез упоминает ее на собеседовании, мы тут же прощаемся.
Наслышан об этом. Уже не удивляет наличие двух прямо противоположных точек зрения об этом авторе.
А вы в книге "Чистый код" что-то полезное всё-таки нашли, или вообще ни одной полезной мысли? Лично мне зашла глава о функциях.
«Чистый код» читать можно, но с преизряднейшей долей скепсиса и после минимум десяти лет стажа в боевой индустрии (не круд, не джейсон, не фреймворки).
Я обычно сравниваю ее с монографией «Искусство забивания гвоздей» Н. Апелидова: человек купил молоток и написал тысячу страниц, восхваляя его в качестве идеального суперинструмента для всего.
Проблема на первый взгляд незаметна, но она существенна: монографию стали читать и — благодаря авторитету (откуда он вообще взялся?) автора — применять на деле — люди с шурупами, винтами и болтами. Результат — переполненные травматологические клиники и миллиарды разбитых пальцев.
Нет, про функции Мартин тоже ничего не понимает. Про функции лучше читать книги людей, съевших собаку в функциональном программировании. А еще лучше, и гораздо полезнее, — вместо чтения беллетристики потратить время на «сесть и пописать код».
Пример всё же будет лучше. Есть некая служба, работающая с неподконтрольным нам API (отдаёт в ответ на запросы документы разной структуры). Работа API зависит от т. н. режима работы. Бывают режим "Цех", "Производственная линия" и "Отдел планирования".
Для активации режима один джун написал одну такую функцию:
public function setMode($mode)
{
// Тут какой-то switch + case для переменной $mode, емнип.
// В сумме строчек 20
}Другой наш джун написал три разных функции:
public function setWorkshopMode() // внутри несколько строк
public function setManufacturingLineMode() // аналогична предыдущей
public function setPlanningDepartmentMode() // эта тоже единообразнаВам чей код больше по нраву и почему?
Никакой из предложенного, страшно подумать, что с этим кодом станет в многопоточной среде.
Но если надо выбрать — разумеется, первый. Во-первых, я смогу добавить (и убрать) новую моду не перелопачивая тонны легаси. Во-вторых, не нужно скакать по коду туда-сюда, чтобы узнать, как переключаются моды (и какие они вообще бывают). В-третьих, обработка ошибки будет в одном месте, а не в трех (завтра — в пятиста). В-четвертых, первый код допускает некоторую моду по умолчанию, а второй — нет. Ну и так далее.
первый код допускает некоторую моду по умолчанию, а второй — нет.
Вот с этим нельзя не согласиться. Пожалуй, главный аргумент (не в контексте нашего проекта, правда).
А вот с первым и вторым пунктом нельзя однозначно согласиться. При добавлении, например, нового режима "Валидация продукции на линии" никакой проблемы нет. Незачем изучать код остальных режимов. Их изучение даст ответ на вопрос: "Как?", но не: "Почему?", а будет именно такой вопрос.
P. S. А поделитесь опытом, как бы сделали вы? Мне тоже полезно, видимо)
первый, который внутри вызывает вторые, конечно
В том-то и дело, что внутри setMode() не вызывается ни одна из функций ниже :-)
Покажу на абстрактном примере иначе. Допустим, есть форма, которую нужно иногда показывать, иногда скрывать. Для этого у неё есть булевое свойство visible.
Первый джун придерживается такого стиля:
public function visible($bool)
{
$this->visible = $bool;
}
// в разных местах проекта, соответственно, вызывается так:
visible(true);
// либо:
visible(false);Второй джун придерживается стиля с говорящими названиями:
public function show()
{
$this->visible = true;
}
public function hide()
{
$this->visible = false;
}
Может лучше вторые, которые внутри вызывают первую? Не надо передавать параметр, помнить какие значения параметра что означают.
Первый.
Как минимум, потому что при добавлении\удалении режима, второй вызывает изменение паблик интерфейса класса.
Ну и второй размазывает функциональность по нескольким местам.
Если при установке режима предусмотрены какие то доп. действия, например синхронизации\блокировки для многопоточности, то в первом случае это все в одном месте, а во втором будет дублироваться в нескольких местах.
Скажите пожалуйста конкретнее, куда не собеседоваться?
Спасибо за подсказку! С книгами у меня есть проблема, что я либо читаю и мало что схватываю, либо, если сажусь прорабатывать, трачу уйму времени и не всегда хватает сил закончить. Но думаю это уже вопрос самодисциплины и чем дольше это делать, тем проще будет идти.
Чистый Код Мартина обалденная книга, очень рекомендую!
Здравствуйте! Вижу у Вас вот эти книги
- Код, который умещается в голове
- Современная программная инженерия
издательства Питер, подскажите пожалуйста, Вы уже читали, как впечатление?
Дональд Кнут, "Искусство программирования".
вот эту еще пососветую -)
http://learnyouahaskell.com/
Позволю себе не согласиться. Имхо, книга Уилл Курт -- Программируй на хаскель рассказывает про хаскель лучше чем эта, хоть и не так подробно
Эта книга http://learnyouahaskell.com/ – это же алегория! =)
Так в статье же написано - изучайте всякие принципы и подходы программирования, независящие от технологий/фреймворков. Мне кажется, в этом может помочь создание какого-нибудь приложения или программы с использованием голых API операционной системы или браузера (т.е. без фреймворка) и постепенное внесение улучшений в код/рефакторинг по мере того как вы изучаете новые штуки со временем. Того и глядишь свой фреймворк напишете под себя, а заодно и узнаете принципы работы популярных фреймворков.
У Влада Тана было видео как раз на эту тему, про "базовых программистов"
Получить высшее профильное образование?
Будучи фреймворкером вы влегкую проходите самый важный и самый грозный этап собеседования — девочку-эйчаршу, оценивающую вас чисто по формальным признакам: возрасту, национальности и конечно же списку фреймворков, который она точно в состоянии прочесть и заучить и который вы указали в совем резюме.
Если у вас порядок с технарской частью собеседования вы занимаете выбранную нужную вакансию и приступаете к работе.
Когда вы имеете работу, вы не тратите силы и время на поиски где бы подшабашить и можете посвятить их изучению чего-нибудь действительно "разумного, доброго и вечного". А что именно это будет... да черт его знает... может быть что в эпоху помешательства на бесполезных мобильных приложениях это что-то на стыке железа и сфота..?
И тут дело вовсе не в книжках, которые вам советуют прочитать. Книжки нужны и полезны, но инженерство — оно все же где-то в осязаемых вещах...
Надо выдать MVP уже вчера. И срочно пишем функцию load_from_disk(). Инженер это про вдумчиво планировать на начальном этапе. Кто даст время и фидбэк от заказчика? За это время уже 3 фреймворка поменяются.
картина намекает что лучше архитектором
Потрясающая статья! Приятно встретить единомышленника!
Сам себя не похвалишь, никто не похвалит.
PS: жду дизлайков))
Вот не знаю. Всегда считал себя посредственным кодером (в сравнении со знакомыми из шараги). Но каждый раз читая подобные статьи удивляюсь очевидности написанного.
это поведение, которое может измениться
нужно ипользовать принцип бритвы Оккама. случается, что ТЗ "додумывается", и реализуется функционал, который никогда не будет востребован
Автору зачет. Но сейчас сюда набежит толпа УНасДедлайнеров, клепающих баблишко копипастом джейсонов
Люди, названные тут "фреймворкерами", зачастую лишены проблемы велосипедостроения, но в то же время практически не способны к "творческим" идеям и чему-то своему.
Они тоже полезны, на пример для построения MVP, но дай им написать что-то свое и с 0 - на это уйдет уйма времени нежели то же самое дать инженеру с творческим мышлением.
Надо уметь применять, но нужно и уметь создать!
Возможно покажусь занудой и старпером, но советская система образования этим и была знаменита, что учила людей творческому мышлению. А сейчас... эх, одни применители почти. Редко когда на собеседования приходит человек, реально творчески и неординарно мыслящий! "Алло, мы ищем таланты!!!"
Непонятно, почему эти три понятия противопостовляются. Поясню: можно быть очень хорошим инженером в чём-то (например, радиолокация), при этом быть средненьким программистом на C (проверять гипотезы и даже делать MVP на микроконтроллерах) и использовать фреймворк (например, для спектрального контроллера). И как аффтор назовёт такого человека?
Я к тому, что и язык программирования и фреймворк - просто инструменты расширяющие возможности человека, и их изучение не всегда может и должно являться целью у человека.
P.S. Пример взят с реального родственника.
Быть инженером, а не фреймворкером