Комментарии 68
Это называется опыт, со временем который перерастает в качество (в архитектуре системы в том числе).
Я верю что ещё не всё потеряно))
Я не верю, что даже с огромным опытом разработчика красивая архитектура рождается с чистого листа. Она не может вытекать напрямую из требований.
По-моему может. Проблемы начинаются, когда требования дополняются, расширяются и изменяются по ходу дела.
Мне кажется, ещё зависит от опыта в этой сфере. Например, программист всю жизнь писал всякие корпоративные программы, а тут ему надо написать карточную игру. Архитектура будет явно слабой. Потом ещё одна область — ещё одна слабая архитектура. И так каждый раз, когда человек входит в неизведанные для себя пространства.
Я воспринимаю архитектуру, как проекцию взамоотношений абстрактных или привязанных к реальным сущностей на технологии, которые будет поддерживать их существование в привычном нам цифровом мирке.
В первом случае нужно мастерство аналитика, во втором — знание матчасти.
Можно проектировать видеохостинг, предположив, что видеоролик занимает 1 мб и моментально прередается клиенту и потерпеть фиаско.
Можно проектировать документооборот между госорганизациями, предположив, что это горизонтально расположенные сущности и так же прогореть.
Но с каждым кейсом и не без помощи здравого смысла мы затыкаем дырку в понимании то в одной области то в другой и шанс на 100% фиаско заменяется на 50%, и быстро убывает. Хорошего архитектора может родить буквально десяток кейсов.
В первом случае нужно мастерство аналитика, во втором — знание матчасти.
Можно проектировать видеохостинг, предположив, что видеоролик занимает 1 мб и моментально прередается клиенту и потерпеть фиаско.
Можно проектировать документооборот между госорганизациями, предположив, что это горизонтально расположенные сущности и так же прогореть.
Но с каждым кейсом и не без помощи здравого смысла мы затыкаем дырку в понимании то в одной области то в другой и шанс на 100% фиаско заменяется на 50%, и быстро убывает. Хорошего архитектора может родить буквально десяток кейсов.
Так всегда… Приходится втихаря под прикрытием других задач (которые ты оценил «ого-го», а на самом деле они просто «тьфу») заниматься идеологически правильным исправлением уже сделанного… ^_^
Думаю большинство программистов проходят через такое (страдания души поэтапрограммиста :) ), по крайней мере в просторах СНГ, где культура разработки своеобразная… Увольняться или оставаться каждый решает сам для себя, иногда жизнь вынуждает идти на компромиссы с совестью и другими товарищами.
>«Какой еще РеХаКтОрИнГ? Ты же сказал всё работает! У нас много других задач...».
действительно, а зачем? сделал, сдал в эксплуатацию и занялся чем-то более другим.
вот когда потом нужно будет туда что-то добавлять и менять — тогда можно и порефакторить, если мешает жить.
действительно, а зачем? сделал, сдал в эксплуатацию и занялся чем-то более другим.
вот когда потом нужно будет туда что-то добавлять и менять — тогда можно и порефакторить, если мешает жить.
Если попросят чуток улучшить… С их точки зрения это (чуток)… А времени уйдёт на рефакторинг, столько что не оправдаться нормальными словами))
>Если попросят чуток улучшить… С их точки зрения это (чуток)… А времени уйдёт на рефакторинг
а не рефакторьте все сразу. итерационно надо.
а не рефакторьте все сразу. итерационно надо.
Хуже если этот чуток действительно чуток с любой точки зрения, но огромный костыль с точки зрения архитектуры.
Вполне нормальное ситуация. И вполне ожидаемая реакция от начальства. Вот если этот код нужно будет дорабатывать, тогда можно и рефакторить, а так просто зачем?
Правда вот на мысли «будь мужиком ...» надо было остановиться и все же начать рисовать. Если только сроки дико не поджимали.
Правда вот на мысли «будь мужиком ...» надо было остановиться и все же начать рисовать. Если только сроки дико не поджимали.
Есть такой моральный принцип, спорный, но от Льва Толстого (как свидетельствует его сын в «Очерках былого»): «Если ты что-нибудь делаешь, делай это хорошо. Если же ты не можешь или не хочешь делать хорошо, лучше совсем не делай».
Всегда получается ему следовать? :)
Уволят. Лев Толстой мог этого не бояться. Но с поправками на враждебную среду — почему бы и не следовать?
Это не принцип, это перфекционизм! Для гениев вроде Толстого это может быть хорошо, но для всех остальных — однозначно плохо! Сколько из-за него неначатых проектов! А сколько книг не написано?
Конечно, мало кто может написать роман, претендующий на нобелевку по литературе. Но написать и выиграть не столь престижного «букера» — разве не стоит попытаться, зная что до идеала тебе еще далеко?
Конечно, мало кто может написать роман, претендующий на нобелевку по литературе. Но написать и выиграть не столь престижного «букера» — разве не стоит попытаться, зная что до идеала тебе еще далеко?
нет. хорошо — не значит «идеально». делать хорошо, на 100% для себя. для своего уровня.
а если слукавили, и при постройке своего дома криво угол дома положили. или окно вставили не сверив с уровнем.
Вам потом это деяние «мулять» будет всю жизнь, пока вы на него смотреть будете.
вот что значит делать хорошо. )
а если слукавили, и при постройке своего дома криво угол дома положили. или окно вставили не сверив с уровнем.
Вам потом это деяние «мулять» будет всю жизнь, пока вы на него смотреть будете.
вот что значит делать хорошо. )
А сколько понаписано пальпфикшена и говнокода? Тренироваться прекрасно — но тренироваться нужно на кошках и у себя дома.
Добро пожаловать в мир разработчиков программного обеспечения!
8 лет кодю. Душевное беспокойство начало 1-2 года назад подкрадываться… Раньше спокойно говнокодил)) Наполнял потом контентом govnokod.ru
Исходя из личного опыта, именно так и происходит, если откладывать рефакторинг (как и написание тестов, кстати) на потом. Последние годы убедили меня, что рефакторинг и тесты нетоделимы от дизайна и собственно написания кода. И, почему-то, я уже давно не рисовал архитектуру отдельно от кода, в смысле, на бумажке. Архитектура — и есть код, классы, пусть даже с пустыми методами.
Подумал-подумал, и решил, что был несколько категоричен. Все вышесказанное — 100% правда. Для случая Java/Scala + Eclipse. Вспомнил времена, когда кодил в VI, и понял, что без хороших инструментов (типа Эклипса), мне было бы намного труднее решиться заниматься рефакторингом не закончив какой-то кусок кода. А сейчас — лафа :) И никаких отмазок, чтобы не делать все правильно.
Со временем с первого раза будет получаться все лучше и лучше, хоть немного в таких случаях (см начальник и «какой еще рефакторинг») помогает себя радовать.
Не корите себя. Если бы вы начали «сразу делать все по паттернам», вы бы до сих пор рисовали абстракции с интерфейсами. А кода бы до сих пор не было.
Везде баланс нужен, да. Просто со временем и опытом вы научитесь его сразу чувствовать.
Везде баланс нужен, да. Просто со временем и опытом вы научитесь его сразу чувствовать.
Эээ… А что значит «сразу делать по паттернам»? Зачем вообще продумывать весь код сначала? Почему не дать ему (коду) расти самостоятельно, исправляя искривления сразу, не дожидаясь врастания уродства в другие куски программы? Не знаю, насколько этот рецепт подходит всем, но я просто пишу код (с тестами, да). Если в процессе хоть раз поморщусь (типа, как-то тут неэлегантно получается), я тут же делаю рефакторинг. В результате код получается прямой, читаемый, неповторяющийся, легко тестируемый.
Ну да, опыт, конечно, помогает находить неэлегантные места и подсказывает, что нужно сделать для их исправления, и опыт этот придет. Но если сначала рисовать _всю_ архитектуру, или, не приведи Господь, UML-диаграммы, а потом писать, получится индусский код. Их так учат. Они в своих университетах запоминают сотни умных слов и названий паттернов, но с практическим применением этих знаний у них проблемы. Смотришь на их код, хватаешся за голову. Говоришь ему — друг дорогой, на кой хрен тут нужны 50 строк кода в элеменарном методе? А он говорит: «А я применил паттерн «Сон синглтона в летнюю ночь на фасаде статической фабрики»». А то, что оно тут просто не нужно, что все эти 50 строк превращаются в три, он не задумывается. Не научен.
Ну да, опыт, конечно, помогает находить неэлегантные места и подсказывает, что нужно сделать для их исправления, и опыт этот придет. Но если сначала рисовать _всю_ архитектуру, или, не приведи Господь, UML-диаграммы, а потом писать, получится индусский код. Их так учат. Они в своих университетах запоминают сотни умных слов и названий паттернов, но с практическим применением этих знаний у них проблемы. Смотришь на их код, хватаешся за голову. Говоришь ему — друг дорогой, на кой хрен тут нужны 50 строк кода в элеменарном методе? А он говорит: «А я применил паттерн «Сон синглтона в летнюю ночь на фасаде статической фабрики»». А то, что оно тут просто не нужно, что все эти 50 строк превращаются в три, он не задумывается. Не научен.
Так всё и было до тех пор, пока не придумали OLAP.
Все внимание на поле F3 прилагаемой картинки.
Наши уже в городе!
Наши уже в городе!
Не понял причём тут OLAP? Речь вроде о UI, а не о технологиях быстрого получения отчётов. Речь идёт о том как задать произвольный запрос в терминах предметной области и в них же получить, а не о том как быстро получить его результаты.
Как то писали мы крупную систему. Служба поддержки периодически к нам прибегала с вопросами и просьбами в базе что-то поправить. Сделали им админку в рамках их предметной области, которая решала все их вопросы. Но бегать не перестали. На вопрос — почему был получен очень простой ответ — через вас быстрее :)
Еще один генератор запросов? Сколько уже их делали, либо получается убогая ни на что не годная заплатка, либо некий монстр, который изучить и использовать сложнее чем SQL. Откройте лучше курсы по SQL в своей конторе!
НЛО прилетело и опубликовало эту надпись здесь
Да я сам ими активно пользуюсь, особенно в части DDL, но аналитические запросы мастерами делать — увольте, SQL совсем не так сложен, как кажется.
Кстати SQL изначально создавался для конечных пользователей, отсюда его максимальная приближенность к естественному языку.
Кстати SQL изначально создавался для конечных пользователей, отсюда его максимальная приближенность к естественному языку.
НЛО прилетело и опубликовало эту надпись здесь
отсюда его максимальная приближенность к естественному языку.
Только не надо забывать, что естественный язык в России русский.
1С же портировали SQL на русский. Местами доставляет :)
С одной стороны, SQL оперирует не сущностями предметной области задачи, а их отображением на реляционную модель да ещё зачастую нормализованным до предела и схемой отображения хранящейся, грубо говоря, только в голове у разработчика, то есть пользователи будут вынуждены использовать больше знаний, чем необходимо. С другой стороны, как посмотрит начальство на заявление программиста «нормально генераторов запросов я написать не смогу, давайте лучше обучим пользователей языку декларативного программирования, для чего нам нужно пригласить преподавателя, чтобы он объяснил им основы реляционной алгебры, SQL и то, как я отобразил предметную область на реляционную модель с учетом особенностей реализации конкретной РСУБД»? Особенно если это «коробочный» продукт.
А вы сделайте набор представлений (VIEW) и хранимых процедур, максимально приближенных к предметной области, инкапсулирующих низкоуровневую структуру.
Я веду к тому, что ваш инструмент, пусть он изначально отличный простой и понятный, с появлением новых хотелок будет обрастать шерстью и в конце концов придется проводить и по нему обучения.
Да, я понимаю что учить менеджеров SQLю — это звучит дико, это наверное утопия, к сожалению :(
Да, я понимаю что учить менеджеров SQLю — это звучит дико, это наверное утопия, к сожалению :(
Если подумать, то говнокод не такая уж и страшная штука. Зато потом уже будешь сразу лучше систему проектировать) Хотя конечно первая версия ПО по любому это говнокод, если у тебя опыта до этого было всего год или два.
Программа программе рознь.
Есть огромный проент софта, где замечательно работает принципе, которых вы охарактеризовали как «какой нафиг РиФаХтоРинх».
Есть у меня приятель, он периодически обращается с просьбами набросать тулзы (программой я это не назову) для автоматизации всякой рутины. Приходит, объясняет. Пока пьем пиво — пишу. По ходу дела уточняем требования. Через часок-другой — глядишь, и пиво выпито и программа сделана. Потом он иногда просит что-то подправить — за пару минут делается костыль и отдается. И где в этом процессе место РеХаКтОрИнГу? Паттернам? Классам?
В принципе, тут напрашивается обобщение — что первую версию софта обдумывай, не обдумывай, всё равно всё гарантированно после десятка «пожеланий» к костылям сведется. Но высказывать вслух не рискну (=
Есть огромный проент софта, где замечательно работает принципе, которых вы охарактеризовали как «какой нафиг РиФаХтоРинх».
Есть у меня приятель, он периодически обращается с просьбами набросать тулзы (программой я это не назову) для автоматизации всякой рутины. Приходит, объясняет. Пока пьем пиво — пишу. По ходу дела уточняем требования. Через часок-другой — глядишь, и пиво выпито и программа сделана. Потом он иногда просит что-то подправить — за пару минут делается костыль и отдается. И где в этом процессе место РеХаКтОрИнГу? Паттернам? Классам?
В принципе, тут напрашивается обобщение — что первую версию софта обдумывай, не обдумывай, всё равно всё гарантированно после десятка «пожеланий» к костылям сведется. Но высказывать вслух не рискну (=
Сейчас работаю над оберткой к одной БД и хочу пожелать твоему другу удачи.
Не может быть сверхуниверсальной и одновременно простой тулзы, которая не стала бы похожей на MS Access или аналогичные. Вопрос какие кейсы использования бывают часто и написать инструмент который нормально обслуживает их, остальное дело вкуса.
Если не устраивает архитектура ее нужно рефакторить до посинения. Потому что потом исправлять ошибки будет сложнее и дороже.
Боссу нужно объяснить сколько времени ценного сотрудника (друга) тратится на эти идиотские процедуры с запросами. Достаточно один раз сделать нормальный инструментарий и он начнет экономить ему бабки в рабочего времени сотрудников. Если до шефа все равно не доходит, нужно просто оказаться помогать ему стрелять себе в ногу.
Нормальный программист без работы не останется и это не повод через себя переступать. Сделав хуевый продукт ты не увеличиваешь шансы на то, что следующий будет лучше, а ты будешь стоить дороже. А работая прокладкой к БД тем более.
Не может быть сверхуниверсальной и одновременно простой тулзы, которая не стала бы похожей на MS Access или аналогичные. Вопрос какие кейсы использования бывают часто и написать инструмент который нормально обслуживает их, остальное дело вкуса.
Если не устраивает архитектура ее нужно рефакторить до посинения. Потому что потом исправлять ошибки будет сложнее и дороже.
Боссу нужно объяснить сколько времени ценного сотрудника (друга) тратится на эти идиотские процедуры с запросами. Достаточно один раз сделать нормальный инструментарий и он начнет экономить ему бабки в рабочего времени сотрудников. Если до шефа все равно не доходит, нужно просто оказаться помогать ему стрелять себе в ногу.
Нормальный программист без работы не останется и это не повод через себя переступать. Сделав хуевый продукт ты не увеличиваешь шансы на то, что следующий будет лучше, а ты будешь стоить дороже. А работая прокладкой к БД тем более.
Вспоминается классическое «вам шашечки или ехать ?». Зачастую, в условиях нехватки времени на «сделать всё красиво и правильно» приходится действовать по методу «глаза боятся, а руки делают». Если при этом не забывать следовать принципам вроде «Keep It Short & Simple», то конечный результат может быть вполне себе удобоваримым. Вообщем-то, от желания предусмотреть всё на свете и получаются монстры типа «всё в одном», которые разве что кофе не варят, но их потом сложно поддерживать и расширять. Важно не поддаваться соблазну и не усложнять без необходимости. Если это простая специализированная утилитка, то вовсе необязательно в неё тащить половину изученных паттернов, кучу абстракций, классов и т.д. Ну и не забываем, что первый блин — всегда комом.
в таких делах 50% автоматизации написания за вас должна сделать архитектура, которая например должна лечь на ООП. поэтому надо тщательно продумывать архитектуру приложения. как правило, такое сделать почти невозможно from scratch, поэтому разрабы поступают хитро: они пишут proof of concept (не альфа!), где накидывают интерфейс на 90% а под ним — костыли-костылики, покрытие функциональности как душа ляжет 20-50%. если шефу нравится, то он дает добро, тогда начинаешь думать над архитектурой, на основе полученного опыта и подводных камней, которые ты уже заметил когда делал PoC. и… начинают снова с нуля! продолжать разрабатывать PoC — считается очень дурной манерой.
Спасибо, такой подход меня вполне устроит)
Главное чтобы шеф/заказчик одобрил такой подход. Применять его «втихаря» — можно натолкнуться на недопонимание типа «За первую неделю/месяц сделал так много, а теперь пятую неделю/месяц никаких сдвигов».
А чтобы не было соблазна продолжать разрабатывать прототип, можно разрабатывать его на языке, который точно в релиз/продакшен не пойдёт :)
А чтобы не было соблазна продолжать разрабатывать прототип, можно разрабатывать его на языке, который точно в релиз/продакшен не пойдёт :)
У лиспа такое прошлое что дай бог всем нам такого будущего.
Закопайте стюардессу Отправьте уже старичка на заслуженный отдых
НЛО прилетело и опубликовало эту надпись здесь
Ухты, у меня так же бывает — уже в ходе кодинга появляется понимание, что херовенько всё работает, придётся править, но тааак лень, но хочется идеальный код и начинается заново… :)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Программирование vs Паттерны