Кстати хмг с прошедшим др вас! Не успел заметить как вам стало сорок восемь

вообще поймал себя на мысли, что когда пишу код по работе стал делать это сильно медленнее, т.к. раньше особо не думал о том, как, грубо говоря, вписать его в общую нить проекта и разработки

теперь, когда стал задумываться, часто стал ощущать нехватку инструментария для этого - почти нет опыта принятия таких решений (условный уровень middleware по абстракции между архитекутрой и непосредственно кодом) не знаю на что ориентироваться, как в "тумане войны" в стратежке приходится решения принимать

усиленно впитываю, короче говоря, надеюсь, что достаточно навпитываю в короткое время, хотя без офиса это и сложнее

Приложения пишутся сверху вниз, а библиотеки выращиваются снизу вверх как самоценность

Но вообще да, написать этот мидлварь идиоматично та ещё задача

понял!

это скорее простудная тема, хроническое горло никак не может успокоиться после ожога (неумело на ветру перегрел цигариллку и ее дым, соответственно), у меня пока такие случаи довольно редко, будет чаще — отпилю эти проклятые гланды

надеюсь, на далекой дистанции не сильно аукнется

Вроде и придумывать ничего не хочется своего а вроде и надо

Не люблю вводить понятия, всегда при этом чувствую себя педиком

Интересно.
Я сейчас на стадии, когда пишу код быстро, а потом наступает разочарование ("надо было дольше подумать над архитектурой!")
А когда действительно думаю, кажется, что слишком много времени тратится, непропорционально присущей задаче сложности.

Но принцип single responsibility часто требует вводить понятия

Если б я не был хаскеллистом, это было бы смертным приговором, но так как рефакторинг у нас дешев...

вот

меня сейчас стали сильнее цеплять вещи вроде унификации использования библиотек и модульности на контрасте между последними прожектами: в одном была предельная модульность и строгий, но хороший код стайл с отвратным руководством и сомнительной бизнес (прости господи) логикой, а во втором напротив - в одном файле используют две разных стринги, например, и ни одна их них не std

но бизнес логика простая и разумная, а руководство и коллектив предельно комфортные (во всяком случае пока)  

и что делать непонятно, потому что разгребать горы 10+ летнего легаси в данном климате это весьма рисковое решение, но и потакать тяп-ляп рефлексам не хочется, т.к. без строгости в технической части получится что-то невразумительное

мне кажется, или хочется верить, что это надо перетерпеть и тратить сколько хочется - иначе не перешагнуть

но допускаю, разумеется, что могу ошибаться и это работает как-то по-другому

вспоминаю случай, как я с месяц в паралелли работал над крупной фичей в непродуманной стейт-машине (boost::statechart), сам фичу не продумал т.к. подошел к вопросу залихватски и еще не имел возможности ее тестировать

в итоге это превратилось в horrific nightmare, но не у меня, ни у автора оригинальной архитектуры, которого мы тихо ненавидили и открыто критиковали, никаких проблем в итоге не было

он в итоге мою имплементацию перепелил, подстроив требования под себя потому что он "уважаемый человек"
подстроил он их, конечно, логичнее чем было на старте, но осадочек все равно остался

возможно уже рассказывал тут об этом, прошу извинить если повторяюсь

Ну тут мне кажется только один путь. Делать минимальные изменения которые решают задачу, и не строить замков из воздуха. Минимализм это в первую очередь ленивый подход, откладывающий принятие решений( и как следствие создание себе проблем) на неопределённый точку в будущем

Нарисовать на горячую голову можно много чего, но как правило большинство дизайн решений все равно имеют оборотную сторону поэтому лучше отложить

Experience is what you get when your program segfaults. то есть постфактум

я с этим согласен!

в том конкретном случае начиналось все двоольно просто, только потом выяснилось, что оригинальный автор напрототипировал как раз на горячую голову что-то, что потом надо было очень тяжело адаптировать под реальные условия

думаю, если бы вместо работы над какими-то поделиями нам бы дали это реализовывать самостоятельно с нуля, шаг за шагом, то таких бы проблем не было т.к. нужные решения были бы приняты сильно раньше непосредственно этой задачи

Боюсь нужные решения в системной разработке изначально принимать умеют примерно 0 человек в мире)

интересный факт, кстати, что вся вот эта психологическая атмосфера недоверия со стороны руководства на мой взгляд была полностью искусственной для plausible deniability: в проекте ключевую роль занимал специалист, который работал на двух должностях, получая ЗП только за одну.
за вторую его публично все эти менеджеры гнобили, дескать, не справляется и т.д., а в конце проекта по случаю сравнительного успеха взяли все лавры себе и наняли человека на зарплату на, собственно, вторую должность

ну, будь разработка дробленой на кусочки сильно раньше, проще было бы откатить неудавшееся, я к этому :)