Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Хотя и все отлично работало, но от структуры кода неприятно становилось даже вам.
Считали ли вы это совершенно нормальным или старались переделать и изменить?
Дійсно, 99.99% оупенсорса — дуже якісні і повноцінні програми, якже. Комерційні конкуренти тихо кусають лікті в сторонці.Ну навіщо сарказм? GNU не народився у середовищі школярів-аматорів — це скоріше акт доброї волі від прфі — усіляких Столменів, Танебаумів etc. Це так чи інакше спеціалісти дуже високого гатунку. Колиж якийсь малалєтній кул-хацкер начитається книжок та почне наполегливо та кропітко працювати на GNU ідею — то сам стає профі (той же Торвальдс) — інтерес+наполеглевість+талант зроблять своє діло...
P.S.: тут вже почали, я так бачу, сперичатися про тести — так вони ніяк не виправлять криву архітектуру...
TheRealAnonymous 2 час. назад
> юнит-тест тестирует юниты (а юнит это чаще всего метод)Цікаво, що заважає написати тест, який тестує те, що треба, а не обов’язково лише один метод, об’єкт, чи клас?
Цена? Заказчику важно побыстрее и подешевле. А на разработку хорошего юнит-теста, а не просто для галочки, нужно затратить больше чем на написание самого рабочего кода.
Цікаво, що заважає написати тест, який тестує те, що треба, а не обов’язково лише один метод, об’єкт, чи клас?
Мусье слышал об изменении требований в самый неподходящий момент? Когда код, писанный в течении недель, приходится рефакторить, или что значительно чаще, ставить костыли и подпорки, потому что стоимость рефакторинга иногда слишком значительна. Проблема в том, что надо всегда балансировать между качеством и стоимостью)Мусье слышал о юнит-тестах?
FYI: юнит-тест тестирует юниты (а юнит это чаще всего метод), протестировав метод нет гарантии что вся иерархия классов, или подсистема приложения работает абсолютно корректно, и уж тем более спроектирована правильно.
А у меня все время выходит один гавнокод: (Не смотря на то что все работает, никогда не удается избежать ошибок проектирования классов: (
Они помогают только в самых простых случаях, когда все можно построить однозначное соответствие между входными и выходными данными.Мусье слышал о юнит-тестах?
Вот как вы построите юнит тест на обход определённого бага который встречается на 1% систем пользователей из-за конфликта с определённым ПО? Конечно можно сказать вот у нас есть технические требования к системе и идите гуляйте у которых их нет, но это утрата клиентов.
Речь ведь в общем то не об ошибках. Говнокод получается когда аккуратно пишеш какой то модуль или прогу, а потом через какое то время возникает необходимость его дописать, потом ещё раз дописать — наращивается мясо. После пятёрки таких апгрейдов любой код превратится в гавнокод, и хочется его порефакторить, но ведь нельзя... потому что хоть это и гавнокод, но он протестирован и работает, а какая фича поламается после рефакторинга не известно. Так что, там где замешаны деньги об искусстве и речи не может быть.
Вообще говнокод это нормально, потому что мы все люди и мы не в состоянии написать идеальный код и идеальные программы. Мы все равно делаем ошибки, и это естественный процесс. Целые науки появились, которые иеперь изучают, как сделать говнокод лучше, качественнее, дешевле...
А вот еще Егор Егоров о говнокоде
Прос ебя скажу: стыдно было по-первах. Потом понял, что старый свой говнокод — это нормально. И чужой — нормально. Есть понимание процесса и в текущий момент нужно принять решение — переписать начисто либо же подставить очередной костыль.
TheRealAnonymous 20 час. назад
> Доречі ще одна причина чому GNU opensource “рулить” — гавнокод вічний супутник комерції, а от проект “для душі” навіть досить значний за обсягом — який сенс розробляти не якісно?Дійсно, 99.99% оупенсорса — дуже якісні і повноцінні програми, якже. Комерційні конкуренти тихо кусають лікті в сторонці.
Основное преимущество коммерческих — в удобстве для пользователей-казуалов. Вот, например, даже мне иногда приятнее настройки произвести мышкой, чем ковырять конфиги и читать документацию. А все GNU пишется для программистов (для себя), не для пользователей (клиентов). Хотя если использовать в качестве библиотек, то чаще всего даже лучше по качеству коммерческого кода
Дійсно, 99.99% оупенсорса — дуже якісні і повноцінні програми, якже. Комерційні конкуренти тихо кусають лікті в сторонці.
+1:)Антон Мартыненко
Доречі ще одна причина чому GNU opensource «рулить» — гавнокод вічний супутник комерції, а от проект «для душі» навіть досить значний за обсягом — який сенс розробляти не якісно? Це я маю на увазі True GNU, куди не пропадає вже сам GCC — як набільший прокт open source і вже давно по-суті благодійно-коммерційний.
Гораздо реже бывает и то, что стыдно смотреть на старый код, но понимаешь, что тогда ты сделал всё, что мог, выше головы не прыгнешь. Обычно стыдно за код, который писался в новой сфере, впервые использовалась что-то новое и знаний не хватало для того, чтобы это спроектировать и написать с первого раза.
Конечно бывало, да и сейчас бывает. Иногда это из-за некоторых ограничений языка программирования (когда знаешь, что в Руби это выглядело бы элегантнее, а в шарпе к сожалению имеем, что имеем), иногда это из-за моих косяков. Стараюсь изменять, что изменить возможно. Ну и то же самое что и у Сергея Волошина — заметочка «не делать так в следущий раз».
Просто надо смириться с тем что вы пишите говнокод и просто стараться улучшить его качество. =) Да прибудет с вами Сила.
Нужно затаить злобу и расправиться с ним (кодом) в следущем проекте...Заказчика можно не трогать
В голову приходит что-то типа «не делать так в следующий раз».
Артём Грошевой 2 час. назадПрочитал недавно Фаулера «Рефакторинг» и мне перестало становиться стыдно. Я просто изменяю код, пока он мне не начнёт нравится)
Это все понятно. Здесь другое. Если заказчику все нравится, а тебе в архитектуре нет, но видно, что можно улучшить, то здесь как быть?
Прочитал недавно Фаулера «Рефакторинг» и мне перестало становиться стыдно. Я просто изменяю код, пока он мне не начнёт нравится)
druid III
Alexandr Gavriluk
TheRealAnonymous
am am
VG
Sergii Voloshyn
Михаил Старовойт
Mike Gorchak
Alexander Migal
Artem Groshevoy
20 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів