Комментарии 43
Высказывание, приведённое в конце, принадлежит Лао-Цзы, а не Конфуцию.
Вообще, весь текст выглядит как бесплотное и бесплодное умствование в попытке выглядеть авторитетно.
Фразы типа «В большинстве случаев хороший код от плохого отличается логикой и архитектурой» не означают ничего.
Вообще, весь текст выглядит как бесплотное и бесплодное умствование в попытке выглядеть авторитетно.
Фразы типа «В большинстве случаев хороший код от плохого отличается логикой и архитектурой» не означают ничего.
Да Вы правы, действительно не Конфуцию, а Лао — Цзы. Спасибо что обратили внимание.
Согласен с предыдущим оратором. Плюс стиль изложения чрезмерно агрессивен, из-за этого по ходу чтения постепенно возникает ощущение отторжения материала. На лицо ярко выраженная категоричность в некоторых оценках, а категоричность в нашей профессии — это как раз зачастую проявление синдрома «самого умного программиста».
Интересно, что к статье «Что такое хороший код..» как иллюстрацию к разделу «С чего начать?» Вы использовали кадр из фильма Железный человек, который потом сменяется вот таким:
Сколько и чему нужно учиться чтобы стать востребованным (и хорошо оплачиваемым) разработчиком?
Плюс нужно придерживаться существующих ограничений, о которых в т.ч. и на хабре проскакивали статьи:
После 30 лет трудоустройство программистом затруднительно.
После 35 лет путь в работу программиста практически заказан.
Иной опыт — обыкновенные исключения.
Плюс нужно придерживаться существующих ограничений, о которых в т.ч. и на хабре проскакивали статьи:
После 30 лет трудоустройство программистом затруднительно.
После 35 лет путь в работу программиста практически заказан.
Иной опыт — обыкновенные исключения.
Сколько пересекаюсь с заграничными программистами на всяких гитхабах и SO — у большинства по авам возраст за 30, что очень радует. Это у нас в СНГ почему-то 23-летние синьоры везде.
Заграницей тоже так обстояли дела, правда раньше, сейчас уже лучше, нормальный возраст подняли до 30 лет. Не радует что эта профессия считается молодой. Она и старой то считаться не должна, более того должен учитываться опыт, если человек отработал программистом 20 лет — его возраст 40, он ушел из одной компании, и что опыт огромен, он считай full-stack, но возраст! «Вы не вольетесь в наш коллектив 25-летних», вроде верно, а вроде речь идет не о вливании а о работе. Если человек адекватен он уживется в любом нормальном коллективе и возраст будет не помехой. Короче меня вот это расстраивает, чем больше работаешь, тем меньше шансов при смене работы найти новую.
Вы совершенно правы, возраст не играет ключевую роль, но при двух условиях — разработчик в возрасте (скажет старше 35 лет) и с постоянным опытом работы, причем он не ленился учиться. К примеру у многих разработчиков с большим стажем присутствует серьезная консервативность во взгляде на методологию программирования, некоторые к примеру принципиально не переучиваются допустим с Clarion или Delphi на более востребованные языки и платформы, если же он постоянно развивался, освоил .NET, JAVA, использование IoC контейнеров и ORM и т.д. и что самое главное сумел перестроиться под самое важное изменение в программирование — это работа в команде. Раньше программирование было индивидуальное в большинстве своем, сейчас же командное, и это оказало серьезное влияние на всю отрасль в целом. Второе условие -это коммуникативность или как вы совершенно точно выразились адекватность. Если оба эти условия соблюдены то возраст это будет скорее плюс чем минус.
Если человек адекватен он уживется в любом нормальном коллективе и возраст будет не помехой.
По опыту скажу, что вполне нормально уживался с 25-30 летними ребятами. Сейчас, когда мне через пару-тройку месяцев будет 55, я нахожу меньше тем… Так же со всеми в коллективе, обсуждаю и сериалы, и книги, и автомобили… Может, быть только, раньше сваливаю с корпоратива… А мне, он и в 40 не так был интересен.
чем больше работаешь, тем меньше шансов при смене работы найти новую.
Этому есть другое объяснение. Чем больше набор скиллов, тем выше зарплатные ожидания, но и меньше вероятность найти работодателя, который будет готов платить за все эти скиллы.
Ага, на международных научных конференциях меня часто путают с PhD student или master student, и немного удивляются, что я уже 3 года как Senior Scientist (с.н.с.).
После 30 лет трудоустройство программистом затруднительно.
После 35 лет путь в работу программиста практически заказан.
Ну, это как сказать…
я после 35 стал профессионально этим заниматься… сейчас мне 54 и я востребован
После 35 лет путь в работу программиста практически заказан.
Ну, это как сказать…
я после 35 стал профессионально этим заниматься… сейчас мне 54 и я востребован
А можете поподробнее про то как вы трудоустраивались, какие встретили сложности? Спрашиваю без сарказма. Если конечно вы не ведете речь о фрилансе, там востребованы любые возраста по программированию.
Поддержу rikert. Очень интересно услышать вашу историю.
rikert ls18
Истории как таковой нет… все банально: Я офицер Вооруженных Сил СССР, служил в Космических войсках (тогда они как отдельное соединение не существовали, но управление соединения было подчинено Генштабу непосредственно), когда все стало рушиться ушел из армии на..., в общем поступил в аспирантуру. Мне тогда было 30 лет. По окончанию аспирантуры я женился и переехал в Питер. Далее еще несколько лет проработал на Государство, заработал пенсию и потом решил заниматься тем, что интересно в жизни. Так как предыдущие проекты были связаны с интернет (но моя роль была больше по части согласования документов), то я ударился в тогда, начинающую развиваться, WEB отрасль.
Программирование мне было интересно со школьной скамьи… Мой отец преподавал кружок программирования, тогда мы программировали на перфокартах… правда кружок через пару занятий заглох. Но, мой интерес активно проявился на первом курсе. Я начинал на таких машинах. В армии я работал в основном в отделе обработки информации, там на БК-10, если кто помнит такой комп сделал программу оперативной обработки телеметрии. Это моя комната в общежитии, справа на столе — БК-010, телевизор Электроника использовался для вывода вместо дисплея.
В общем, профессионально создавать программы я стал начиная с 34-35 лет… Работал в разных студиях, потом ушел в один проект и понял, что просто клепать сайты — не интересно. Потом меня пригласили делать соц.сеть, Соц.сеть так и не взлетела, зарплату мне там не выплатили за 3 мес, но я считаю, что там я поднялся как специалист. Там, мы стали одними из первых в РФ (Первый по моим данным был Макс Лапшин) кто стал использовать RabbitMQ. В этом проекте я реализовал PHP расширение… Ну а дальше скилсы стали увеличиваться вместе с интересными проектами… Выступаю на Конференциях… Вот одно из моих последних выступлений
Я согласен с тезисом автора «хочешь иметь хорошую работу — надо изучать матчасть...» Как говорил мой друг по службе (тоже разработчик, основатель собственной компании) «ты Живой — пока бежишь...»
Истории как таковой нет… все банально: Я офицер Вооруженных Сил СССР, служил в Космических войсках (тогда они как отдельное соединение не существовали, но управление соединения было подчинено Генштабу непосредственно), когда все стало рушиться ушел из армии на..., в общем поступил в аспирантуру. Мне тогда было 30 лет. По окончанию аспирантуры я женился и переехал в Питер. Далее еще несколько лет проработал на Государство, заработал пенсию и потом решил заниматься тем, что интересно в жизни. Так как предыдущие проекты были связаны с интернет (но моя роль была больше по части согласования документов), то я ударился в тогда, начинающую развиваться, WEB отрасль.
Программирование мне было интересно со школьной скамьи… Мой отец преподавал кружок программирования, тогда мы программировали на перфокартах… правда кружок через пару занятий заглох. Но, мой интерес активно проявился на первом курсе. Я начинал на таких машинах. В армии я работал в основном в отделе обработки информации, там на БК-10, если кто помнит такой комп сделал программу оперативной обработки телеметрии. Это моя комната в общежитии, справа на столе — БК-010, телевизор Электроника использовался для вывода вместо дисплея.
В общем, профессионально создавать программы я стал начиная с 34-35 лет… Работал в разных студиях, потом ушел в один проект и понял, что просто клепать сайты — не интересно. Потом меня пригласили делать соц.сеть, Соц.сеть так и не взлетела, зарплату мне там не выплатили за 3 мес, но я считаю, что там я поднялся как специалист. Там, мы стали одними из первых в РФ (Первый по моим данным был Макс Лапшин) кто стал использовать RabbitMQ. В этом проекте я реализовал PHP расширение… Ну а дальше скилсы стали увеличиваться вместе с интересными проектами… Выступаю на Конференциях… Вот одно из моих последних выступлений
Я согласен с тезисом автора «хочешь иметь хорошую работу — надо изучать матчасть...» Как говорил мой друг по службе (тоже разработчик, основатель собственной компании) «ты Живой — пока бежишь...»
и еще один тезис «Программирование — это прежде всего призвание, а не профессия, это стиль жизни...»
А, может я живу — не правильно… не как все, но моя жизнь интересна, хотя и полна багов, как и всякая программа…
А, может я живу — не правильно… не как все, но моя жизнь интересна, хотя и полна багов, как и всякая программа…
Мне 30 лет, до этого 6 лет проработал сисадмином. При этом периодически писал код на нескольких языках, внедрил несколько самописных сервисов, о чём подробно расписал в резюме.
Сейчас почти два месяца пытаюсь найти работу питонистом. За всё это время был на одном собеседовании.
Работодатели сразу отвечают отказом даже по тем вакансиям, где написано, что вообще никакого опыта не нужно.
И если это не из-за возраста, то я вообще не представляю, в чём причина.
Сейчас почти два месяца пытаюсь найти работу питонистом. За всё это время был на одном собеседовании.
Работодатели сразу отвечают отказом даже по тем вакансиям, где написано, что вообще никакого опыта не нужно.
И если это не из-за возраста, то я вообще не представляю, в чём причина.
Когда устраивался программистом мне было 29, за плечами никакого компьютерного опыта, работа юристом в рекламном агенстве, но тем не менее присылали и тестовые и на собеседованиях был. Устраивался junior JAVA или C#. В итоге устроился на C#, но потом почти сразу перешел на iOS разработку. Потом уже менял работу. Также есть знакомые кто в 30-40 становились программистами, и если соглашались на небольшую зп, то устраивались. Так что до 40 дискриминации не замечено. Место действия Новосибирск.
согл, есть возрастная дискриминация… особенно на позиции джуниоров.
какой у тебя город?
какой у тебя город?
Нужно понимать, чем данное положение вещей обусловлено. Когда в нашей стране начался бум интернета и связанных с ним технологий, когда ВУЗы начали пачками выплевывать студентов, массово хватающихся за ставшее ультрамодным программирование, когда силами этих же студентов начали, как грибы, расти конторы, цепляющиеся в первую очередь за западный рынок, тогда да, оказалось, что разработчики предыдущего поколения в этой нише не сильно-то и востребованы. Они не владели модными языками, фрэймворками и платформами, они привыкли вотерфолить по-старинке, они в целом были неторопливы и размеренны и предпочитали искать в справочниках, а не на Стэковерфлоу. Молодое поколение наоборот были энергичным, погруженным в Интернет с головой, быстрым. Но, как показала практика, слишком быстрым, потому что вот это вот хвать за то, хвать за это привело к поверхностным знаниям, к утрате культуры программирования, к тотальному непониманию и неприятию бизнеса как участника процесса разработки. По мере подхода к тридцатнику оно начало массово осознавать, что если так продолжать, то каши особо не сваришь. Можно, конечно, до 60 фрилансить где-нибудь на оДеске, ограничиваясь изучением новых инструментов — тоже вполне себе выбор — но в целом индустрия у нас повернула туда же, куда и западная (только 20-30 годами ранее). А это значит, что те, кому за 30, и кто был в этой Интернет-струе, когда им было 20, прямо сейчас формируют новую экосистему и новые правила игры. Игры, где больше нет, как справедливо отметил коллега ниже, 23-летних сеньоров, а опыт связан не столько с инструментами, сколько с методологиями, методиками и глубоким пониманием процессов, а такой опыт с годами становится только релевантнее.
Поэтому не переживайте — исключения становятся правилами прямо на наших с вами глазах, а следующее поколение программистов будет трудиться уже в других, куда лучших условиях :)
Поэтому не переживайте — исключения становятся правилами прямо на наших с вами глазах, а следующее поколение программистов будет трудиться уже в других, куда лучших условиях :)
> После 30 лет трудоустройство программистом затруднительно.
> После 35 лет путь в работу программиста практически заказан.
Лол
Из моих знакомых самые квалифицированные и высокооплачиваемые программисты как раз после 30-35.
Мне сейчас 32. Давай расскажи мне, как мне трудно трудоустроится)))
> После 35 лет путь в работу программиста практически заказан.
Лол
Из моих знакомых самые квалифицированные и высокооплачиваемые программисты как раз после 30-35.
Мне сейчас 32. Давай расскажи мне, как мне трудно трудоустроится)))
un1t А у нас в фирме, на оборот, менее 30 лет — рассматривают за редким исключением, средний возраст программиста 35, тестера 22.
так что с тобой — полностью согласен
так что с тобой — полностью согласен
Не совсем понял, Ваше высказывание. Если Вы имеете ввиду, что если начать заниматься программированием когда тебе за 30 — то трудоустройство программистом затруднительно — с такой формулировкой я соглашусь т.к. в программировании очень важен опыт, который сын ошибок трудных. Но смена рода деятельности после 30 — это уже исключение так что все возможно. Если умеешь, готов и что самое важное есть возможноть учиться, то вперед. Но нужно быть готовым что учитсья придется всерьез и долго и ни в коем случае нельзя ориентироваться на рекламу со слоганами типа «Вы нам заплатите и за один… три месяца мы сделаем из Вас программиста и будете получать стотыщпятьсот долларов» или книги с формулировками «Освоим программмирование за 21 день» и т.д.
О, ICL на Хабре :) Вопрос есть такой, почему ваша компания не принимает на работу не граждан РФ(если точнее, то граждан стран Таможенного союза)? Мне просто интересно.
Я вот тут не очень понял:
С командой он должен уметь работать, конечно же.
PS
У вас баг в слове «наилучшем»
Нет, есть, конечно, «гениальные» программисты, воображающие, что они «пуп земли», но это обычно довольно быстро вскрывается.
А вот с чем я сталкиваюсь, когда беру в команду гениального программиста:
Первое. Продукт должен быть доставлен в срок. Гениальный программист никогда не соблюдает сроки, и причина проста: он ВСЕГДА пытается найти наилучшее решение, не понимая, что лучшее — враг хорошему.Если программист не соблюдает сроки — он уже не гениальный по определению. Он должен «чувствовать» сроки даже на интуитивном уровне, просто в силу огромного опыта.
Второе. Продукт должен быть надлежащего качества. Гениальный программист всегда будет добиваться чтобы качество было наилучшем и, к сожалению, это во вред срокам и работе всей команды.Выпустить качественный продукт — это-то чем плохо? А сроки — пункт выше.
Третье. По мнению гениального программиста, продукт есть действие его самого, а не всех участников команды, и его гениальный мозг не терпит чтобы вы что-то поменяли в его архитектуре без его ведома.Что ж, вот вам другая цитата:
… С четвертой по шестую главу я доказываю, что самое важное — назначить одного человека архитектором продукта, ответственным за все его стороны...Фредерик Брукс, «Мифический человеко-месяц».
С командой он должен уметь работать, конечно же.
Четвертое. Гениальный программист не понимает, что, если в контроле «КНОПКА» обнаруживается текст «КНОПКО» — для заказчика это баг.Это как-то не стыкуется со вторым пунктом выше.
PS
У вас баг в слове «наилучшем»
Нет, есть, конечно, «гениальные» программисты, воображающие, что они «пуп земли», но это обычно довольно быстро вскрывается.
>Как отличить хороший код от плохого?
>По сигнатуре кода. В большинстве случаев хороший код от плохого отличается логикой и архитектурой. >Используйте в разработке принципы SOLID и всегда их придерживайтесь.
После таких слов рука тянется к не то, что к пистолету, а к автомату. Знание SOLID и других супер аббревиатур не делает ваш код хорошим.
Что такое хороший код.
1. Это читаемый и понятный код. Что это такое- читателю не составляет труда понять ход мыслей программиста и use case который был реализован. В следующий раз когда потребуется добавить подобный функционал, время добавления предсказуемо. При этом дизайн может быть с неоптимальным, дубовеньким и на первый взгляд не правильным, в этом случае добавление займет не 4 часа, а 6.
2. Дизайн кода в точности соотвествует бизнес требованию. Принятое техничекое решени оптимально сбалансировано между расширяемостью и сложностью, без каких либо стратегических супер закладок на будущее, которое никогда не настанет. Например делает тривиальный редактор: считать таблицу, отредактировать строчку, сохранить. Не нужны никакие слои, супер сервисы, инверсия зависимостей, модели и доменные объекты, паттерны и т.д… Надо просто ридером считать запись, закинули в таблицу изменить и сохранить — ВСЕ.
Другой пример есть переключение между 2-3 тремя стейтами, не надо лепить паттерны по SOLID, вполне достаточно обычного switch. Нагромождения ради правильности только усложняют код.
При простом и понятном коде, время на рефакторинг (он необходим когда новая фича лаконично не укладывается текщий код) предсказуемо. Дешевле потратить время на рефакторинг потом, чем усложнить код сейчас.
3. Любая технология, подход, практика используется взвешенно и в соотвествии с ее предназначением. А не так что раз DI хорошо, а Service Locator плохо, то везде инжектим все через конструктор, SL запретить.
Например возьмём автомат калашникова, в нем нет ничего лишнего, а только все нужное. У него есть некоторые недостатки, но преимущество в том, что он стрелляет всегда: его можно купать в болоте, возить в песке, кидать на бетонный пол — и все равно он будет стреллять и выполнять свою задачу.
>По сигнатуре кода. В большинстве случаев хороший код от плохого отличается логикой и архитектурой. >Используйте в разработке принципы SOLID и всегда их придерживайтесь.
После таких слов рука тянется к не то, что к пистолету, а к автомату. Знание SOLID и других супер аббревиатур не делает ваш код хорошим.
Что такое хороший код.
1. Это читаемый и понятный код. Что это такое- читателю не составляет труда понять ход мыслей программиста и use case который был реализован. В следующий раз когда потребуется добавить подобный функционал, время добавления предсказуемо. При этом дизайн может быть с неоптимальным, дубовеньким и на первый взгляд не правильным, в этом случае добавление займет не 4 часа, а 6.
2. Дизайн кода в точности соотвествует бизнес требованию. Принятое техничекое решени оптимально сбалансировано между расширяемостью и сложностью, без каких либо стратегических супер закладок на будущее, которое никогда не настанет. Например делает тривиальный редактор: считать таблицу, отредактировать строчку, сохранить. Не нужны никакие слои, супер сервисы, инверсия зависимостей, модели и доменные объекты, паттерны и т.д… Надо просто ридером считать запись, закинули в таблицу изменить и сохранить — ВСЕ.
Другой пример есть переключение между 2-3 тремя стейтами, не надо лепить паттерны по SOLID, вполне достаточно обычного switch. Нагромождения ради правильности только усложняют код.
При простом и понятном коде, время на рефакторинг (он необходим когда новая фича лаконично не укладывается текщий код) предсказуемо. Дешевле потратить время на рефакторинг потом, чем усложнить код сейчас.
3. Любая технология, подход, практика используется взвешенно и в соотвествии с ее предназначением. А не так что раз DI хорошо, а Service Locator плохо, то везде инжектим все через конструктор, SL запретить.
Например возьмём автомат калашникова, в нем нет ничего лишнего, а только все нужное. У него есть некоторые недостатки, но преимущество в том, что он стрелляет всегда: его можно купать в болоте, возить в песке, кидать на бетонный пол — и все равно он будет стреллять и выполнять свою задачу.
Знание SOLID и других супер аббревиатур не делает ваш код хорошим. — знание абривиатур не делает, а использование (в частности SOLID) делает и объясню почему. Статья расчитана на новичка, который еще не сможет оценить как лучше написать. Поэтому здесь и акцент, не знаешь как, то делай так и в большинстве случаев это будет оправдано. вот когда понабет шишек и наберется опыта, вот тогда уже можно будет рассуждать о преимуществах и недостатках того или иного подхода.
"
Что такое хороший код.
1. Это читаемый и понятный код. Что это такое- читателю не составляет труда понять ход мыслей программиста и use case который был реализован. В следующий раз когда потребуется добавить подобный функционал, время добавления предсказуемо. При этом дизайн может быть с неоптимальным, дубовеньким и на первый взгляд не правильным, в этом случае добавление займет не 4 часа, а 6." — на уровне хелоу ворда будет работать без проблем, на уровне большого проекта с сотнями классов и тысячами зависемостей понять в принципе как работает проект — это уже задача не на один месяц и кто же Вам даст столько времени то. Используется SOLID — как минимум код слабосвязанный, разбираешься только в своем куске остальное не заботит, вероятность сломать что-то минимизируется, а если на косячил, то либо с высокой вероятность на уровне тестирования выплывут баги.
2. Не соглашусь — нужно лепить патерн и правильный подход и зависимость через конструктор. Причина опять же проста, Если проект старттап он начинает жить и 100% появляются требования к доработке и накручиванию нового функционал, а вот предуагадать что прикручивать придется, а что перепиливать — не угадаешь. И когда наступает эта необходимость, обсчет сроков уже вполне себе нормальная задача. А вот другая сторона медали если проект пришел в в поддержку, вот тут уже нужно смотрть на ситуацию и в большинстве случаев, во всяком случае в моей практике полностью его переделывать для бизнеса не выгодно и придется ваять костыли ини куда от этого не денешься.
3. Любая технология, подход, практика используется взвешенно и в соотвествии с ее предназначением. — соглашусь. 90% задач, а может больше основной фактор это скорость реализации. Если наработан правильный стиль, а именно писать реализации интерфейсов а не классы и максимально увеличивать изолированность кода — это на мой субъективный взгляд два самых важных принципа, то время разработки увеличивается примерно на 5-10%, а вот сопровождение кода уменьшается в разы. Попробуйте сопровождать код типа «монолит» — взмокнете и будете очень грубо выражаться в сторону разработчиков. Но повторюсь — даттые советы ориентированы на новичка, который неспособен еще отличить необходимость того или иного подхода.
p.s. не нравится мне пример насчет автомата калашникова. Давайте возьмем самолет. Задача построить самолет — нужно стпроить самолет а не с оглядкой переделать его в звездолет — это я с Вами соглашусь на 100%. Вот только, когда заказчик скажет что у него оказывается взлетная полоса короткая и а грузоподъемность нужно увеличить в два раза, С Вашими подходами Вам придется делать новый самолет, а мне просто поставить на старую модель более мощный двигатель позволяющий вертикальный взлет. Такая алигория мне кажется лучше описывает картинку.
Но в любом случае спасибо за комментарий, всегда интересно и полезно выслушать другое мнение, даже если оно и противоречет собсвенному.
"
Что такое хороший код.
1. Это читаемый и понятный код. Что это такое- читателю не составляет труда понять ход мыслей программиста и use case который был реализован. В следующий раз когда потребуется добавить подобный функционал, время добавления предсказуемо. При этом дизайн может быть с неоптимальным, дубовеньким и на первый взгляд не правильным, в этом случае добавление займет не 4 часа, а 6." — на уровне хелоу ворда будет работать без проблем, на уровне большого проекта с сотнями классов и тысячами зависемостей понять в принципе как работает проект — это уже задача не на один месяц и кто же Вам даст столько времени то. Используется SOLID — как минимум код слабосвязанный, разбираешься только в своем куске остальное не заботит, вероятность сломать что-то минимизируется, а если на косячил, то либо с высокой вероятность на уровне тестирования выплывут баги.
2. Не соглашусь — нужно лепить патерн и правильный подход и зависимость через конструктор. Причина опять же проста, Если проект старттап он начинает жить и 100% появляются требования к доработке и накручиванию нового функционал, а вот предуагадать что прикручивать придется, а что перепиливать — не угадаешь. И когда наступает эта необходимость, обсчет сроков уже вполне себе нормальная задача. А вот другая сторона медали если проект пришел в в поддержку, вот тут уже нужно смотрть на ситуацию и в большинстве случаев, во всяком случае в моей практике полностью его переделывать для бизнеса не выгодно и придется ваять костыли ини куда от этого не денешься.
3. Любая технология, подход, практика используется взвешенно и в соотвествии с ее предназначением. — соглашусь. 90% задач, а может больше основной фактор это скорость реализации. Если наработан правильный стиль, а именно писать реализации интерфейсов а не классы и максимально увеличивать изолированность кода — это на мой субъективный взгляд два самых важных принципа, то время разработки увеличивается примерно на 5-10%, а вот сопровождение кода уменьшается в разы. Попробуйте сопровождать код типа «монолит» — взмокнете и будете очень грубо выражаться в сторону разработчиков. Но повторюсь — даттые советы ориентированы на новичка, который неспособен еще отличить необходимость того или иного подхода.
p.s. не нравится мне пример насчет автомата калашникова. Давайте возьмем самолет. Задача построить самолет — нужно стпроить самолет а не с оглядкой переделать его в звездолет — это я с Вами соглашусь на 100%. Вот только, когда заказчик скажет что у него оказывается взлетная полоса короткая и а грузоподъемность нужно увеличить в два раза, С Вашими подходами Вам придется делать новый самолет, а мне просто поставить на старую модель более мощный двигатель позволяющий вертикальный взлет. Такая алигория мне кажется лучше описывает картинку.
Но в любом случае спасибо за комментарий, всегда интересно и полезно выслушать другое мнение, даже если оно и противоречет собсвенному.
1.
>Используется SOLID — как минимум код слабосвязанный, разбираешься только в своем куске остальное не заботит, вероятность сломать что-то минимизируется,
Для слабосвязного кода SOLID необходимое, но не достаточное условие. Т.е. SOLID помогает, но неверная
иерархия типов точно так же усложнит проект. Такое тож встречал.
2.
>Не соглашусь — нужно лепить патерн и правильный подход и зависимость через конструктор. Избыточное проектирование наперед, внесение дополнительной сложности в надежде, что она окупится в будущем. Я бы с этим был очень и очень осторожен.
Вместо внедрения паттерна State хватит пары-тройки ifов. В будущем этот код возможно поменяется толкьо через пару лет. State только усложнит чтение и увеличит время разработки.
3.
>писать реализации интерфейсов а не классы и максимально увеличивать изолированность кода — это на мой субъективный взгляд два самых важных принципа, то время разработки увеличивается примерно на 5-10%, а вот сопровождение кода уменьшается в разы.
тут опять надо соблюдать баланс, перегибы видел и вчрезмерной изолированности и связности. Изолированность должна быть оправдана.
О выше приведенных подходах я бы не стал так однозначно говорить, т.к. они имеют и плюсы и минусы. Но если их не использовать вообще, код будет точно не айс.
А новичок прежде всего должен сам осознать и понять что и для чего было придумано. Опытные програмисты только в одной области эксперты, а в другой новички. Но профи от дилетанта отличает подход, у профи на выходне некачественного продукта не бывает.
>Используется SOLID — как минимум код слабосвязанный, разбираешься только в своем куске остальное не заботит, вероятность сломать что-то минимизируется,
Для слабосвязного кода SOLID необходимое, но не достаточное условие. Т.е. SOLID помогает, но неверная
иерархия типов точно так же усложнит проект. Такое тож встречал.
2.
>Не соглашусь — нужно лепить патерн и правильный подход и зависимость через конструктор. Избыточное проектирование наперед, внесение дополнительной сложности в надежде, что она окупится в будущем. Я бы с этим был очень и очень осторожен.
Вместо внедрения паттерна State хватит пары-тройки ifов. В будущем этот код возможно поменяется толкьо через пару лет. State только усложнит чтение и увеличит время разработки.
3.
>писать реализации интерфейсов а не классы и максимально увеличивать изолированность кода — это на мой субъективный взгляд два самых важных принципа, то время разработки увеличивается примерно на 5-10%, а вот сопровождение кода уменьшается в разы.
тут опять надо соблюдать баланс, перегибы видел и вчрезмерной изолированности и связности. Изолированность должна быть оправдана.
О выше приведенных подходах я бы не стал так однозначно говорить, т.к. они имеют и плюсы и минусы. Но если их не использовать вообще, код будет точно не айс.
А новичок прежде всего должен сам осознать и понять что и для чего было придумано. Опытные програмисты только в одной области эксперты, а в другой новички. Но профи от дилетанта отличает подход, у профи на выходне некачественного продукта не бывает.
Вообще код на скриншоте не очень. ii.
Чуть больше материала идеальный код и еще куча книжек чуть ниже в разделе рекомендуем… Можно читать любую из них…
НЛО прилетело и опубликовало эту надпись здесь
я бы порекомендовал Троелсона
Почему предпочитаете именно его, а не того же Шилдта или Албахари?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что такое хороший код, или как стать востребованным разработчиком