dborovikov

FreePascal или Google Go

Вот хорошая книжка: www.ozon.ru/context/detail/id/5039902/ Чуть подучитесь, освойте какой-нибудь простой популярный язык (Java или PHP) и устраивайтесь юниором, там уже поднатаскаетесь и сориентируетесь как дальше.

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

Да и забыл. Наиболее актуальной книгой по ООП-проектированию, что мне попадалась на глаза является книга Эванса «Domain Driven Design». Буча я читал и у меня сложилось впечатление, что он очень плохо описал как все это можно применить на практике, иначе говоря не описал всей методологии разработки а рассматривает все на каких-то гипотетических примерах.

Применительно для веба процедурный стиль вполне уместен. Впрочем, я почти не видел веб-приложений не в процедурном стиле несмотря даже на то, что есть там есть классы, ибо классы эти в основном описывают объекты без состояния вроде контроллеров и сервисов, в которых 95% логики. А писать метод create_order внутри класса OrderService или писать процедуру create_order внутри модуля ordering особой архитектурной разницы не имеет. Почитайте про MVC. На три слоя поделить можно и с процедурным подходом. Хоть это деление и приписывают ООП, но его можно найти в любой парадигме.

Что касается идеи сделать методы save/create/update/delete у модели юзер — это те редкие примеры применения ООП, которые все таки используются. Такое решение называется ActiveRecord. Если у вас нету библиотеки-ORM, то советую не отходить от процедурного же паттерна DAO (почитайте про него). Помните, то процедурное программирование, которое используете вы совсем не то, что ругают в книжках, так как perl по крайней мере динамический язык.

Основная функция программиста — думать и записывать результаты раздумий в некой формализованной форме (коде). Как вы будете учиться думать: развивая мозг на изучении математики или еще как — дело ваше. Важно лишь то, что никакие супер знания не заменять способности быстро и продуктивно мыслить.

Мое мнение — никогда не используйте assert-ы в коде, так как место их в юнит-тестах. Да и код загромождают да.

Красивое название SRP всего лишь синоним сильного сцепления — одной из двух составляющих модульности на ряду с низкой связанностью. Можете постыдить коллегу, сказав что его код не модульный. Если он начнет гнуть в сторону того, что ему не нужна модульность, попробуй прибегнуть к аргументу, что его код не читабелен. Обычно плохо понятный код подвержен ошибкам более, чем чисто написанный. Объясняется это так: человек способен держать в памяти одновременно лишь ограниченное количество объектов, причем только в одном контексте. Таким образом, перемешивание контекстов (нарушение SRP) ведет к багоопасному коду.

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

Если данные строготипизированные и строгоструктурированные, то Protobuf. Если формат не очень строгий, то JSON лучше подойдет.

Советую как можно скорее приступить к «бою». В режиме обучения можно до конца жизни просидеть. Просто смиритесь, что вначале вы будете писать плохой код, зато потом все лучше и лучше. А теорию потом подтянете, когда будете в «теме».