Диллема при возвращении к старому проекту 1. Продолжить работу с ИЛИ 2- Перекодить дсё уже существ / commitstrip :: Смешные комиксы (веб-комиксы с юмором и их переводы)
Подробнее
Диллема при возвращении к старому проекту
1. Продолжить работу с ИЛИ 2- Перекодить дсё уже существующим кодом
commitstrip,Смешные комиксы,веб-комиксы с юмором и их переводы
Если постоянно так делать, то ты из 2й картинки будешь переходить к 1й. Так что просто пиши свой код так, как будто после тебя его будет смотреть маньяк-убийца, который знает где ты живешь.
Формула успеха не в этом, а в том, что кроме кодинга есть еще куча необходимых процедур. Например документация принятия решений (как минимум), автоматизированное тестирование, фиксация требований, даже если они размытые. "Просто пиши код так, будто ..." - не работает. Это всего лишь часть процесса, и порой не самая важная.
Ни документация, ни тестирование, к сожалению, не спасают от кривых рук. Да это все важно и нужно, да это повышает стабильность и "автобусное число", и вобще фиг ты сориентируешься без всего этого в команде на 10+ разрабов. Но когда нет понимания почему так много говорят про паттерны, солид и прочее - за это надо бить по рукам. Так что надо, Федя, надо. =)
Я не вижу реальной отдачи от слепого следования паттернам и солидам, хотя так или иначе они присутствуют - принципы не из космоса, а кодеры не идиоты. А вот от тестирования и фиксации интерфейсов польза огромная - когда негде ошибиться или подумать о лишнем, архитектура очевидна.
Честно говоря еще не видел кого-то, кто опирался бы тупо на баззворды и выдавал что-то отличное от первой картинки.
Паттерны... Солиды... Просто надо в деревьях разбираться. Ну, или повесить огромный плакат перед собой. Грубо говоря, придерживаться модульной системы (лучше сделать код на 3% менее оптимизируемым по объему, но на 40% лучше оптимизируемым по скорости и куда более понятным). Делать этого мы, конечно, не будем.
Дока архи важна, я тут открыл проект после 2-х лет забивания на него. Кто тот ирод что это придумал ? Чем он руководствовался ? Совсем никакой доки кроме requirements.py
Теперь буду разбираться и писать доку по уже накатанному.
если внешнее поведение программы не поменялась - то таки рефакторинг, даже если внутри не осталось ни одной строчки.
"рефакторинг - процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы"
а вопще это софистика, с т.з. архитектора это таки рефакторинг, а с т.з. кодера - рекодинг.)
В общем-то на первой картинке представлен типичный рефакторинг в середине процесса. Если человек бросит его на полпути, то единственный шанс - это откатиться или начать заново. Полагаю, для местного большинства разработка в режиме рефакторинга - это норма, учитывая, как меня в прошлый раз закидали за критику костылей js-а.
Это, если ты составляешь программу неправильно. Белые люди выносят функции в библиотеки.
А вообще, что ты несешь? Сколько я компилил, никогда ничего не компилилось в несколько этапов. Только, если я ошибку допустил серьезную в коде, и не предусмотрел для неё ловушку, но это совсем другой разговор.
Или, ты говоришь о компоновке? Так это совсем другой процесс. Тогда, да, в два шага. Но если использовать оболочку для написания кода, поддерживающую структуру, то компоновку делать не нужно.
Тебя, похоже, тоже на сишке написали :)
Короче, я нихуя не понял из этого потока сознания. Как наступит прояснение - пиши, обсудим языки и их компиляторы
Я к тому, что указанная проблема имеется только при компиляции древним нативным компилятором. Тогда она происходила таки в два шага (впрочем, только для приложений, имеющий внешние связи, т.е., обращающиеся к библиотекам или выделенным отдельно процедурам).
А дальше я говорил, что если использовать современную оболочку для программирования (типа RAD студии, например, она умеет работать не только с форками С, но и с ним самим), то компиляция происходит точно так же, как на любом другом языке, кроме Явы и её собратьев.
да, компиляция происходит точно так же, тока медленнее
"С - абсолютный и совершенный язык. Лучше него только ассемблер."
Вот насчёт ассемблера спорить не стану. Это ultimate инструмент для оптимизации.
А вот нахера нужен язык, который уже и высокоуровневым считать перестали? С еблей с указателями, c дебильными хедер-файлами, с наркоманским препрроцессингом, без никакой модульности и т.д
Ассемблерные вставки не только в сишке есть.
Ну, на самом деле, он хорош (С) только тем, что весьма гибкий и в базе весьма легкий. Т.е., программы на нем, по умолчанию (без учета кривизны рук), без использования стандартных библиотек весьма легкие и быстрые. А на ассемблере целиком писать что-то солидное - то ещё развлечение.
Если судить по удобству написания широких и тяжелых приложений, то пусть я буду заплеван, но мне нравится Делфи. Есть в паскале что-то такое. Гармоничное.
А так, главная причина для изучения форков С (++ и #, например, как самых известных) то, что 90% программистов, пишущих не для веба тебя за человека не будут считать, если ты скажешь, что пишешь на чем-то отличном от С++ или С#.
Помнишь тот хреновый проект, за который я чне хотел браться*
^ Ты о mow, за который ты ^ запросил в10 раз больше, думая, что заказчик откажется*
перевод,- юишшвшдж
ТАК, ЧТО ТАМ У НАС ТВОРИТСЯ В ЗАХВАТЫВАЮЩЕМ МИРЕ ВЕБ-КОМИКСОВ?..
£91
^ С. У Д
и у \ /1 /
ОЛИН ЧЕЛОВЕК
РОПСЕНШТИЛЬС/
Я, КАЖЕТСЯ, ПОЗНАЛ ТЩЕТУ БЫТИЯ.
ПИСТОЛЕТ В СЛИВНОМ _БАЧКЕ.
Честно говоря еще не видел кого-то, кто опирался бы тупо на баззворды и выдавал что-то отличное от первой картинки.
Теперь буду разбираться и писать доку по уже накатанному.
это называется - рефакторинг
"рефакторинг - процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы"
а вопще это софистика, с т.з. архитектора это таки рефакторинг, а с т.з. кодера - рекодинг.)
почему тогда этот совершенный язык за 1 проход скомпилять нельзя? :)
А вообще, что ты несешь? Сколько я компилил, никогда ничего не компилилось в несколько этапов. Только, если я ошибку допустил серьезную в коде, и не предусмотрел для неё ловушку, но это совсем другой разговор.
Или, ты говоришь о компоновке? Так это совсем другой процесс. Тогда, да, в два шага. Но если использовать оболочку для написания кода, поддерживающую структуру, то компоновку делать не нужно.
Короче, я нихуя не понял из этого потока сознания. Как наступит прояснение - пиши, обсудим языки и их компиляторы
Я к тому, что указанная проблема имеется только при компиляции древним нативным компилятором. Тогда она происходила таки в два шага (впрочем, только для приложений, имеющий внешние связи, т.е., обращающиеся к библиотекам или выделенным отдельно процедурам).
А дальше я говорил, что если использовать современную оболочку для программирования (типа RAD студии, например, она умеет работать не только с форками С, но и с ним самим), то компиляция происходит точно так же, как на любом другом языке, кроме Явы и её собратьев.
"С - абсолютный и совершенный язык. Лучше него только ассемблер."
Вот насчёт ассемблера спорить не стану. Это ultimate инструмент для оптимизации.
А вот нахера нужен язык, который уже и высокоуровневым считать перестали? С еблей с указателями, c дебильными хедер-файлами, с наркоманским препрроцессингом, без никакой модульности и т.д
Ассемблерные вставки не только в сишке есть.
Если судить по удобству написания широких и тяжелых приложений, то пусть я буду заплеван, но мне нравится Делфи. Есть в паскале что-то такое. Гармоничное.
А так, главная причина для изучения форков С (++ и #, например, как самых известных) то, что 90% программистов, пишущих не для веба тебя за человека не будут считать, если ты скажешь, что пишешь на чем-то отличном от С++ или С#.