Комментарии 97
Скажите, а вы не читали Майкла Физерса?
К сожалению не читал. Но сейчас стараюсь читать больше именно про книги про чистоту кода, проектирование систем и т.п. А стоит ли читать его книгу? Я, как понимаю, речь идет о книге «Эффективная работа с унаследованным кодом».
Да, речь идет именно об этой книге. Читать стоит, но только на английском (русский перевод ужасен) и после «Рефакторинга» Мартина Фаулера и «Test driven development» Кента Бека.
> Нет, тут дело не в том, что я не смог его залатать, а дело в том, что проект изначально был криво
> спроектирован, что впоследствии привело к очень плачевному результату. Очень много моментов таких
> как: мерцание, переполнение памяти, медленная работа и прочее. Попросту невозможно было убрать.
Это все на самом деле вполне решабельно (тесты и инкрементальный рефакторинг со строгим исполнением принципа «разделяй и властвуй»), просто нужно подойти с правильной стороны, тем более что вариант «все переписать» оказался успешным. И есть подозрение, что изначально вполне можно было уложиться в 4 месяца.
> Нет, тут дело не в том, что я не смог его залатать, а дело в том, что проект изначально был криво
> спроектирован, что впоследствии привело к очень плачевному результату. Очень много моментов таких
> как: мерцание, переполнение памяти, медленная работа и прочее. Попросту невозможно было убрать.
Это все на самом деле вполне решабельно (тесты и инкрементальный рефакторинг со строгим исполнением принципа «разделяй и властвуй»), просто нужно подойти с правильной стороны, тем более что вариант «все переписать» оказался успешным. И есть подозрение, что изначально вполне можно было уложиться в 4 месяца.
Да, возможно, Вы правы. Но на тот момент, главной проблемой стал объем кода. А также несуразная архитектура и логика программы. После 3 разработчиков в этом коде было крайне сложно разобраться. Тем более, что я начал изучать вопросы связанные с проектированием, логикой и прочими вещами, только на окончании разработки старой версии продукта.
За книжки спасибо. Буду изучать.
За книжки спасибо. Буду изучать.
… и Даниэля Арсеновски
… и МакКоннела.
Если Вы про книгу «Совершенный код», то я ее сейчас дочитываю. Но все равно спасибо.
Я, несомненно, про нее. Просто меня удивляет, что вы описываете те вещи, которые там уже давно описаны.
Согласен. Но Вы подумайте, как человек лучше усвоит знания и какие-либо приемы, на собственном опыте или вычитав в книге? Я жалею о том, что я раньше не начал ее читать, так бы не набил столько шишек.
«Вы подумайте, как человек лучше усвоит знания и какие-либо приемы, на собственном опыте или вычитав в книге?»
Вы подумайте о том, что для читающего вас человека это не «собственный опыт». Так что вероятность усвоения приблизительно та же.
(я уж молчу на когнитивную поправку «это он дурак, у меня-то так не будет»)
Вы подумайте о том, что для читающего вас человека это не «собственный опыт». Так что вероятность усвоения приблизительно та же.
(я уж молчу на когнитивную поправку «это он дурак, у меня-то так не будет»)
Да. Верно. Но еще раз повторюсь, что я жалею, что не прочитал эту книгу раньше, так как многие вещи, практически все, там уже описаны. И не надо изобретать велосипед.
так эта статья скорее мотиватор прочитать ту книгу — она — маленькая порция, замануха :) так что она не конкурент книге а наоборот — анонс.
… и Даниэля Арсеновски
>«Лучше потратить больше времени на планирование и проектирование,
>чтобы потом не тратить в разы больше времени на отладку и исправление»
Не удержусь. «Птичка! Лучше день потерять, потом за 5 минут долететь!» (с) Гриф, «Крылья, ноги и хвосты»
>чтобы потом не тратить в разы больше времени на отладку и исправление»
Не удержусь. «Птичка! Лучше день потерять, потом за 5 минут долететь!» (с) Гриф, «Крылья, ноги и хвосты»
А через пару дней расскажите о продукте поподробнее?
Так. Расскажу, что смогу не выходя за рамки соглашения.
На данный момент, для 1-й версии реализовано следующее (повторюсь, описываю только то, что не запрещено):
— распознавание элементов плана
— распознавание текста
— измерение площадей помещений
— распознавание линейных элементов (провода, сетевые кабели и т.д.)
Работает программа по принципу «запустил и забыл». К примеру Вы подбиваете смету для небоскреба, именно по розеткам. В небоскребе 100 этажей. Вы просто загружаете 100 планов в программу, выбираете символ для поиска (розетку), заполняете проект, и нажимаете старт. Все, программа начала анализ. После анализа вы получаете все сто планов с выделенными на них розетками. С помощью различных инструментов, вы подгоняете план до того, который Вам нужен (к примеру измеряете площади, длины и т.д.). После этого все Вы формируете отчет. В котором будут все данные по розеткам, площадям, длинам, стоимости, накруткам и т.д.
На данный момент, для 1-й версии реализовано следующее (повторюсь, описываю только то, что не запрещено):
— распознавание элементов плана
— распознавание текста
— измерение площадей помещений
— распознавание линейных элементов (провода, сетевые кабели и т.д.)
Работает программа по принципу «запустил и забыл». К примеру Вы подбиваете смету для небоскреба, именно по розеткам. В небоскребе 100 этажей. Вы просто загружаете 100 планов в программу, выбираете символ для поиска (розетку), заполняете проект, и нажимаете старт. Все, программа начала анализ. После анализа вы получаете все сто планов с выделенными на них розетками. С помощью различных инструментов, вы подгоняете план до того, который Вам нужен (к примеру измеряете площади, длины и т.д.). После этого все Вы формируете отчет. В котором будут все данные по розеткам, площадям, длинам, стоимости, накруткам и т.д.
Вас в итоге не позвали в штат, на полную ставку?
Или сделали «коробочный продукт» и все? Суппортом фирма разве не занимается?
Или сделали «коробочный продукт» и все? Суппортом фирма разве не занимается?
проектировать и обобщать все заранее это конечно круто, но в реальных условиях на это часто не дают нужное кол-во времени, что влечет за собой такие горы костыльного кода
Да, Вы правы. Но основным моим требованием было то, что бы мне дали столько времени, сколько мне нужно, именно на проектирование системы. Если система грамотно спроектирована, то проблем очень мало и код очень хорошо писать.
Вам очень повезло! Все тщательно спроектировать и реализовать — одно удовольствие.
Я думаю тут не везение, а просто я доступно объяснил, что если мне дадут времени достаточно, то будет все круто, если нет, то мы получим старый продукт. Вот и все. Ведь некоторые заказчики как дети, с ними надо разговаривать проще и доступнее.
к сожалению не всем можно объяснить, точнее не все прислушаются
знаете, когда Вы 3 года получаете только обещания и хотите наконец получить продукт, действительно продукт, не поделку, то Вы согласитесь на мнение и условия разработчика. Но я соглашусь с Вами еще в том, что многие не понимают всей важности проектирования и планирования. Им важна только прибыль/время/затраты, но никак не качество. А если качество важно, то они стараются это компенсировать дополнительными бонусами и прочими плюшками. Грубо говоря, превратить разработчика в маленького ослика, и давать ему больше морковки. Но как ты ослика не корми, он не сможет тянуть больше.
подозреваю что не будь до Вас индусов и головной боли — они бы и не согласились
>> И мы с заказчиком решили, что надо переписать проект с нуля.
Тут я подумал, что самое веселое еще впереди… Но увы) А если серьезно, то респект.
Один только вопрос: как можно гарантировать качество такого проекта? Ведь как я понял, проект «крупный и сложный», но тесты для него не писались.
Тут я подумал, что самое веселое еще впереди… Но увы) А если серьезно, то респект.
Один только вопрос: как можно гарантировать качество такого проекта? Ведь как я понял, проект «крупный и сложный», но тесты для него не писались.
Я про тесты не упомянул. Забыл. Но тесты писались и их очень много. Тем более, что тестировали помимо меня еще другие люди.
>>Тут я подумал, что самое веселое еще впереди… Но увы) А если серьезно, то респект.
Знаете, да, про то как готовились к разработке нового продукта — это отдельная история и я не счел нужным включать ее в данный пост.
>>Тут я подумал, что самое веселое еще впереди… Но увы) А если серьезно, то респект.
Знаете, да, про то как готовились к разработке нового продукта — это отдельная история и я не счел нужным включать ее в данный пост.
Мотивирует, спасибо. Только не функционал, а функциональность :)
(простите за занудство, но глаза режет)
(простите за занудство, но глаза режет)
Не сочтите за придирку, но тег <habracut/> стоило использовать чуть раньше (если он был использован).
2012 год. Анализ сканированных планировок для подсчета розеток?
Кто бы подумал! Но даже на территории бывшего СНГ волна векторизации архивов уже почти прошла, а её уже вовсю обгоняет волна информационного моделирования зданий.
Работаю в этой сфере и крайне удивлен потребности рынка США в таком продукте. Крупные компании типа Боинг пережили этот период еще в девяностых и, к стати, так же не без участия наших продуктов.
Выражаю огромное уважение автору. Попросту говоря, Вы утерли нос не только коллегам программистам, но и нашли плодородную долинку посреди высыхающей степи.
Кто бы подумал! Но даже на территории бывшего СНГ волна векторизации архивов уже почти прошла, а её уже вовсю обгоняет волна информационного моделирования зданий.
Работаю в этой сфере и крайне удивлен потребности рынка США в таком продукте. Крупные компании типа Боинг пережили этот период еще в девяностых и, к стати, так же не без участия наших продуктов.
Выражаю огромное уважение автору. Попросту говоря, Вы утерли нос не только коллегам программистам, но и нашли плодородную долинку посреди высыхающей степи.
Я тоже был удивлен тем, что при проектировании зданий не ведется подсчет элементов. Но как мне объяснили, над зданием работает много компаний, помимо строительных. Планы достаточно часто меняются. Всех фишек продукта я пока не могу раскрывать, поэтому кажется, что все на каком-то начальном уровне, так сказать архаично.
В общем все как у нас!
США… США…
А мы наивно полагаем, что у них давно все проектируют дома в прекрасном Аutodesk Revit, которому уже немало лет, между прочим!
США… США…
А мы наивно полагаем, что у них давно все проектируют дома в прекрасном Аutodesk Revit, которому уже немало лет, между прочим!
спасибо, хорошая статья.
На тот момент я был 3 года чистокровным фрилансером. То есть моя работа — это фриланс.<blockquote/>
а до этого вы работали в коллективе? насколько крупная компания была?
Да. Я работал. И не в одной компании. Я работал в одной компании, которая занимается разработкой ПО для банков и одного гос.учреждения. Так вот их коллектив был человек 15-20 программистов. Плюс куча бизнес-аналитиков, роль которых я не понимаю и не понимал. Также я работал в банке программистом. Коллектив всего банка не скажу, но в нашем ИТ-департаменте было 10 человек. Так же я работал удаленно на одну российскую компанию, штат которой к сожалению не знаю. А сейчас удаленно, на постоянной основе работаю на канадскую компанию, которая занимается разработкой продукта для СЕО-шников. Я развиваю библиотеку, которая распознает капчу.
>… которая занимается разработкой продукта для СЕО-шников. Я развиваю библиотеку, которая распознает капчу.
И вам не стыдно?
И вам не стыдно?
Если честно, то не знаю. Я больше тут применяю свои алгоритмы на практике(шумоподавление, сегментация, нормализация, НС и т.п.) и мне интересен процесс разработки. Но когда ты разрабатываешь что-то, экспериментируешь, а еще за это платят деньги — это круто.
Если сами ПС виноваты в том, что их можно проспамить?
бизнес-аналитики в таком количестве — тёмная сторона силы, за их счёт можно увеличить бюджет на проект, но речь не об этом. вы столь эмоционально и ярко описали свою встречу в говнокодом, что мне показалось, что эта встреча была первой. но раз вы для банков и гос. учреждений ПО разрабатывали, то вас наверное говнокодом не испугаешь :)
Товарищи, может я не по теме, но: накидайте литературы (желательно качабельной) по распознаванию звуков (распознавание голосов птиц у меня). Диплом стоит. Софт написан, а в теории недостаточно источников и информации. С огромным удовольствием почитаю / ознакомлюсь.
Имел я полгода назад «счастье» вписаться в проект, который поначалу казался пустяком на неделю. Описание не предвещало беды: заменить один контрол (MS Chart) на другой, более производительный. Проект на C# 4. В итоге выяснилось, что проект имеет настолько давнюю историю, что был портирован с VB6 на C# неким индусским программистом, а «производительный» оказалось способный работать с десятками тысяч точек и на системе с любой разрядностью. К счастью, через 1,5 месяца работы заказчик пропал на месяц, что позволило с чистой совестью закрыть контракт. После этого я зарекся соглашаться работать, не взглянув на код. К тому же сильно поднял самооценку (с точки зрения качества кода в нашей компании и моего кода в частности), ибо уже забыл, что код бывает ТАКИМ гадким.
Воистину, русский человек способен на подвиг
На самом деле, нихуя
Выбросите такие мысли из головы. А точнее, доработайте их.
Подход а-ля давайте щас все сразу спроектируем круто за один раз — это говноподход. Он губит все: софт, стартапы, методологии.
Руп водопадный умер, и живет Agile.
Почему? Потому что спроектировать систему без живых данных правильно нельзя. Это аксиома. А живые данные получить без системы рабочей тоже нельзя.
Маленькая иллюстрация первой аксиомы: у инженеров на досках и в уравнениях самолеты всегда летают и никогда не падают. А на деле всегда есть ЧТО-ТО ЕЩЕ, что не учли.
Как же быть? Очень просто. Сначала делать интерактивные прототипы. В 99 процентах проектов можно сделать их быстро, говнокодом. Обкатать, стабилизировало требования с заказчиком. Нужно только чтобы был живой прототип с основным функционалом.
Все. А как только обкатали первую ПРОСТУЮ быстронаписанную говнокодом и копипастом версию — уже проектируйте архитектуру.
В данном случае вы наибали себя, простите за грубость. Вы сначала имели дело с протипом системы в виде говнокода, и в общении с заказчиком познали сферу бизнес-логики. А потом уже смогли сесть и спроектировать ВТОРУЮ итерацию с наличием стабильных бизнес-требований.
А если бы с самого начала пытались спроектировать мегаверсию — ничего бы не вышло.
Итерации, итерации, итерации. Причем первая обязательно быстро, говнокодом для скорости, и только самый базовый функционал. Потому что первая итерация это всегда обкатка требований.
Да, это не работает в зданиях жилых. Там сразу проектируется все жестко, хотя и есть запасы прочности и тд.
Но у нас IT, и тут бизнес- реалии поначалу неясны, и чтобы их проверить, нужны итерации.
Еще хороший пример — дизайнеры. Рисуют мля супердизайн месяц, а потом его за один день живым текстом убивает контентщик. Дизайнер же не делает итерации, дурила, он даже в 90 случаев вместо живого текста и пунктов меню доем иисус долор вставляет.
А потом клиент из корда копипастнет текст — и все поехало :)
В общем, допилить имхо нужно посыл. Да, проектировать нужно. Но во время инкрементального рефаткоринга, как там выше кто-то написал. А систему снизу вверх только можно спроектировать, об этом в 97 еще Мартин, который принципы солид придумал и agile манифест подписал, в книгах жег. Или Макконнелл о мифе о стабильности требований
Выбросите такие мысли из головы. А точнее, доработайте их.
Подход а-ля давайте щас все сразу спроектируем круто за один раз — это говноподход. Он губит все: софт, стартапы, методологии.
Руп водопадный умер, и живет Agile.
Почему? Потому что спроектировать систему без живых данных правильно нельзя. Это аксиома. А живые данные получить без системы рабочей тоже нельзя.
Маленькая иллюстрация первой аксиомы: у инженеров на досках и в уравнениях самолеты всегда летают и никогда не падают. А на деле всегда есть ЧТО-ТО ЕЩЕ, что не учли.
Как же быть? Очень просто. Сначала делать интерактивные прототипы. В 99 процентах проектов можно сделать их быстро, говнокодом. Обкатать, стабилизировало требования с заказчиком. Нужно только чтобы был живой прототип с основным функционалом.
Все. А как только обкатали первую ПРОСТУЮ быстронаписанную говнокодом и копипастом версию — уже проектируйте архитектуру.
В данном случае вы наибали себя, простите за грубость. Вы сначала имели дело с протипом системы в виде говнокода, и в общении с заказчиком познали сферу бизнес-логики. А потом уже смогли сесть и спроектировать ВТОРУЮ итерацию с наличием стабильных бизнес-требований.
А если бы с самого начала пытались спроектировать мегаверсию — ничего бы не вышло.
Итерации, итерации, итерации. Причем первая обязательно быстро, говнокодом для скорости, и только самый базовый функционал. Потому что первая итерация это всегда обкатка требований.
Да, это не работает в зданиях жилых. Там сразу проектируется все жестко, хотя и есть запасы прочности и тд.
Но у нас IT, и тут бизнес- реалии поначалу неясны, и чтобы их проверить, нужны итерации.
Еще хороший пример — дизайнеры. Рисуют мля супердизайн месяц, а потом его за один день живым текстом убивает контентщик. Дизайнер же не делает итерации, дурила, он даже в 90 случаев вместо живого текста и пунктов меню доем иисус долор вставляет.
А потом клиент из корда копипастнет текст — и все поехало :)
В общем, допилить имхо нужно посыл. Да, проектировать нужно. Но во время инкрементального рефаткоринга, как там выше кто-то написал. А систему снизу вверх только можно спроектировать, об этом в 97 еще Мартин, который принципы солид придумал и agile манифест подписал, в книгах жег. Или Макконнелл о мифе о стабильности требований
То есть я к чему
Индусы уроды стопудов. Те, которых наняли за гроши. Там есть и умные
Сам давным давно их код рефакторил
Проект вы переписали. Поздравляю. Довели до конца, вы один из тысячи, кто так может. И я даже после чтения комментов про архитектуру поверил, что на сишарпе есть среди говнокодеров асы. Приятно читать
Классно, что вы из России. У нас хороший генофонд. Ну или Украины? В общем, правители просерают такой народ…
Но мне не понравился вывод. Он частный, и в реалиях бизнеса губительный. Да и для программера
Потому что вы, допустим, послушали заказчика, навоображали себе оси изменений и сущности, месяц писали. А он за месяц в голове все перекрутил. И через месяц вам все с нуля надо переписввать. А неохота так как много сил вложили и типа писали сразу круто
А процесс надо знать. Он с насыщением, устанавливающийся к нулю за конечный срок. Сначала вы делаете первые версии быстро и говнокодом, так чтобы было не жалко переделать. Заказчик меняет требования и вы ОПЕРАТИВНО меняете говноверсии. И он кстати будет рад. Так как вы быстро пишете
За это время вы лучше познаёте область предметную. Чтобы во время рефакторинга уже выделять нужные сущности. А не что вы там нафантазировли в первы раз. Напомню, мы 10-20 процентов только слышим от того, что нам говорят. Слышим и осознаем.
Все. Устоялись требования. Берете таймаут и рефакторитп. И уже более длинные итерации.
Еслиьтребования не устояться за месяц допустим — заказчик сам не знает, не итерирует проработку требований. Нахер такого
Если не можете обосновать необходимость рефакторинга — наймите себе говорливого менеджера
Желаю удачных и глубоких выводов.
Индусы уроды стопудов. Те, которых наняли за гроши. Там есть и умные
Сам давным давно их код рефакторил
Проект вы переписали. Поздравляю. Довели до конца, вы один из тысячи, кто так может. И я даже после чтения комментов про архитектуру поверил, что на сишарпе есть среди говнокодеров асы. Приятно читать
Классно, что вы из России. У нас хороший генофонд. Ну или Украины? В общем, правители просерают такой народ…
Но мне не понравился вывод. Он частный, и в реалиях бизнеса губительный. Да и для программера
Потому что вы, допустим, послушали заказчика, навоображали себе оси изменений и сущности, месяц писали. А он за месяц в голове все перекрутил. И через месяц вам все с нуля надо переписввать. А неохота так как много сил вложили и типа писали сразу круто
А процесс надо знать. Он с насыщением, устанавливающийся к нулю за конечный срок. Сначала вы делаете первые версии быстро и говнокодом, так чтобы было не жалко переделать. Заказчик меняет требования и вы ОПЕРАТИВНО меняете говноверсии. И он кстати будет рад. Так как вы быстро пишете
За это время вы лучше познаёте область предметную. Чтобы во время рефакторинга уже выделять нужные сущности. А не что вы там нафантазировли в первы раз. Напомню, мы 10-20 процентов только слышим от того, что нам говорят. Слышим и осознаем.
Все. Устоялись требования. Берете таймаут и рефакторитп. И уже более длинные итерации.
Еслиьтребования не устояться за месяц допустим — заказчик сам не знает, не итерирует проработку требований. Нахер такого
Если не можете обосновать необходимость рефакторинга — наймите себе говорливого менеджера
Желаю удачных и глубоких выводов.
комментарий в избранное, извините за оффтопик.
Уважаемый, Cord (извините, я не знаю как Вас по имени и отчеству).
1. Как я могу адекватно воспринимать от Вас информацию, когда в Вашем тексте столько мата и негатива? Я не девочка и не ханжа, но мне не очень приятно. Как Вы можете так негативно воспринимать все вокруг?
2. Я не из России или из Украины, я из Беларуси.
3. Я не знаю, я раз 8 прочитал Ваших 2 поста, но ничего толком не понял. Какой смысл всего этого посыла был? Я не понимаю. Но осмелюсь предположить, что основным моментом вашей тирады было то, что мол: «Пишите говнокод на начальных этапах, а только после этого садитесь за нормальный код?». Это? Не так ли? Но в целом Ваш посыл очень разорван на несвязанные части.
4. Я работаю чистокровно фрилансером 3 года, еще 2 я отработал наполовину с другими местами работы. Но поверьте, за это время у меня не было провальных проектов.
5. Я не знаю кто Вы по профессии и какое место у Вас в компании, но почему-то Ваш пост пронизан сплошным негативом, мол «всё гов*о и все козлы», у Вас что был неудачный опыт? Почему Вас так это зацепило?
6. Если разобрать Ваш текст на отдельные части, тогда да, в нем будет множество полезных и умных мнений, но в купе они, извините, настолько сумбурны и бессмысленны, что просто мозг перегружается.
Возможно, Вы по-своему правы, но я во многих моментах с Вами не согласен.
1. Как я могу адекватно воспринимать от Вас информацию, когда в Вашем тексте столько мата и негатива? Я не девочка и не ханжа, но мне не очень приятно. Как Вы можете так негативно воспринимать все вокруг?
2. Я не из России или из Украины, я из Беларуси.
3. Я не знаю, я раз 8 прочитал Ваших 2 поста, но ничего толком не понял. Какой смысл всего этого посыла был? Я не понимаю. Но осмелюсь предположить, что основным моментом вашей тирады было то, что мол: «Пишите говнокод на начальных этапах, а только после этого садитесь за нормальный код?». Это? Не так ли? Но в целом Ваш посыл очень разорван на несвязанные части.
4. Я работаю чистокровно фрилансером 3 года, еще 2 я отработал наполовину с другими местами работы. Но поверьте, за это время у меня не было провальных проектов.
5. Я не знаю кто Вы по профессии и какое место у Вас в компании, но почему-то Ваш пост пронизан сплошным негативом, мол «всё гов*о и все козлы», у Вас что был неудачный опыт? Почему Вас так это зацепило?
6. Если разобрать Ваш текст на отдельные части, тогда да, в нем будет множество полезных и умных мнений, но в купе они, извините, настолько сумбурны и бессмысленны, что просто мозг перегружается.
Возможно, Вы по-своему правы, но я во многих моментах с Вами не согласен.
Если я правильно понял Cord'а, то он говорит о том, что нужно использовать разработку итерациями и итерации почаще обсуждать с заказчиком. По двум причинам: обратная связь от заказчика и постепенное понимание вами требований заказчика и предметной области. И не проектировать и делать, а сделать, потом рефакторинг, потом сделать ещё, потом проектирование, потом рефакторинг, потом ещё сделать.
Негатива я в его комментариях не заметил, слэнга много, но мы же тут коллеги все как бы, нет? А он написал всё в курилка-стиле. По-моему, нормально. Просто представьте, что вам это коллега говорит во время какого-нибудь неформального мероприятия.
Негатива я в его комментариях не заметил, слэнга много, но мы же тут коллеги все как бы, нет? А он написал всё в курилка-стиле. По-моему, нормально. Просто представьте, что вам это коллега говорит во время какого-нибудь неформального мероприятия.
Возможно я неправильно понял Coord'a, НО! Я работал над проектом не один день, я имею ввиду первую версию. Я уже знал в принципе чего хотят от меня. Митинги были чуть ли не каждый день, так что я был в курсе всех основных позиций по требованиям от заказчика. Курилка-стиль — это не мое. Здесь идет процесс, нормальный процесс. Мы же в постановке задач не пишем в этом стиле. И нам не пишут. Неформальное общение — это да. Я могу позволить себе высказать что-то наподобие «да он ....», «да… я его требования», «да он не понимает, что говорит». Но в реальности, в работе, я такого себе не позволяю. Профессиональная этика, так сказать…
Второй пункт, помимо итерирования и стабилизации требований — это обкатка на живых данных.
Допустим вы спроектировали поле ФИО длиной 50 знаков. И таких вещей — 100500 штук.
Кодировку выбрали для данных cp1251, и т.д.
А стали через год продукт забивать — оказывается, ЖИВЫЕ данные не влазят в это поле, китайские символы особенно. И такого всего менять по «суперспроектированной крутой» программе — не перечесть.
Поэтому чтобы избежать переписывания с нуля, нужны итерации. И постоянная работа на живых данных, постоянная, с первого месяца программы.
Иначе, увы, не работает. А рисовать красивые UML По полдня и я люблю, это так приятно…
Допустим вы спроектировали поле ФИО длиной 50 знаков. И таких вещей — 100500 штук.
Кодировку выбрали для данных cp1251, и т.д.
А стали через год продукт забивать — оказывается, ЖИВЫЕ данные не влазят в это поле, китайские символы особенно. И такого всего менять по «суперспроектированной крутой» программе — не перечесть.
Поэтому чтобы избежать переписывания с нуля, нужны итерации. И постоянная работа на живых данных, постоянная, с первого месяца программы.
Иначе, увы, не работает. А рисовать красивые UML По полдня и я люблю, это так приятно…
Ок, Беларусь. Мощная страна.
Извините, если вас задело. Я писал перед сном и это просто, по сути дела, поток мыслей под эмоцией.
А эмоция была такая потому, что опыт весь мой восстает против вывода. Читаешь отличную статью, начинаешь уважать автора, и тут такой вывод.
По профессии я исполнитель на всех инструментах — жнец, жрец и на дуде игрец. В последние годы занимаюсь управлением проектами. Опыт есть, когда люди проектируют сложно и ничего не достигают — проект не выводится на рынок, или уже не нужен, когда выводится.
Так как мы программы пишем в 90% случаев для кого-то, то нужно учитывать бизнес-реалии. А бизнес реалии именно таковы — в большинстве сфер требования сначала нужно обкатать на живых прототипах, сделанных на скорую руку, и потом уже, получив знания предметной области, experience так сказать, уже делать верную версию.
В мегасофте, конечно, проектируют сразу. Под самолеты автопилоты. Или софт под искусственное дыхание или работу сердца. Там, конечно, нельзя так.
Но в веб-проектах, в софте и т.д. можно и нужно итерировать
Извините, если вас задело. Я писал перед сном и это просто, по сути дела, поток мыслей под эмоцией.
А эмоция была такая потому, что опыт весь мой восстает против вывода. Читаешь отличную статью, начинаешь уважать автора, и тут такой вывод.
По профессии я исполнитель на всех инструментах — жнец, жрец и на дуде игрец. В последние годы занимаюсь управлением проектами. Опыт есть, когда люди проектируют сложно и ничего не достигают — проект не выводится на рынок, или уже не нужен, когда выводится.
Так как мы программы пишем в 90% случаев для кого-то, то нужно учитывать бизнес-реалии. А бизнес реалии именно таковы — в большинстве сфер требования сначала нужно обкатать на живых прототипах, сделанных на скорую руку, и потом уже, получив знания предметной области, experience так сказать, уже делать верную версию.
В мегасофте, конечно, проектируют сразу. Под самолеты автопилоты. Или софт под искусственное дыхание или работу сердца. Там, конечно, нельзя так.
Но в веб-проектах, в софте и т.д. можно и нужно итерировать
В какой-то степени обкатка прототипа проходила в данном примере на старой версии. И исходя из старой версии продукта, то есть прототипа, проектировался новый. Бизнес-реалии таковы, что продукт востребован на рынке, насколько мне известно от моего клиента. Объясню почему. Основной фишкой должно было быть именно распознавание. Так как у других конкурентов оно очень слабое. В нашем же случае, мне было поручено разработать не просто алгоритм поиска, а алгоритм, который сможет распознавать строительные элементы с точностью в среднем не ниже 94-96%. Так прописано в договоре. И сейчас, когда продукт выходит на рынок у него есть одно очень важное конкурентное преимущество — это точность поиска. А это основной козырь программы.
Насчет сложного проектирования — я тут полностью с Вами согласен. Если Вы посмотрите мой 7 пункт, то там написано, что не надо углубляться в проектном решении настолько, чтобы пытаться описать все возможные вещи, которые будут в проекте. Это невозможно! Так как постоянно какие-то мелкие фишки добавляются в проект и их всех предусмотреть невозможно. Самое главное — это правильно спроектировать ядро продукта, а только потом, по ходу дела, то есть разработки проектировать новые дополнительные вещи. См. 1 пункт. Масштабируемость и гибкость. Спроектировал ядро, закодил его, а потом потихоньку подключай к нему новые фишки. Главное, чтобы ядро было правильно и грамотно спроектировано.
Насчет сложного проектирования — я тут полностью с Вами согласен. Если Вы посмотрите мой 7 пункт, то там написано, что не надо углубляться в проектном решении настолько, чтобы пытаться описать все возможные вещи, которые будут в проекте. Это невозможно! Так как постоянно какие-то мелкие фишки добавляются в проект и их всех предусмотреть невозможно. Самое главное — это правильно спроектировать ядро продукта, а только потом, по ходу дела, то есть разработки проектировать новые дополнительные вещи. См. 1 пункт. Масштабируемость и гибкость. Спроектировал ядро, закодил его, а потом потихоньку подключай к нему новые фишки. Главное, чтобы ядро было правильно и грамотно спроектировано.
Да. Но вы же все равно испытывали распознавание.
Вон, писали — библиотека PictureBox плохо варит большие картинки, она не крокодил с километровой пастью, чтобы их на раз-два глотать. Значит, уже имели опыт работы на живых данных (либо читали).
Так и распознавание. Наверняка не писали целый месяц мега-алгоритм, чтобы лишь потом запустить его и понять, что он в принципе не работает. Итерировали, пробовали на картинках, по-любому.
То есть вы понимаете суть. Но в итоге посыл именно такой (как я его прочитал) — что надо сразу круто проектировать, а не бросаться делать. По сути дела, начинать рефакторинг и неизбежный premature optimization (которая, как известно, is a root of evil), не имея еще работающего прототипа. Вместо этого я говорю, что посыл и вывод должен быть такой, что нужно итерировать обязательно, и тестировать на живых данных.
И РЕФАКТОРИТЬ!!! Основная беда проекта в том, как я понимаю, что балбесы просто были дилетантами, кто его писал, и не рефакторили. Вот и все.
Вон, писали — библиотека PictureBox плохо варит большие картинки, она не крокодил с километровой пастью, чтобы их на раз-два глотать. Значит, уже имели опыт работы на живых данных (либо читали).
Так и распознавание. Наверняка не писали целый месяц мега-алгоритм, чтобы лишь потом запустить его и понять, что он в принципе не работает. Итерировали, пробовали на картинках, по-любому.
То есть вы понимаете суть. Но в итоге посыл именно такой (как я его прочитал) — что надо сразу круто проектировать, а не бросаться делать. По сути дела, начинать рефакторинг и неизбежный premature optimization (которая, как известно, is a root of evil), не имея еще работающего прототипа. Вместо этого я говорю, что посыл и вывод должен быть такой, что нужно итерировать обязательно, и тестировать на живых данных.
И РЕФАКТОРИТЬ!!! Основная беда проекта в том, как я понимаю, что балбесы просто были дилетантами, кто его писал, и не рефакторили. Вот и все.
Про алгоритм распознавания — не сыпьте соль на рану. Я его писал что-то около месяца. Но если говорить про обкатку, то да. Была куча эталонных картинок, то есть живых данных, на которых он и тестировался. Обкатка велась чуть ли не круглые сутки, так как это и есть сердце программы по сути, и сбоев быть не должно.
>>Вместо этого я говорю, что посыл и вывод должен быть такой, что нужно итерировать обязательно, и тестировать на живых данных. И РЕФАКТОРИТЬ!!!
Я это и подразумевал. Так как эталонные данные зачастую не совпадаю с реальными. На моем примере — это было так. Мы тестировали алгоритм на планах одной компании и было все круто, результат зашкаливал. Показатели были неимоверными. Но только мы попробовали на планах другой компании — результат был, мягко говоря не очень. А все из-за того, что в алгоритме есть с десяток параметров, которые мы настроили для одного типа планов и там все было красиво и точно, а для другого типа эти параметры не подходили абсолютно. Так что обкатка на реальных данных обязательна.
>>Основная беда проекта в том, как я понимаю, что балбесы просто были дилетантами, кто его писал, и не рефакторили.
Да. Это основная беда.
>>Вместо этого я говорю, что посыл и вывод должен быть такой, что нужно итерировать обязательно, и тестировать на живых данных. И РЕФАКТОРИТЬ!!!
Я это и подразумевал. Так как эталонные данные зачастую не совпадаю с реальными. На моем примере — это было так. Мы тестировали алгоритм на планах одной компании и было все круто, результат зашкаливал. Показатели были неимоверными. Но только мы попробовали на планах другой компании — результат был, мягко говоря не очень. А все из-за того, что в алгоритме есть с десяток параметров, которые мы настроили для одного типа планов и там все было красиво и точно, а для другого типа эти параметры не подходили абсолютно. Так что обкатка на реальных данных обязательна.
>>Основная беда проекта в том, как я понимаю, что балбесы просто были дилетантами, кто его писал, и не рефакторили.
Да. Это основная беда.
ИМХО Coord всё верно сказал. Он попытался сказать, что без индийского говнокода у вас не получилось бы относительно быстро спроектировать грамотную архитектуру. Потому что для любого более-менее сложного продукта сначала необходим прототип, который в 99% случаев надо выкинуть, собраться с мыслями и выкинуть…
Можете рассказать про объем кода старого и нового проекта: кол-во строк кода, число классов?
Заодно спрошу у Александра.
Вы для распознавания использовали EmguCV? Какой фреймворк для unit-тестов? NUnit? Побольше технических сведений, интересно же!
Вы для распознавания использовали EmguCV? Какой фреймворк для unit-тестов? NUnit? Побольше технических сведений, интересно же!
Для распознавания использовался собственный алгоритм. Я не могу раскрыть всех его тех. деталей, но могу рассказать о результатах его работы. По проведенным тестам средняя точность в районе 90%. Это если считать и сложный и простые символы и текст. Но в целом, по подавляющему большинству символов, алгоритм показывает точность 94-96% и выше. Средняя скорость поиска одного символа на стандартном плане 5400х3600 пикселей, 30-40 сек. в зависимости от параметров самого символа и плана. Но у меня в планах довести алгоритм до 15 сек, сохранив точность.
Для тестов использовался NUnit.
Для тестов использовался NUnit.
Ну Вы же наверняка не работали с изображением напрямую, а использовали какую-то библиотеку для разбора графики, вот я и хотел спросить что Вы использовали. Или Вы не можете этого рассказать из-за NDA?
Ещё хотел бы спросить:
1. А какие части системы Вы покрывали тестами в NUnit'e?
2. Используете ли Вы какую-то интеграцию Visual Studio и NUnit?
3. Какую редакцию Visual Studio Вы использовали при разработке?
Спасибо, Александр!
1. А какие части системы Вы покрывали тестами в NUnit'e?
2. Используете ли Вы какую-то интеграцию Visual Studio и NUnit?
3. Какую редакцию Visual Studio Вы использовали при разработке?
Спасибо, Александр!
Одним из условий разработки было не использовать чужие проекты. А реализовать именно свой алгоритм распознавания и обработки. На это ушло чуть больше месяца. Все писалось с нуля и не использовалось ничего побочного и дополнительного.
NUnit'ом я покрывал ту часть, которая непосредственно отвечает за обработку, распознавание, фильтрацию, шумоподавление и т.д изображений.
Дf я использую интеграцию NUnit
MS VS 2010
А за чем Вам вся эта инфа?
NUnit'ом я покрывал ту часть, которая непосредственно отвечает за обработку, распознавание, фильтрацию, шумоподавление и т.д изображений.
Дf я использую интеграцию NUnit
MS VS 2010
А за чем Вам вся эта инфа?
Сказать точно не могу по количеству строк кода. Но в старой версии код был в районе ~250 классов. В новой в районе 180.
Знаете, пункт 6 (Копипаст) немного пугает. При правильном проектировании у Вас не должно возникать даже желания что-то копипастить. А если все же возникло, значит, уже пора заняться рефакторингом.
В посте не хватает вот этой картинки:
Сейчас в похожей ситуации, вот только шефа уговорить переписать не могу(
Простите, не верно. То, что люди пишут совсем г… нокод, — бывает и часто. Но средства борьбы ваши тоже не верные.
По порядку:
1. Архитектура БД и классов. Худший из способов — это строить архитектуру до написания кода. Опытному программисту сам код по разным показателям подсказывает, где лажа и что можно изменить. Выбирая листочки или UML — вы выбираете другой язык для моделирования — не язык программирования. Графические языки иногда более наглядны, но всегда более ущербны. И часто не могут показать лажу. Потом, один из главных принципов ООП — скрывание внутренностей — т.е. инкапсуляция. UML нарушает этот принцип по полной, делая анатомический разрез. Код не является настолько иногда наглядным как UML. Но как раз в этом его сила — он стимулирует писать, отражая более прямым образом суть. Цель — код должен читаться легко и понятно, как книга, которая описывает, что должно выполняться.
UML — хорошее средство документирования для более быстрой передачи знаний другим программистам о продукте. Но такая документация все же делается после, а не до. Проектировать так — плохо.
Хотя, не буду однозначен, проектировать на листочках ручкой можно и полезно, но очень грубо. Не подробно, развешивая на стену все зависимости. А только на следующий этап.
2. Переменные, методы и комментарии. Переменные и методы да, обязаны называться как надо. В итеративной разработке именно поэтому они часто переименовываются. Но замечания по поводу комментариев. Комментарии — это «естественный» язык. Сам код надобно писать так, чтобы он отражал то, о чем он написан. Не какие-то реализации, а смысл. Комментарии — это параллельно ведется на другом языке описание. Если рука тянется писать комментарии — значит лажа в коде, он не выполняет своей функции — ясного изложения мыслей. Второй минус комментариев — это язык, который не имеет никакого отношения к продукту, к его компиляции (как и UML), а значит это дополнительная вещь, которая по сути дублирует логику и требует еще и поддержки. При этом поддержка эта сложнее, чем поддержка кода. Потому что у вас нет средства компиляции и проверки соотвествия требованиям.
Я говорю не обо всех комментариях, а о комментариях внутри методов. Комментрарии, описывающие классы или методы — полезны. Но опять же, они не должны брать на себя функцию объяснения, что делает класс, который называется как попало и из его названия ничего не скажешь.
Иногда комментарии в коде нужны — бывает, что код подвергался оптимизации и уже не прямо выражает смысл. Или просто выбран сложный алгоритм. Но всё же вот так — с комментариями нужно быть осторожным, они ведутся по остаточному принципу, когда другие средства повышения читаемости кода не дали результата.
3. Копипаст. Проблема копипаста полезна для понимания рефакторинга. Представьте, что у вас уже есть код и в нем есть похожие куски. Вот, самое время подумать, возможно есть лажа. И вынести в отдельный метод. Классика и наверное многие возмутятся, к чему я это пишу. А пишу я к тому, что я не сторонник проектирования наперед. Проблемы решаются по мере поступления. А у вас подход — решить всё в воображении и предвидеть, что понадобится. И вы проблему копипаста рассматриваете — как проблему недопущения копипаста. Я рассматриваю, как проблему исправления копипаста. Если код повторяется два раза — сингнал рефакторить. При этом он должен повториться два раза. А не «не должен вообще».
Решил написать комментарий, потому что сейчас страдаю от чрезмерной тяги людей архитектурить. При этом наперед. Когда простая задача по смыслу породила больше 20 классов, каждый минимум на две страницы. Хотя как по мне, кода должно быть максимум на две страницы. Аргументируют это так: чтобы потом можно было просто писать, не задумываясь об архитектуре.
Вот как раз, теперь и потом придется задумываться постоянно. Не было во Вселенной ни единой уже создавшейся причины писать столько кода. И глючного, как и всегда бывает.
По порядку:
1. Архитектура БД и классов. Худший из способов — это строить архитектуру до написания кода. Опытному программисту сам код по разным показателям подсказывает, где лажа и что можно изменить. Выбирая листочки или UML — вы выбираете другой язык для моделирования — не язык программирования. Графические языки иногда более наглядны, но всегда более ущербны. И часто не могут показать лажу. Потом, один из главных принципов ООП — скрывание внутренностей — т.е. инкапсуляция. UML нарушает этот принцип по полной, делая анатомический разрез. Код не является настолько иногда наглядным как UML. Но как раз в этом его сила — он стимулирует писать, отражая более прямым образом суть. Цель — код должен читаться легко и понятно, как книга, которая описывает, что должно выполняться.
UML — хорошее средство документирования для более быстрой передачи знаний другим программистам о продукте. Но такая документация все же делается после, а не до. Проектировать так — плохо.
Хотя, не буду однозначен, проектировать на листочках ручкой можно и полезно, но очень грубо. Не подробно, развешивая на стену все зависимости. А только на следующий этап.
2. Переменные, методы и комментарии. Переменные и методы да, обязаны называться как надо. В итеративной разработке именно поэтому они часто переименовываются. Но замечания по поводу комментариев. Комментарии — это «естественный» язык. Сам код надобно писать так, чтобы он отражал то, о чем он написан. Не какие-то реализации, а смысл. Комментарии — это параллельно ведется на другом языке описание. Если рука тянется писать комментарии — значит лажа в коде, он не выполняет своей функции — ясного изложения мыслей. Второй минус комментариев — это язык, который не имеет никакого отношения к продукту, к его компиляции (как и UML), а значит это дополнительная вещь, которая по сути дублирует логику и требует еще и поддержки. При этом поддержка эта сложнее, чем поддержка кода. Потому что у вас нет средства компиляции и проверки соотвествия требованиям.
Я говорю не обо всех комментариях, а о комментариях внутри методов. Комментрарии, описывающие классы или методы — полезны. Но опять же, они не должны брать на себя функцию объяснения, что делает класс, который называется как попало и из его названия ничего не скажешь.
Иногда комментарии в коде нужны — бывает, что код подвергался оптимизации и уже не прямо выражает смысл. Или просто выбран сложный алгоритм. Но всё же вот так — с комментариями нужно быть осторожным, они ведутся по остаточному принципу, когда другие средства повышения читаемости кода не дали результата.
3. Копипаст. Проблема копипаста полезна для понимания рефакторинга. Представьте, что у вас уже есть код и в нем есть похожие куски. Вот, самое время подумать, возможно есть лажа. И вынести в отдельный метод. Классика и наверное многие возмутятся, к чему я это пишу. А пишу я к тому, что я не сторонник проектирования наперед. Проблемы решаются по мере поступления. А у вас подход — решить всё в воображении и предвидеть, что понадобится. И вы проблему копипаста рассматриваете — как проблему недопущения копипаста. Я рассматриваю, как проблему исправления копипаста. Если код повторяется два раза — сингнал рефакторить. При этом он должен повториться два раза. А не «не должен вообще».
Решил написать комментарий, потому что сейчас страдаю от чрезмерной тяги людей архитектурить. При этом наперед. Когда простая задача по смыслу породила больше 20 классов, каждый минимум на две страницы. Хотя как по мне, кода должно быть максимум на две страницы. Аргументируют это так: чтобы потом можно было просто писать, не задумываясь об архитектуре.
Вот как раз, теперь и потом придется задумываться постоянно. Не было во Вселенной ни единой уже создавшейся причины писать столько кода. И глючного, как и всегда бывает.
Что интересно — фантазия у людей, которые не отталкиваются от требований — неистощима. Такое иногда пишут в погоне за гибкостью.
Вот, в моем проекте написали класс, который является «сообщением». В него вставили тип и передают список параметров object. Уверен, что гордятся этим. Недавнее изобретение. А то, что нарушилась статическая типизация и забили болт на шарп, как таковой, создавая «новое измерение» в сверхгибком параллельном и непересекающимся с шарпом пространстве — никто не думал.
Кстати, страдаю как раз по причине того, что ищу баги в этом чужом коде второй день. И это непросто. Не знаю, как людей можно отучить от целенаправленного нанесения вреда.
Архитектура — это для меня в последнее время самое злое ругательство.
Вот, в моем проекте написали класс, который является «сообщением». В него вставили тип и передают список параметров object. Уверен, что гордятся этим. Недавнее изобретение. А то, что нарушилась статическая типизация и забили болт на шарп, как таковой, создавая «новое измерение» в сверхгибком параллельном и непересекающимся с шарпом пространстве — никто не думал.
Кстати, страдаю как раз по причине того, что ищу баги в этом чужом коде второй день. И это непросто. Не знаю, как людей можно отучить от целенаправленного нанесения вреда.
Архитектура — это для меня в последнее время самое злое ругательство.
Понимаете, я не пытался спроектировать весь код. Я спроектировал масштабируемое ядро. Я про это писал где-то выше. Еще Вы писали про тягу людей архитектурить. Я согласен, когда проект начинает трещать на стадии разработки архитектуры. То есть когда пытаются все предсказать и запланировать — это превращается в бесконечное проектирование. Но я спроектировал и главное реализовал все задуманное. Тут с какой стороны подойти.
Про кривой код. Он же индийский. Расскажу пример из своей жизни. Когда я учился в университете, у меня был один одногруппник. Мнил из себя, как говорят в Одессе «Шо ты, Роза!». То есть он мнил из себя гения. Окончил с красным дипломом и т.д. и т.п. Так вот, этот товарищ на 4-м курсе пытался устроится в одну крупную компанию. Там естественно ему дали тестовое задание. Задание простое — несколько классов однотипных объектов, по определенным критериям их надо было сортировать и группировать, а результат выводить на экран. Все просто. Так вот, этот гений неделю бился над решением, а потом попросил ему подсказать. Писать задачу на Java мне было влом, так как ни эклипса, ни нетбинса под рукой не было, а выкачивать не хотелось, я предложил ему такой вариант: я пишу на шарпе, а он просто конвертит в джаву. Вроде бы все просто. Я за пару часов написал это тестовое задание, отдал ему, он за три дня это все сконвертил. Не дал мне на проверку и пошел. В компанию. И естественно его там приняли. Через некоторое время он мне дал свой исходник. И я выпал в осадок. Там не то что код был плохим — он был ужасным! Не буду расписывать все прелести того кода, а просто подведу итог. Если наши краснодипломники, которые учатся на программистов 5 лет — мега быдлокодеры. То что говорить об индусах, у которых есть 3х месячные курсы и опа — ты программист. Людей не надо переучивать — они либо это сами делают, либо они через какое-то время не смогут дальше работать нормально в компании.
Про кривой код. Он же индийский. Расскажу пример из своей жизни. Когда я учился в университете, у меня был один одногруппник. Мнил из себя, как говорят в Одессе «Шо ты, Роза!». То есть он мнил из себя гения. Окончил с красным дипломом и т.д. и т.п. Так вот, этот товарищ на 4-м курсе пытался устроится в одну крупную компанию. Там естественно ему дали тестовое задание. Задание простое — несколько классов однотипных объектов, по определенным критериям их надо было сортировать и группировать, а результат выводить на экран. Все просто. Так вот, этот гений неделю бился над решением, а потом попросил ему подсказать. Писать задачу на Java мне было влом, так как ни эклипса, ни нетбинса под рукой не было, а выкачивать не хотелось, я предложил ему такой вариант: я пишу на шарпе, а он просто конвертит в джаву. Вроде бы все просто. Я за пару часов написал это тестовое задание, отдал ему, он за три дня это все сконвертил. Не дал мне на проверку и пошел. В компанию. И естественно его там приняли. Через некоторое время он мне дал свой исходник. И я выпал в осадок. Там не то что код был плохим — он был ужасным! Не буду расписывать все прелести того кода, а просто подведу итог. Если наши краснодипломники, которые учатся на программистов 5 лет — мега быдлокодеры. То что говорить об индусах, у которых есть 3х месячные курсы и опа — ты программист. Людей не надо переучивать — они либо это сами делают, либо они через какое-то время не смогут дальше работать нормально в компании.
Так 5 лет учебы мало дают. Только после 5 лет работы полноценный рабочий день, при этом в хорошем колективе, люди понемногу приходят в себя.
А образование программистов — портит людей. Мне повезло, я по образованию не программист. Но потом даже преподавал программирование в ВУЗе.
Что я увидел.
1. Низкий уровень преподавания колег. Очевидно, что люди, умеющие хоть как-то программировать, не будут за такие копейки работать в универе. Остаются те, кто не может. Поэтому студенты брошены сами на себя. После окончания учебы программистами (нормальными) становятся только те, кто занимался самообучением.
2. Плохо устроена программа обучения. За пять лет нужно изучить много направлений. По сути, не получается ни одного. Я учился не на программиста, но предмет был несколько лет. Тупо один паскаль. Но только благодаря такому количеству часов мы почти Кнута прошли. Стуктуры данных и алгоритмы. У программистов на предмет ООП столько, что не успевают толком до виртуальных методов дойти.
Плюс слабая математическая подготовка. Это всё не только от уровня преподавания, а от распределения часов.
Т.е. выходят люди из вузов — база плохая. Но далее, работа и желание развиваться — всё поправит. Но и тут есть несколько этапов (сужу по себе):
1. Человек должен научиться писать программы хоть как-то. Циклы, ветвления, алгоритмы. Хорошо, если эта база хорошо проработана, но не важно. После этого человек ощущает, что может написать всё и часто такие устраиваются уже на работу. Что-то пишут, но говнокод пока.
2. Изучают паттерны, примеры реализованных проектов и т.д. Важный этап в обучении. Но сам способ обучения — человеку предлагают решения на примерах. И у него складывается ощущение, что надо в любой задаче сразу увидеть архитектуру, добиваться гибкости, использовать побольше паттерны. Часто люди изучают UML и упираются в то, что надо разрабатывать архитектуру ДО. И всё правильно прорисовать. Ну и куча ереси рождается — жалуются, что требования меняются, а они не должны, что в правильных компаниях такого не допустят, что начальник-архитектор должен всё сам разрисовывать, а кодерам давать схемы, тогда будет рай.
3. Возврат назад в природу. Отказ от паттернов и архитектуры. Это не шутка. Этот этап — доработка навыков кодирования и получение знаний о кодировании. Т.е. книги о рефакторинге, тест-драйвинг девелопменте, домейн-драйвинг девелопменте (все книги прорабатываются критично), теории функционального программирования. У человека появляются навыки, как правильно выходить из той или иной ситуации. Как правильно решать возникшие конкретные задачи. Как не дублировать данные или код. Какой код плохой. И расширяется список способов оценки кода. Когда у человека появятся навыки кодирования и оценки, он перестает бояться кодировать без тщательного планирования.
Где-то так. Главное на втором этапе не застрять. Грубо проектировать масштабируемое ядро на бумаге — конечно можно. Тут вопрос баланса, что такое грубо, а что нет. В идеале, возможно, есть такие джедаи, которые вообще не рисуют и даже не воображают. А умеют доращивать код, доращивая юз-кейсы. Возможно, к этому надо стремиться, но ни я таких людей не встречал, ни сам так в чистом виде не пробовал. Минимальное ядро всё таки проектировал.
А образование программистов — портит людей. Мне повезло, я по образованию не программист. Но потом даже преподавал программирование в ВУЗе.
Что я увидел.
1. Низкий уровень преподавания колег. Очевидно, что люди, умеющие хоть как-то программировать, не будут за такие копейки работать в универе. Остаются те, кто не может. Поэтому студенты брошены сами на себя. После окончания учебы программистами (нормальными) становятся только те, кто занимался самообучением.
2. Плохо устроена программа обучения. За пять лет нужно изучить много направлений. По сути, не получается ни одного. Я учился не на программиста, но предмет был несколько лет. Тупо один паскаль. Но только благодаря такому количеству часов мы почти Кнута прошли. Стуктуры данных и алгоритмы. У программистов на предмет ООП столько, что не успевают толком до виртуальных методов дойти.
Плюс слабая математическая подготовка. Это всё не только от уровня преподавания, а от распределения часов.
Т.е. выходят люди из вузов — база плохая. Но далее, работа и желание развиваться — всё поправит. Но и тут есть несколько этапов (сужу по себе):
1. Человек должен научиться писать программы хоть как-то. Циклы, ветвления, алгоритмы. Хорошо, если эта база хорошо проработана, но не важно. После этого человек ощущает, что может написать всё и часто такие устраиваются уже на работу. Что-то пишут, но говнокод пока.
2. Изучают паттерны, примеры реализованных проектов и т.д. Важный этап в обучении. Но сам способ обучения — человеку предлагают решения на примерах. И у него складывается ощущение, что надо в любой задаче сразу увидеть архитектуру, добиваться гибкости, использовать побольше паттерны. Часто люди изучают UML и упираются в то, что надо разрабатывать архитектуру ДО. И всё правильно прорисовать. Ну и куча ереси рождается — жалуются, что требования меняются, а они не должны, что в правильных компаниях такого не допустят, что начальник-архитектор должен всё сам разрисовывать, а кодерам давать схемы, тогда будет рай.
3. Возврат назад в природу. Отказ от паттернов и архитектуры. Это не шутка. Этот этап — доработка навыков кодирования и получение знаний о кодировании. Т.е. книги о рефакторинге, тест-драйвинг девелопменте, домейн-драйвинг девелопменте (все книги прорабатываются критично), теории функционального программирования. У человека появляются навыки, как правильно выходить из той или иной ситуации. Как правильно решать возникшие конкретные задачи. Как не дублировать данные или код. Какой код плохой. И расширяется список способов оценки кода. Когда у человека появятся навыки кодирования и оценки, он перестает бояться кодировать без тщательного планирования.
Где-то так. Главное на втором этапе не застрять. Грубо проектировать масштабируемое ядро на бумаге — конечно можно. Тут вопрос баланса, что такое грубо, а что нет. В идеале, возможно, есть такие джедаи, которые вообще не рисуют и даже не воображают. А умеют доращивать код, доращивая юз-кейсы. Возможно, к этому надо стремиться, но ни я таких людей не встречал, ни сам так в чистом виде не пробовал. Минимальное ядро всё таки проектировал.
Да, отказ от паттернов — я имею ввиду, от желания их применять. Они, конечно, используются. Куда ж без стратегии, фабрик, и синглтона. Но паттерны часто сами рождаются при рефакторинге и оценке кода. Естественным образом. И вот, эти три паттерна, наверное, часто используются, остальные гораздо реже или вообще не используются. Код должен отвечать критерию простоты, а не гибкости.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Правила разработки сложных систем. История одного проекта