Посмотрел недавний код, выяснилось, что написал функцию на 700 строк.
Всё нормально работает.
Не в смысле отсутствия багов - это-то понятно. Нормально в смысле ошибок во время создания, сложности изменений и прочего.
Ещё раз убедился, что все те ужасы, которыми пугали бородатые гуру и зазнайки-профессора, - не более чем детские страхи. Просто код писать надо правильно.
Всё нормально работает.
Не в смысле отсутствия багов - это-то понятно. Нормально в смысле ошибок во время создания, сложности изменений и прочего.
Ещё раз убедился, что все те ужасы, которыми пугали бородатые гуру и зазнайки-профессора, - не более чем детские страхи. Просто код писать надо правильно.
no subject
Date: 2018-03-09 10:02 am (UTC)У меня один раз был main() на две тысячи LOC :)
no subject
Date: 2018-03-09 05:33 pm (UTC)no subject
Date: 2018-03-09 05:34 pm (UTC)Я в сях подобные большие свичи заменял таблицей условных переходов. Читать легче, да и конвейер проца лишний раз не надо перезагружать.
no subject
Date: 2018-03-09 05:58 pm (UTC)no subject
Date: 2018-03-09 03:56 pm (UTC)А откуда знаете, что правильно написано? (какие ваши доказательства).
А что, нарезать на осмысленные кусочки уже нельзя?
no subject
Date: 2018-03-09 05:07 pm (UTC)Рефакторинг - это маркетинговое название для исправления ошибок дизайна.
Во-первых, дизайн был отработан на прототипах.
Во-вторых, внесение любых изменений и добавлений не представляет никаких проблем.
А откуда знаете, что правильно написано?
Процесс разработки построен так, что решение развивается поэтапно, когда дальнейшее продвижение идёт после того, как все вопросы с предыдущего этапа сняты и ошибки устранены.
Если же баг какой попадается, на его поиск и устранение уходит минут пять максимум.
Короче, скучная бухгалтерская работа, никакой романтики.
А что, нарезать на осмысленные кусочки уже нельзя?
Зачем делать кусочки, если всё и так прекрасно осмысляется?
В данном случае это каскад процессов. Проще и логичнее держать их в одном контексте. (Кстати, потеря контекста - это слабость функционального программирования.)
Если понадобится что-то другое, можно разрезать/собрать в другом порядке и с другой гранулярностью. Но это уже будет другой софт для другой задачи.
no subject
Date: 2018-03-09 05:29 pm (UTC)И предложение использовать копипасту тоже радует.
Это все древняя культура, которая отсюда смотрится нелепой.
Ну и спасибо за рассказ, конечно. Обычно так в деталях это не вербализуют, а просто сообщают, что единственная истина дана говорящему свыше, в порядке жизненного опыта.
no subject
Date: 2018-03-09 06:03 pm (UTC)Вот и первое отличие. У меня не ощущения, у меня знания, основанные на широком пласте теории.
что вы слишком долго жили в Германии, и впитали
Это не абсорбция сквозь оболочку. Это результат серьёзного анализа, сбора информации, разнообразного опыта и многочисленных экспериментов.
Германия - это только одна из деталей мозаики. Не ключевая, но интересная.
Обычно так в деталях это не вербализуют,
Были заданы вопросы. Были даны ответы. Обижаться, что ответы не те, которые хочется, - это уже не солидно.
no subject
Date: 2018-03-09 08:19 pm (UTC)no subject
Date: 2018-03-09 08:45 pm (UTC)no subject
Date: 2018-03-11 07:23 pm (UTC)Очевидным образом вы на свой код не пытались через полгода смотреть. Write-only, ага.
no subject
Date: 2018-03-11 07:27 pm (UTC)Нет, конечно. Просто я умею делать правильно.
no subject
Date: 2018-03-11 09:04 pm (UTC)no subject
Date: 2018-03-18 01:57 pm (UTC)Вот... какраз думал как бы можно было бы переопределить написание программ,
в смысле САЗЕ, чтобы оперировать контекстами.
Что-то типа литерейт програминга, но в более диалоговой и подерживаемой компом манере.
no subject
Date: 2018-03-19 06:40 am (UTC)Что автор, который настаивает что "рефакторинг -- это ошибки дизайна",
хотя, новое отдельное слово понадобилось именно потому,
что это не ошибка -- это из-за того что высокий уровень программирования,
означат высокую же вариативность, то есть, что одну и ту же задачу можно решить многими способами и потому это ап ту програмер выбирать...
и иногда он как буриданов осел -- не может решить.
И это не бага, а фича -- потому что то же самое существует,
и не только в человеческой технике,
а например и в ДНК...
Ну и вы тоже.
Рефакторить код тела функции -- что там рефакторить? и главное -- для чего?
Я кода не видел, но вроде как верю автору,
что он не овсем тупой и копипастного дублирования там у него нет.
То есть, выделять в функции повтяющиеся куски кода не требуется,
а что ж еще тогда рефакторить?
Просто произвольным образом делить функцию на две, несколько?
Накуа?
Не будет ли это наоборот -- бэд практис?
no subject
Date: 2018-03-19 07:00 am (UTC)Следующий раз комментарий будет удалён.
И, вообще, стоит залогиниться, чтоб я каждый раз кнопку не нажимал.
и иногда он как буриданов осел -- не может решить
Не "как" и без "буриданов".
Если есть альтернативы, они проверяются или по литературе, или на прототипах. Если альтернатива выбрана плохо, это ошибка дизайна.
и главное -- для чего?
Функциональное программирование - это почти чистая математика. Небольшие изменения могут не только изменить производительность, но и коренным образом поменять поведение.
no subject
Date: 2018-03-20 11:17 am (UTC)\\Не "как" и без "буриданов".
\\Если есть альтернативы, они проверяются или по литературе, или на прототипах. Если альтернатива выбрана плохо, это ошибка дизайна.
По как литературе и по какми правилам?
Вы будете выбирать между тем как написать "++х" или "х=х+1"?
Это я так, чтобы самый просто пример выбрать,
и не скатится к холивару пробелов против табов и т.п.
Не знаю, почему вы не видите,
или считает необходимым не учитывать рефаторинг/стиль как отдельную сущность...
\\и главное -- для чего?
\\Функциональное программирование - это почти чистая математика. Небольшие изменения могут не только изменить производительность, но и коренным образом поменять поведение.
Вопрос вообще-то был вашему визави.
Вот есть тело функции, которое, так уже получилось, разрослось на 700 строк...
и нет в нем очевидного, напрашивающегося на рефакторинг:
дублирования кода, деления по смыслу и т.п. -- что его все равно "надо рефакторить"?
А смысл?
Рефакторинг ради рефакторинга?
Даже в ужерб читабельности и пониманию смысла?
А что до ФП... то я вообще не знаю, как они там собираются обеспечивать производительность???
Ну, за пределами "наш компилятор компилирует в натив не хуже Сишного".
В С ведь всегда остается вариант вылизать критическую функцию до предела -- накропать её на асме, с учетом всех кеш-миссов и пайплайнов,
и выиграть иногда даже 10%...
Вот я про КУДА читал, так там вообще все весело, и выигрышы могут быть вообще в разы.
А вот я бы хотел посмотреть на ФП реализацию компилятора для ГПУ...
вот почему ФПшники за ТАКИЕ задачине берутся, а? %)
no subject
Date: 2018-03-20 11:33 am (UTC)Такие мелочи не просто понятны, но и описаны даже в каждом втором стандарте. Не всегда обоснования разумные, но это совершенно стандартно.
Вот есть тело функции, которое, так уже получилось, разрослось на 700 строк...
Так не получилось. Так было надо. Возможность разбить функцию всегда проверяется, потому что это естественная тактика. В данном случае другие факторы были важнее.
no subject
Date: 2018-03-21 07:06 am (UTC)Дык... понятно что описаны.
Я ведь сам там же признал, что специально выбрал пример попроще.
Потому что моя цель -- не приводить здесь полный список возможных рефакторингов,
вы и сами вряд ли в подобном заинтересованы,
а продемонстрировать простую мысль -- рефакторинг это об изоморфных (с точки зрения функциональности) преобразованиях кода.
\\Так не получилось. Так было надо. Возможность разбить функцию всегда проверяется, потому что это естественная тактика. В данном случае другие факторы были важнее.
Дык... вот это выделенное и означает,
что рефакторинг вы -- делаете.
Но, в данном случае в нем нет необходимости.
Это ведь был камень в сторону вашего оппонента,
который почему-то подумал что рефакторинга вы не делаете в принцыпе,
и потому вам нужно (голословно, однако) доказывать...
не, не что его таки нужно делать...
а только какой вы ужасный редиска, что не хотите делать рефакторинг. %))
no subject
Date: 2018-03-21 10:34 am (UTC)Я не делаю рефакторинг. Потому что это слово описывает неосознанные попытки улучшений красивости "по запаху". Я нахожу и исправляю ошибки дизайна в полном осознании, что я делаю.
no subject
Date: 2018-03-21 11:02 am (UTC)Это понимать так, что вы и текст не редактируете?
Там, переименование переменных -- вот что, вы серьозно хотите утверждать что вот 100% ничего подобного не делаете?
\\Потому что это слово описывает неосознанные попытки улучшений красивости "по запаху".
Почему неосознанные?
Несомненно, некоторая часть рефакторинга, делается на основании представлений о "красивости"... потому что стиль.
Но отнюдь не все.
То же выделение метода... чтобы не ввязыватся здесь в холивар по ООП,
Выделять из тела функции другие функции, устранть дублирование кода -- это несомненно один из видов рефакторинга,
и так же несомненно, характерен не только для ООП, но и обычного структурного и функционального подходов.
А вот, представить себе, как можно редактиовать код ТАК,
чтобы ничего подобного не делать...
Это разве что набирать его в стиле cat > file
Другое дело, что хотелось бы... и давно,
иметь программистам средства анализа и рефакторинга кода,
которые бы (надежно) показывали зависимости между модулями,
"ошибки дизайна", предложение возможных вариантов и т.п.
\\Я нахожу и исправляю ошибки дизайна в полном осознании, что я делаю.
Гуд фор ю.
no subject
Date: 2018-03-20 11:08 am (UTC)что от вашей с Витом (а почитываю вас обоих довольно давно) дискуссии,
испытал жесткое разочарование.
Вы вроде старшие товарищи,
с опытом и регалиями, до которых мне еще лесом и лесом,
а завязались обсуждать такую чихню,
что и первокурсникам должно быть западло (ну, я наверное не знаю чего там обсуждают первокурсники программисты... я сам механик %) ).
Спасает тут разве что то,
что это довольно тонкие материи.
Действительно, если перенести его на сферу писательства (а кто-то утверждает, что программирование это творческий труд сравни писательскому...),
то
рефакторинг -- он соответствует СТИЛЮ,
а дизайн -- сути, сюжету...
Тут конечно надо понимать что это деление довольно условное,
оно в другое вполне переходит и друг на друга влияет.
Но.
Такие умудренные опытом люди, должны вроде бы понимать это и без напоминания залетных редисок-анонимов.
А тут, получается на вас классическая дихотомия физиков-лириков.
Вы настаиваете на примате стиля,
что мол всегда нужно писать высоким штилем...
даже если это кома сепарейтед табличка данных... сгенерированная одним процессом для прочтения в другом... и которая может попасть на глаза програмеру только весьма случайно -- то програмер по любому объязан залезть в неё и начать править... там пробелы на табы заменять и вайсе верса,
и так далее?
А ваш визави,
что мол имеет смысл только сюжет,
а качество его исполнения, стилистика -- это все от лукавого,
для графоманов.
Тру же писателям нужно не знание всяких вариантов и сттилей,
а исключительно учебник по граматике... и его -- достаочно. %)
Ну да, есть тут одна важная истина, которую мне видимо таки придется усвоить.
Что для того чтобы быть успешным программистом,
а то и прослыть опытным челом и гуру -- железобетонная самоуверенность просто необходима.
Всякие там сомнения, неуверенность в выбраном варианте кода, желание поделится и услышать релевантное мнение -- это все для слабаков.
Есть только два мнения -- мое, и неправильное (ТМ)
ЗЫ Там уже уважаемый Вит начал обижатся на вольности которые я тут себе позволил,
так что вообще может не расскринить...
да и я сам,
как уже говорил -- разочарован, и лучше мне прекращать подобные (не)дозволеные речи,
пока не полез совсем уже ядреный сарказм тролл-стайл (тоже себе, и тут стиль, да)
Спасибо старики за науку. Буду крутить её на ус. %((
ЗЗЫ И отдельный тут момент. На тему вашего ранее задикларированного разочарования "мурзилками которые ничему учится не хотят".
Да вот... видно ужо у кого и чему учится... неча на зеркало пенять.
no subject
Date: 2018-03-20 11:29 am (UTC)а дизайн -- сути, сюжету...
Стоит прочитать хотя бы одну книжку по стилю и хотя бы одну книжку по сценарному мастерству, чтобы понять, насколько это не в тему.
И не стоит забывать, что люди ведут дискуссию в контексте.
no subject
Date: 2018-03-21 07:19 am (UTC)И даже так, я там явно указал, что стиль имею в виду в отношении написания текстов... причем тут сценарное мастерство?
Ну а про контекст... может между вами существует, как подводна часть айсберга, обмен глубокими тайными смыслами...
но я могу коментировать только то что вижу и что могу понять.
Увы мне. %(
no subject
Date: 2018-03-21 10:26 am (UTC)Это слишком долго объяснять.
Извиняюсь
Date: 2018-03-21 11:04 am (UTC)Как я уже говорил, про стиль я говорил в смысле стиля аписания текста.
Каким образом сюда сценическое искуство... это явный совершеннейший оффтоп
no subject
Date: 2018-03-29 12:42 pm (UTC)no subject
Date: 2018-03-29 12:54 pm (UTC)Можем поговорирть тут детальнее?
Date: 2018-04-01 05:46 am (UTC)\\Конечно, это приводит к интересным разговорам. Например, про немецких программистов, или явлсяется ли кодирование главным этапом в процессе производства софта, или можно сначала думать. Но всё-таки ощущение, что я использую какой-то загадочный, не понятный для большинства язык.
Я-то сварщик не местный и всех тонкостей не знаю.
И мои аналогии "рефакторинг -- стиль, дизайн -- сюжет" может быть хромают... и на более чем оджну ногу.
Но по крайней мере у меня есть КМК понимание почему ИМЕННО так.
А вот проблема с пониманием у других -- по ходу та же что и у вас.
Вот и... думаю было бы общеполезно разобратся -- если бы мы смогли договорится до чего-то между собой, то это дало бы нам обоим некие ответы на наши вопросы.
Не так ли?
Так вот... что касается "рефакторинг -- стиль" и вашего замечания про сценическое искуство.
Я как уже говорил/признавал -- ни в каком сценическом искустве не замечен.
Но и посыл мой, касался редактиования текста ТОЛЬКО.
А там... хотя в целом возможная вариативность стилистики потенциально бесконечная (там текст можно и по вертикали, и готическим шрифтом и еще хз как),
но практически... в разрезе изобразительных средств при редактиовании ASCII кода...
стилистическое пространство вполне ограниченное.
Потому, его и имеет смысл обсуждать.
Тогда как дизайн... выраженный в тексте/коде (или вообще графике),
имеет гораздо большую концептуальную глубину.
Описанию дизайна/сценария, уже эти все стилистические изыски, не очень-то и мешают.
Точнее, мешают конечно, если даже элементарные вещи оформить в незнакомоу/неудобной стилистике -- например написать на китайском, да сверху вниз.
То это конечно же помешает пониманию.
Но.
Тут какраз и находится тот самй вопрос -- про конфликт формы и содержания.
Который, если перефразировать в рамках конткекста дискуссии.
Ваша позиция -- стиль/рефакторинг/форма это нинужна -- можно ограничить форму самыми простыми требованиями и этого будет достаточно -- что несомненно ПРАВИЛЬНО, минимализм формы, принцып КИСС они работают,
но...
Вашего же оппонента -- что используя возможности стиля/рефакторинга/вариативности формы -- можно и нужно добиватся соответствия между формой и содержанием, и даже возможо в сторону формы...
тож вряд ли поспоришь... только разве что, с неизбежным при такой постановке вопроса холиваром -- какая форма, какой стиль -- более правильные.
Меня в этом заботит, как уже ранее высказал -- почему вы двое таких умудренных, гораздо более умудренных опытом чем я,
этого не понимаете и не можете договорится...
и это не праздный, а самый что ни на есть насущный вопрос -- если уж вы не можете договорится, то что уже говорить обо мне... в общении с еще более простыми в этом вопросе робятами чем я.
no subject
Date: 2018-04-01 05:29 pm (UTC)Я не зря просил не использовать слово "рефакторинг". Если начать называть вещи своими именами, всё становится на свои места.
Вот и... думаю было бы общеполезно разобратся -- если бы мы смогли договорится до чего-то между собой, то это дало бы нам обоим некие ответы на наши вопросы.
Не так ли?
Не так. Мне это ничего не даст. Разговор изначально идёт о другом, а объяснять достаточно запутанные вещи, включая графический дизайн или сценарии для анимации мне совершенно влом.
...принцип КИСС они работают
Не советую летать на самолёте, в производстве которого использован принцип KISS
Меня в этом заботит, как уже ранее высказал -- почему вы двое таких умудренных, гораздо более умудренных опытом чем я, этого не понимаете и не можете договорится...
Потому что такой цели не стоит. Почему не стоит - это уже вопрос другой, который я объяснять не буду.
no subject
Date: 2018-04-02 06:14 am (UTC)Герменевтика -- наука очень мощная, факт.
Но,
вы же понимаете что я этого сделать не могу -- потому что именно в этом находится суть противоречия в нашей дискуссии.
И "поменять слова" значит замести все видимые (пускай только мне) противоречия под ковер,
а это уже -- явная арбатовщина.
Я -- понимаю ваше желание победить, вот так с ходу, переразвесив ярлычки.
И если это ваше искреннее и единственное желание, то мне вообще ничего не остается... ну, как в случае с Арбатом.
Но все же, надеюсь, что вам интересно не только "забить мозгами",
но и попробоать в чем-то разобратся...
\\Я не зря просил не использовать слово "рефакторинг". Если начать называть вещи своими именами, всё становится на свои места.
Как я указывал. Рефакторинг НЕЛЬЗЯ свести к "ошибкам дизайна".
Иначе, эти ошибки придется траковать ОЧЕНЬ расширительно.
Вплоть до именования переменных, вплоть до применения отступов и пробелов с табами.
Вы что, реально хотите постулиовать, что использование табов(пробелов) вот в этом месте, вместо пробелов(табов) -- это ОШИБКА? %)
Ну, ежели так, то вы попросут ничем не отличаетесь от Хуана Ганди...
просто вы, как приверженцы разных стилистических школ,
никогда не сможете согасится по поводу "что есть правильно и красиво".
Искать тут, в таком случе, какую-то глубину -- попросту глупо. :(
Обычный холивар "табы вс пробелы".
\\Не так. Мне это ничего не даст. Разговор изначально идёт о другом, а объяснять достаточно запутанные вещи, включая графический дизайн или сценарии для анимации мне совершенно влом.
При таком отношении к делу... остается только удивлятся тому что вы сами удивляетесь "почему меня никто не слушает и не понимает"...
Да ведь ровно ПОТОМУ ЖЕ -- "это мне ничего не даст" и "это долго объяснять".
\\Разговор изначально идёт о другом,
Я, вроде достаточно явно сформулровал, что дискутивной позицией для меня является факт разногласий между вами и Ганди...
Коего причину, разногласия, я бы и хотел для себя уточнить.
И зачем для прояснения этого вопроса привлекать "графический дизайн или сценарии для анимации" -- мне совершенно неведомо и неочевидно.
Наоборот. Явный оверкил.
Тем более. Еще раз напомню -- вопрос был о стилистическом оформлении текста в ASCII кодах... причем даже ограниченного их подмножества.
Ну вот причем тут, каким боком графический дизайн???
Тем более, что я и так, заранее, признал что там ДА, там будут существенны отличия.
\\Не советую летать на самолёте, в производстве которого использован принцип KISS
Ну вот, братья Райт летали... и как бы, ничего, неплохо получалось. ;)
\\Потому что такой цели не стоит. Почему не стоит - это уже вопрос другой, который я объяснять не буду.
Ну... вот тут-то я и вижу противоречия... с вашими собственными словами в приведенной выше цитате, и в одном из постов про "нынешние програмеры как папуасы".
То есть, цель "высказатся так, чтобы ОНИ поняли, и возможно прониклись" - таки стоит.
Но... не соответствует (не)явно декларируемой цели.
Это уже психология.
no subject
Date: 2018-04-02 07:12 pm (UTC)Это не "видимые", это "кажущиеся". Включая дурацкое "ваше желание победить".
мне совершенно неведомо и неочевидно.
Наоборот. Явный оверкил.
И не стоит давать оценку тому, что не понимаешь.
no subject
Date: 2018-04-03 06:13 am (UTC)Это еще Свифт высмеивал, тогдашних натурфилософов "если они сталкиваются с чем-то что не могут объяснить, они называют это -- игра природы"...
Я не знаю... постоянно честно в этом признаюсь (за что и "страдаю", да %) как вот -- "И не стоит давать оценку тому, что не понимаешь.") -- получается, что раз САМ признался что чего-то не знаешь, ЗНАЧИТ сам и дурак, неграмотный и ни в чем не разбирающийся, нафиг с таким спорить, он же получается заранее признался что проиграл %))),
например у меня нет ни одного лично знакомого НАСТОЯЩЕГО ученого,
и я не мог наблюдать как они реально делают открытия, приходят к тем или иным выводам.
Но по тому что пишется в литературе -- это делается через АНАЛИЗ и постоянное тестирование собственных посылок.
Большинство же, данное в ощущениях,
и в инете, и так в жизни -- поступают ПРЯМО ПРОТИВОПОЛОЖНЫМ образом.
Оне бронзовеют. %)
Становятся в позу "есть тольео две Правды -- моя... и неправильная".
Настаивают на использовании ТОЛЬКО их определений.
Банют неугодных, сомневающихся.
И т.д., и т.п., и к.з.п.
А по делу...
я сам тут себя и вообще тред перечитал.
И понял, что у меня ровно вот то же самое.
Что для того чтобы поддержать как-то свои мысли "надо много объяснять"...
а все потому, что нет, не существует некоей выделенной базы,
абсолютной точки отсчета, чтобы все сразу могли с ней согласится и вокруг неё танцевать.
Наоборот, каждый... не, ну не каждый, только "забронзовевший" уже,
считает что точка отсчета -- есть.
И заключается она... в глубоком знании монадок, матана, еще чего-то...
(оно-то может и похоже на правду... но...)
Я пробовал подойти к этой проблеме с другой стороны.
Пусть нет базы чтоб договорится,
но ведь люди таки как-то договариваются.
Может можно это как-то протянуть через мотивацию?
Но и там все глухо. Мотивация такая же рандомная и не поддается рациональному устаканиванию... %(
no subject
Date: 2018-04-03 08:26 am (UTC)когда именно редактрпование текста (ака рефакторинг) по вашему убежденгию превращается в "ошибки дизайна"?
1. на уовне расстановки пробелов и переносов -- думаю это можно отбросить,
учтывая что существуют форматеры кода и некоторые даже утверждают что их надо натравливать на код при каждом коммите. %)
2. на уровне редактирования имени переменной?
то есть, если вдруг программист выбрал "неправильное" имя, то это -- ошибка и его вина???
даже если совершенно не было очевидно, что имя нужно будет менять (код написан в одно время, а потом через долгий период времени, скажем месяц, оказалось что его надо расширить).
3. на уровне выделения функции, устранения дублирования -- тут уже я могу себе представить, что есть какой-то хитрый меотд, подход,
чтобы заранее разложить где, что и в какой функции будет делать,
там дизайн сверзу вниз,
но все равно остаются сомнения...
4. на уровне задания структур и классов, там: где какие поля должны быть, акие функции -- здесь уже легче.
Хотя... а как же эксплорэйтив программинг? а если задачи новые, до того не решавшиеся? другой язык, другие библиотеки.
То есть, изучение того как оно работает -- это тоже "ошибки"?
То есть, получается что программист-кодер, в соответствии с вашими воззрениями -- кругом ошибается, чтобы он не делал. Такой вот патологический неумеха. %)
Априорная установка так сказать...
ну, в принцыпе, в режиме "человек -- источник всех ошибок" как инженерного принцыпа можно было бы даже согласится.
5. на уровне вообще структуры проекта...
то есть, если мы создаем новый проект, а потом оказывается что существующие подходы/структуры нас не устраивают...
или например делаем прототипирование "на выброс",
то это тоже "ошибки"? %)
Ну, в таком случае, тут тоже все довольно понятно -- и сходится тютелька в тютельку с обычным эфэктно-мэнагерским "мы не делаем рефакторинг, потому что нам нужно добавлять функционал".
Ну или кондово-програмерское "Пиши код, б*ь!". %)
Тоже вполне понятно.
no subject
Date: 2018-04-03 09:10 am (UTC)редактрпование текста (ака рефакторинг)
Редак что? Если было "редактирование", то, вообще, какой-то бред получается.
no subject
Date: 2018-04-03 02:52 pm (UTC)"...дабы дурость его была видна".
Я свои "заблуждения" не скрываю под маской "я это знаю, но никому не скажу".
Потому что считаю это контр-продуктивным -- но пейн, но гейн. %)
Только и всего.
ЗЫ Наоборот, много раз встречал людей, и в реале в том числе, которые попрекали меня "заблуждениями"... а сами при это... ну да, не будем о грустном.
\\Редак что? Если было "редактирование", то, вообще, какой-то бред получается.
Замена имени переменной -- это не редактироование?
Или вы уже на том уровне абстракций,
что у вас уже как в (xkcd: Real Programmers https://xkcd.com/378/)
и код вам бабочки "набивают".
no subject
Date: 2018-03-10 03:01 am (UTC)Я допускаю "поэтапное продвижение" как метод, но он должен быть обоснован в описании технологии создания продукта так, чтобы в ней содержалось математическое доказательство отсутствия определенного слоя ошибок после каждого этапа. Плюс, гарантия отсутсвия ошибок в продукте вообще после заключительного этапа. И эта технология должна быть подвергнута аудиту, осуществляемому другими людьми, а не дана на откуп разработчику.
Иначе это все мина замедленного действия для бизнеса.
no subject
Date: 2018-03-10 10:33 am (UTC)Естественно, то что я делаю, может работать только в том коллективе, где специалисты выше среднего уровня, начиная с менеджмента. Задача - найти эффективные способы повышения топовых разработчиков, а не создать методологию для коллектива серости.
no subject
Date: 2018-03-11 01:20 pm (UTC)Ничего страшного, передать можно. Берём - и передаём. А он её - не поддерживает, потому что не понимает, но она и так неплохо работает, без поддержки.
no subject
Date: 2018-03-11 02:15 pm (UTC)Если писать правильно, сложность растёт линейно от количества текста.
Очевидно
Date: 2018-03-21 12:15 pm (UTC)Очень небольшое количество текстов, для которых сложность растет "линейно от количества текста".
Например список покупок... но даже и в нем, все усложняется,
если например выясняется что некоторые его составляющие являются составляющими рецепта, в котором возможна вариативность.
А для программы...
ну, если это последовательный вызов подпрограмм, без ветвления...
точно так же, не думаю что большое количество программ таковому соответствует.
Гуд фор ю, если вы работаете в такой области где именно такие программы.
no subject
Date: 2018-03-11 08:32 pm (UTC)