- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
#include <iostream>
using namespace std;
const char _Arr_Digit [] = {'0', '1', '2', '3', '4', '5', '6', '7', '8', '9'},
_Arr_Mantissa [] = {'e', 'E'},
_Arr_Sign [] = {'-', '+'},
_Arr_Dot[] = {'.'},
_Arr_Combo[] = {'0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '.'};
const bool DIGIT = false, SIGN = false, OTHER = true;
bool _Call_Mantissa = false, _flag_dot = false, _flag_mant = false;
int _position_mant;
bool Parse_symbol (char _symb, const char* _Arr, int _size_arr);
bool Parse_full_string (string _checking, int _offset, int _amount, bool _sec_cond, const char* _Arr, int _size_arr, bool _Drive);
bool Parse_the_first_symbol (string _checking);
bool Parse_the_second_symbol (string _checking);
bool Control_result (int i, string _checking);
bool Parse_mantissa (string _checking);
bool Parse_full_string_before_mantissa (int i, string _checking);
bool Parse_the_first_symbol_after_mantissa (string _checking);
bool Parse_full_string_after_mantissa (string _checking);
long double Questioning (char s);
long double Questioning (char s) {
string _checking;
while (true) {
cout << "Введите значение " << s << ": ";
getline(cin, _checking);
if (_checking.length() == 0)
cout << "Вы не ввели значение!" << endl;
else if (!Parse_the_first_symbol(_checking))
cout << "Некорректное значение!" << endl;
else return strtold(_checking.c_str(), nullptr); }}
bool Parse_symbol (char _symb, const char* _Arr, int _size_arr) {
for (int i = 0; i <= _size_arr; i++)
if (_symb == _Arr[i]) return true;
return false; }
bool Parse_full_string (string _checking, int _offset, int _amount, bool _sec_cond, const char* _Arr, int _size_arr, bool _Drive) {
bool _parse_flag;
int _parse_count = 0;
for (int j = _offset; j < _amount; j++) {
if (Parse_symbol(_checking[j], _Arr, _size_arr)) {
_parse_count++;
if (_sec_cond) return false;
if (_Drive) {
if (_Call_Mantissa)
_sec_cond = (j == (_amount-1));
if (_parse_flag) return false;
_parse_flag = true;
if (_Call_Mantissa) {
_flag_mant = _parse_flag;
_position_mant = j;
}
}
}
}
if (!_Drive) {
if ((_amount - _offset) == _parse_count) return true;
else return false;
}
else return true;
}
bool Parse_the_first_symbol (string _checking) {
int LENGTH = _checking.length();
bool _parse_cond = (LENGTH < 2);
if (Parse_full_string (_checking, 0, 1, _parse_cond, _Arr_Sign, 1, SIGN))
return Parse_the_second_symbol (_checking);
else if (Parse_full_string (_checking, 0, 1, false, _Arr_Digit, 9, DIGIT))
return Control_result (0, _checking);
else return false; }
bool Parse_the_second_symbol (string _checking) {
if (Parse_full_string (_checking, 1, 2, false, _Arr_Digit, 9, DIGIT))
return Control_result (1, _checking);
else return false; }
bool Control_result (int i, string _checking) {
if (!Parse_mantissa (_checking)) return false;
else if (_flag_mant) {
string _before_mantissa = _checking.substr(0, _position_mant);
string _after_mantissa = _checking.substr(_position_mant + 1);
return (Parse_full_string_before_mantissa (i, _before_mantissa)
&& Parse_the_first_symbol_after_mantissa (_after_mantissa)); }
else return Parse_full_string_before_mantissa (i, _checking); }
bool Parse_mantissa (string _checking) {
int LENGTH = _checking.length();
_Call_Mantissa = true;
bool cash = Parse_full_string (_checking, 0, LENGTH, false, _Arr_Mantissa, 1, OTHER);
_Call_Mantissa = false;
return cash; }
bool Parse_full_string_before_mantissa (int i, string _checking) { // but the first symbol
int LENGTH = _checking.length();
return Parse_full_string (_checking, i, LENGTH, false, _Arr_Dot, 0, OTHER) &&
Parse_full_string (_checking, i, LENGTH, false, _Arr_Combo, 10, DIGIT); }
bool Parse_the_first_symbol_after_mantissa (string _checking) {
int LENGTH = _checking.length();
bool _parse_cond = (LENGTH < 2);
if ((Parse_full_string (_checking, 0, 1, _parse_cond, _Arr_Sign, 1, SIGN)) ||
(Parse_full_string (_checking, 0, 1, false, _Arr_Digit, 9, DIGIT)))
return Parse_full_string_after_mantissa (_checking);
else return false; }
bool Parse_full_string_after_mantissa (string _checking) {
int LENGTH = _checking.length();
return Parse_full_string (_checking, 1, LENGTH, false, _Arr_Digit, 9, DIGIT); }
Follow us!
Сходу проектировать функции сложно если опыта нету.
З.Ы. Если ты не можешь за одну короткую фразу сказать что делает функция или класс -- это неудачная абстракция, попробуй по-другому.
1) Какую-то часть портянки хотелось бы использовать в другом алгоритме или проекте. Научиться подобно Шики видеть линии в коде так, чтобы переиспользовать его, можно тупо делая несколько проектов: рано или поздно встретится задача, которую ты уже где-то решил.
Вообще, на переиспользуемости кода я бы не рекомендовал зацикливаться, по крайней мере на первое время. Код, который стóит переиспользовать, должен быть крайне хорошо реализованным, протестированным и документированным, и он должен быть универсальным. С этими пунктами даже создатели языков стандартных библиотек языков умудряются обосраться.
2) Для упрощения чтения и понимания кода, чтобы составляющие части алгоритма были изолированы и именованы. Зачастую функция будет использоваться только один раз, и это нормально. В этом случае функция, во-первых, даёт имя какой-то части алгоритма, помогая читателю понять, что хотел сказать автор. И, во-вторых, ограничивает область видимости этой части алгоритма.
Допустим, весь алгоритм целиком работает с 30 переменными. Если он написан одной портянкой, то для его понимания нужно постоянно удерживать в памяти состояние всех 30 переменных. Без лошадиных доз риталина (запрещён в РФ) это невозможно. Теперь разобьём его на вспомогательные функции. Допустим, в среднем такая функция на вход принимает 3 переменных и возвращает одну. То есть они работают с куда меньшим количеством информации, и ментальное усилие, необходимое для понимания каждой из них, становится посильным.
1/2
2/2
сепульки
потому что юнит-тесты работают с блэкбоксом и на читаемость им в общем-то насрать
> Я работал в трёх крупных конторах и должность QA была только в одной
- ошибка выжившего налицо, так сказать. Не надо работать в криптоцыганских стартапах
- почему?
на прод можно не каждый коммит, а только тот, который отмечен правильным форматом тега
А почему, собственно, нет, если у тебя stateless мелкосервиc с гринблёй?
stateless мелкосервиc слабо сочетается с ручным тестированием
в мобайле CI/CD никак не мешает мануальному тестированию и я не понимаю даже, как он может мешать-то
ты настраиваешь CI/CD, чтобы при пуше в фича-ветку он делал билд, гонял тесты и выбрасывал артефакт или орал про ошибки красненьким
при мердже пул-реквеста CI/CD делает то же самое, только ещё заливает билд в систему дистрибуции, откуда его могут забрать тестировщики, попутно сря нужными комментариями в слак и джиру
почему раз в неделю?
Если у тебя там не тысяча китайцев в подвале, конечно.
сливает себе билд с этим номером и тестирует
время на тесты мануальщиком после окончания работ программиста заложено для каждой задачи при планировании и учитывается при наборе спринта
ферштейн?
Т.е. в твоём процессе получается, что специально обученный человек прогоняет тесты на артефакте с "integration" и даёт добро на мердж в "stable", и заказчику попадает артифакт со "stable". И где здесь continuous, Desktop?
что там концептуально или нет, мне похуй, мне надо деливерить фичи, а не с концепцией танцы танцевать
1) Ты заделиверил один мёрдж-коммит, и сразу понимаешь, что в нём баг. Откатываешь сервис на один коммит.
2) Ты разом заделиверил 30 фич, одна содержит баг, и две других меняют схему персистентных данных, и их нельзя откатить, ибо старый код сломается о новые данные.
Какой вариант выберешь?
CD не панацея, и есть ситуации, когда его использовать в принципе нельзя (например, если сервис очень stateful, и любой баг в нём может распидорафтить все данные). Но если его можно использовать, его стоит использовать.
я не утверждаю, что CI/CD не нужен, я считаю, что он нужен
я говорю, что он не отменяет возможность ручного тестирования
деливерить можно не только лишь на прод
если ты на прод заливаешь 30 фич, переинтегрированных между собой, то у тебя на это есть причины - очевидно, 30 фич осилились не за 30 спринтов, а за 1 (один, карл), т.е. скорее всего продукт молодой и активно запиливается
гораздо сложнее для молодого продукта тестировать каждый коммит, тормозя остальные 29, это дорого и зло - не важно кто будет тестировать этот коммит, твои тестеры, наемные тестеры, волонтеры или заказчик
Первая проблема: у тебя 30 коммитов, а не один. Нужно понять, в каком из них баг.
> если ты на прод заливаешь 30 фич, переинтегрированных между собой (не обязательно! прим. редактора), то у тебя на это есть причины - очевидно, 30 фич осилились не за 30 спринтов, а за 1 (один, карл), т.е. скорее всего продукт молодой и активно запиливается
...Или старый, большой, и монолитный и его пилят 5 команд со своими спринтами.
> гораздо сложнее для молодого продукта тестировать каждый коммит
Больше инстансов дженкинса, больше параллельности тестов.
звучит как проблема на 10 минут, если честно
если ты смотришь в код и не понимаешь как так случилось, то даже зная в каком коммите проблема ты потратишь ~ столько же времени
потому что не исключено, что вскрытая проблема вообще не связана с этими коммитами, а живёт в проде уже пару месяцев
> Больше инстансов дженкинса, больше параллельности тестов.
заказчик должен параллельно 30 версий прода запускать в работу? а потом слать отчеты, что "вот у меня тут как-то не всё работало в 14:18 в среду"?
Если у меня один коммит, и после его деплоя прилетает алярм, что количество 500х ошибок выросло на 1%, то я не смотрю в код. В принципе. Я откатываю деплой, и смотрю на логи и код потом в тихой и спокойной обстановке. Или кубернитис это сам делает, останавливает гринблю и меня пингует в ёбаном мессенджере на электроне. Смотреть в логи и код, пока прод подгорает, я тоже умею, но нахер мне такое удовольствие.
ошибка 500 это не единственный признак "ПО работает не так как мы ожидали" и даже близко не
особенно в кейсе @Desktop, который деливерит мобильное приложение
если что, я не оппонирую, мне наоборот интересно где можно (нужно) улучшить наши внутренние процессы
Ну естественно. Но если исповедовать религию "let it crash", то это хорошая аппроксимация.
У заказчика есть только REST API. Нахер ты ему билды своих облачных микросервисов отдаёшь?
а ты "только рест апи"
> Сейчас в заднем конце всюду `CI/CD',
(D as deployment)
xD
Ну видимо требования по персональным данным или ещё какой-нибудь секретности, что заказчик должен на своей инфраструктуре крутить.
Ну так это совсем другая ситуация. Тут концептуально появляется понятие релиза, планирования релизов и т.д., и continous deployment улетает в трубу.
Как мне написать автотест, чтоб он проверял что вот такой-то код на сишке на таком-то STM32 говноконтроллере с такими-то эрратрами будет настраивать вот такой-то кодек (настраиваемый через через I2C шину и передающий-принимающий аудиосемплы в дуплексном решиме по шине I2S) и это будет нормально работать?
З.Ы. Ну или даже эхо-тест через перемыку, раз он и передаёт и принимает.
Автотесты ж нужны для какой-то часто меняющейся и хитрым образом переплетенной питушни, когда изменения хуйни1 может влиять на работу хуйни2 самым неочевидным образом.
Либо если сложная логика, все ветки которой заёбывает проходить вручную.
Ничего вы не понимаете в комфорте. Свои пет-проекты, к примеру, я всегда пилю спросонья, либо усталым, и порой люблю их рефакторить, чтобы не воняли. Я бы в жизни не стал этого делать, если бы не был уверен, что если CI прошёл, то ничего тривиального не сломалось. Ну и руками что-то тестировать мне лень, не барское это дело.
Ну или по работе импелементацию какого-нибудь stateful асинхронного протокола с шестью версиями и десятком полей тоже попробуй руками протестируй. А так один раз написал property-based тестбед с инжекцией ошибок и течёшь. Вкалывают роботы, а не человек.
Ну мы тут про людей говорили, вроде.
Ну если эта стабильность важна, конечно.
"10 hours of HEYYEYAAEYAAAEYAEYAA"
Кубернетис против реального железа -- это как надувная тян против подушки.
они вполне себе виртуаляца уже, вон я недавно про single root I/O virtualization читал: писи ай экс пресс умеет реально вротуализировать тебе несколько сетевых карт (виртуальных функций)
И лики сишного аллокатора?
Знаете, что такое безысходность?
Это когда берешь стабильную слаку, а докера там нет.
Ставишь slackbuildы со всеми сорока зависимостями, но поставив go, забываешь перечитать профайл, и в PATH у тебя вместо go -- gcc-go, и сборка докера падает от отсутствия понимания параметра buildmode.
Потом ты всё таки ее собираешь, и ставишь docker-compose (собрав еще 10 зависимостей), но он 2018-го года, и не понимает Compose Specification.
Ты пишешь автору слак билда "could u please upgrade хуё-мое", и получаешь ответ от мейлер демона, что такого мыла нет.
Каждый месяц кто-то пишет на LQ "а вы видели ченджлог каррента? кажется, скоро у нас будет 15!"
Каждый месяц последние три года.
Но самое смешное, что докера в карренте нет. И нгинкса нет. И постгри. И node.
Зато есть PHP, Apache и squid. Всё хочу спросить у Патрика как ему там в 2006-м?
Скоро у нас будет 15 лет без релиза?
Да проще из генты ебилд спиздить, чем разрабам писать...
Серверный софт всё-таки не десктоп, достаточно чтобы ядро да либцы прокатили.
Если ты каждую прогу с её зависимостями в отдельный каталог в /opt'е складываешь, конечно. Стандартную помоечку в /lib заебёшься поддерживать если ты не Патрик.
но зависимости нужно хендлить вручню: к примеру поставить слакбилд с go, чтобы собрать им слакбилд с докером
В этом и проблема. Невозможно адекватно мейнтейнить стандартную юниксовую помоечку самому. У тебя нет времени и ресурсов на сведение версий либ к общему знаменателю, тестирование совместимости и т.п. Сам же пишешь, что часть слакбилдов морально устарела и не поддерживается. Да и мартышкин труд, т.к. в других дистрах всё это уже сделано за тебя.
Установка каждой программы (программы в смысле "продукта", а не "бинарника") в отдельный каталог вместес нужными ей либами позволяет снизить интерференцию между софтом и хоть как-то выжить. По сути docker way без докера. Я когда-то слаку так и админил.
Пока в Слаке было три пакета в 1997-м году, он справлялся, а современный юникс требует сотен программ и либ, и можно крянкуть.
Я правда не понял, чем отдельные папки лучше slackbuilds.
Авторы слакбилдов гарантируют тебе совместимость с версией дистра (хочется так думать).
Слакбилды так же умеют себя удалять.
Если ставить в каждую папку вручную, то придется потом ldconfigу рассказывать про либы, не?
Но вообще проще всё запускать в докере, и течь.
Кстати, идею зависимостей породили бздуны.
Сначала у них был только тот софт, что шел в комплекте с ОС (ну как в слаке), но потом они завезли порты с зависимостями, и стало можно поставить софт, которого в стандартной поставке нет, и не ебаться с его зависимостями
Это ортогональные вещи. Я против установки самосборного говна в /lib. А слакбилды норм, если их подтюнить немного и сменить префикс.
> придется потом ldconfigу рассказывать про либы
Ни в коем случае. Убьёшь весь профит от изоляции.
>ни в коем случае
а, так ты за то, чтобы вручную в petuh1 и petuh2 поставить нужную им версию libkurochka?
когда я устанавливаю софт методом аутоконф configure make make install, то конечно я его ставлю в /usr/local/petuhsoftname
Я за сборку каждой софтины (postgres, nginx и т.п.) со своим независимым префиксом. Ну и все либы, которые им нужны -- прям к ним в этот же префикс. В худшем случае LD_LIBRARY_PATH в ланчере придётся добавить.
Это та же самая идея, что сейчас во всяких virtualenv и докерах исповедуется.
А упаковать этот каталог в tgz и ставить через пакетник никто не мешает. В случае слаки тут ещё один профит -- получается ОДИН пакет без зависимостей.
пусть там будет голое ядро, и каждый софт в своем докер контейнере... как в корос
А оно к тому и идёт, походу. На серваках везде докер. На десктопах шаттлврот свой snap пропихивает. На телефонах тоже всё изолировано.
Дальше поддерживать /lib -- это тупиковый путь, имхо. Это было круто и удобно в своё время, но сейчас от этого одни проблемы.
Да и админкам нравилось обновить либу и "пофиксить" сразу кучу софта.
Забавно, что первыми адовость этого говна осознайли майки со своим "dll hell", когда пользователя спрашивали хуйню
Еще Чен смеялся над вопросами установщика типа "вы хотите заменить petuh.dll 2.2.3.3 версией 2.2.3.4?".
Замени, и молись, чтобы ничего не упало нигде.
Прыщевикам было чуть проще, потому что весь софт ставился из единой дырки.
Майки завезли SxS еще двадцать лет назад, просто мало кто пользовался
Ну вот и остальных это конснулось
Угу. Ну и security фиксы обычно минимальные и ничего не ломают, поэтому минорное обновление либы таки прокатывает.
А вот какую-то фичу, нужную свежему софту, ты будешь ждать полгода до следующего релиза. Или пять, лол, если ты сторонник стабильности.
но можно сказать, что использование только системного говна дает тебе стабильность. Если я хочу например собирать SNMP с железок и выводить результаты в каком нить MRTG, то мне в общем всё равно какая у меня версия nginx.
А если я буду врунчую запускать докер контейнеры, то вынужден буду не забывать их обновлять бо security, и еще настраивать
Ну есть же софт, который мониторит версии говна в контейнерах и предупреждает про уязвимости в нём.
> дает тебе стабильность
И отбирает гибкость, заставляя тебя выбирать между "всё стабильное" и "всё свежее". Хотя, по-хорошему, тебе надо всего пару свежих прог, а остальное могло бы быть стабильным.
Вообще я бы сказал, что есть три разные задачи:
* Сервер приложений, версии софта на котором выбирает РАЗРАБОТЧИК
* Сервер сервисов сети или просто сетевой инфраструктуры, софт на котором выбирает АДМИН
* Рабочая машина ПОЛЬЗОВАТЕЛЯ
Все три сценарии могут требовать разного.
Docker однозначно лучше для первого, и какой-то SNAP для третьего. А вот для второго возможно что ничего этого не нужно
До первого случая, когда тебе понадобится свежий софт. А потом Сёма себе роутер убивает по советам с форумов, лол.
ну админы же как-то живут с тем, что для поддержки нового RFC нужно менять версию винды, или там ios, и их это не смущает.
Вот если админ скажет разрабу "мы не можем перейти на новую версию питона, потому что ее нет в дистрибе" это пиздец, лулз, зашквар, и PHP4 на шаред хостинге.
Не знаю, если честно. Может быть в 2020 году и не понадобится. Для стандартных задач, где можно просто стандартную коробку в духе циски купить и течь.
Ну не. Прикрутят очередную хуйню, без которой твои письма пойдут в спам, и весь сервак обновлять?
openldap и какая-нибудь файлопомойка с самбой -- ну х.з., наверное.
А хрень для мониторинга -- отличный кандидат для запуска в контейнере. Тогда её можно будет обновлять реже чем сам сервак.
ну вот я ставлю говно для мониторинга. Из паетного манагера оно само подымит мне веб сервер, скриптуху на коей писана со всеми зависимосиями, какое нить rddtool, и все нужное говно, да еще и настроит частично само.
А с докером что? Мне или докер компост писать, или делать фет контейнер вручную?
> фет контейнер
Как что-то плохое. Ты вон вообще в систему проги ставишь ;)
Так это и будет фэт.
>как что-то плохое
Ну по какой-то причине за это ругают. Я как-то в одном проекте запустил django, cron и gunicorn в одном контейнере, так на меня девопсы до сих пор пальцем показывают.
Алсо, фэт контейнеры должны иметь init (pid 1) процесс по идее, иначе могут быть зомби. Наражаешь детей, да помрешь. А кто их похоронит?
goto тоже ругают... Но между установкой говна в систему и фет контейнером выбор по-моему очевиден.
З.Ы. Я думаю, за установку джанги без контейнера эти девопсы тебя вообще бы обоссали.
В моем случае вариант с системой и не канал, кстати: мы деплоились докерфайлом на aws. Там конечно можно вручную всё положить на VPS, но AWS может её в любой момент убить
А для адекватного контроля детей мы однажды сделали контейнер, где фореграунд процесс был системд, лол. Но насколько я помню, там уже было как раз проще поебаться с системд, чем нагородить большую помойку не совсем классических контейнеризуемых сервисов
Наш фет был продиктован выбором крона.
Допустим, твой сервис должен каждую минуту нести яйцо.
Если он писан например на жаве или net, то он работает постоянно, и можно (например библиотекой quartz) это красиво решить.
Если же ты скриптушок, то красивое решение это API. А в соседнем контейнере хертбит сервис, который каждую минуту дергает API.
Можно это всё обмазать celery или другим каким-то queue, и потечь.
Но это всё слишком сложно для тупого приложения.
Потому мы сделали как PHPшники: крон сервис, который дерагет наш скрипт раз в минуту.
В джанге даже есть удобный API для этого: пишешь функции, расставляешь аннотации типа "звать раз в час", главное снаружи чтобы кто-то точку входа дергал по крону
У меня паук на ngk через uwsgi мулов крутился, никаких кронов там не было.
Да и просто так контейнер с долгоиграющим скриптом можно поднять...
ну вот есть кнтейнер с джангой, там нужно дергать python manage.py итд
Хотя возможно увизги бы нам помог
Больные ублюдки. Чем supervisord не подошёл? (Ну или любой другой легковесный супервизор, тысячи их)
Думаешь, супервизорд подойдёт?
Какой микросервис )))
Девайс стартует без хостовых иксов, докер делает всё остальное.
В составе k8s может ещё да, а вот голый Dockerd с компостом держать на долгоживущих хостах — такое. Мне несколько раз приходилось чистить вилкой /var на старых дев-хостах с ним, ибо долгоносик^W докер в нём пожрал всё место под логи или какую-то другую питушню.
Но да, все когда-либо сталкиваются в первый раз с этим.
О, ништяк, команда стала ещё проще
Кстати, в центос 7 есть редкая бага в systemd-journald, которая при активном наполнении логов тупо мемличит. Журналд может и десяток Гб рам нажрать таким образом
ты прав, я наверное зря доебался
Дык можно как в SxS расшаривать и трафик и место и память если так вышло, что двум прогам нужны одинаковые либы. Если более-менее одинаковые версии либ во все пакеты пихать, то норм будет. Что-то отстанет, что-то обгонит, но в среднем будет шариться.
Если у меня два Dockerfile импортируют одного родителя, то он один качается, а потом они оверлапятся на него вроде
docker-compose, ты не повериш, скачивается прямо отсюда:
https://github.com/docker/compose/releases/download/1.27.4/docker-compose-Linux-x86_64
это вот прямо эльф, со всем говном статически линкованный, и зависящий только от ядреных вызовов
Это же go:)
но я же хотел красиво
Граница между функциями должна проходить в логичных, простых местах, чтобы каждую из них можно было в отдельности рассмотреть и понять, не подглядывая в код соседних. А не просто потому что 10 строк или 30 переменных набралось.
Кстати да. Парсинг какого-то одного символа - более мелкая операция, которая входит в состав парсинга всей строки.
Соответственно, читатель ожидает, что
1. Parse_the_first_symbol парсит один символ, а Parse_full_string - целую строку,
2. Parse_the_first_symbol будет какой-то вспомогательной функцией в составе Parse_full_string.
А в коде автор даёт читателю ложную информацию и усложняет чтение кода. Разбиение на функции становится только обузой: чтобы разобраться в одной функции, приходится читать почти весь код, что эквивалентно чтению кода, если бы он весь был в одной функции.
bad code matters
А если в них ткнуть курсором — код развалится?
Разработанный кругозор.