🔥Declarative UI Frameworks

✅jetpack compose

@Composable
fun MyComponent(
    displayString: String
) {
    Text(displayString)
}

✅swiftui

struct MyComponent: View {
    var displayString: String
    var body: some View {
        Text(displayString)
    }
}

✅Flutter

class MyComponent extends StatelessWidget {
  final String displayString;

  MyComponent({required this.displayString});

  @override
  Widget build(BuildContext context) {
    return Text(displayString);
  }
}

🔥بنظرم فلاتر با فاصله ی زیاد قشنگتره و زبان دارت، زبانی مناسبتر برای این هدف

🟢شما هم میتونید نظرتون رو بگید...

@purecoder_ir

🔥Backend Frameworks

✅Asp.net Core

[Route("api/[controller]")]
[ApiController]
public class GreetingController : ControllerBase
    {
        // GET api/greeting
        [HttpGet]
        public IActionResult Get()
        {
            return Ok("Hello from ASP.NET Core!");
        }
    }

✅Laravel

class GreetingController extends Controller
{
    // GET /api/greeting
    public function index()
    {
        return response()->json('Hello from Laravel!');
    }
}

Route::get('greeting', [GreetingController::class, 'index']);

✅Spring Boot

@RestController
public class GreetingController {

    // GET /api/greeting
    @GetMapping("/api/greeting")
    public String getGreeting() {
        return "Hello from Spring Boot!";
    }
}

@purecoder_ir

🔥Backend Frameworks

✅Vania

class GreetingController extends Controller
{
    // GET /api/greeting
    Future index() async
    {
         retuen Response.html('Hello From Vania');
    }
}

Route.get('/greeting',GreetingController().index);

✅Nestjs

@Controller('api')
export class GreetingController {
    @Get('greeting')
    getGreeting(): string {
        return 'Hello from NestJS!';
    }
}

✅Ruby on Rails

class GreetingController < ApplicationController
  def greeting
    render json: { message: 'Hello from Ruby on Rails!' }
  end
end

Rails.application.routes.draw do
  get 'api/greeting', to: 'greeting#greeting'
end

@purecoder_ir

🔥 Test Frameworks

✅XUnit (C#)

public class CalculatorTests
{
    [Fact]
    public void Add_TwoNumbers_ReturnsSum()
    {
        // Arrange
        var a = 2;
        var b = 3;

        // Act
        var result = Add(a, b);

        // Assert
        Assert.Equal(5, result);
    }

    private int Add(int x, int y)
    {
        return x + y;
    }
}

✅JUnit (JAVA)

class CalculatorTests {

    @Test
    void add_TwoNumbers_ReturnsSum() {
        // Arrange
        int a = 2;
        int b = 3;

        // Act
        int result = add(a, b);

        // Assert
        assertEquals(5, result);
    }

    private int add(int x, int y) {
        return x + y;
    }
}

✅Dart

void main() {
  test('add_TwoNumbers_ReturnsSum', () {
    // Arrange
    final a = 2;
    final b = 3;

    // Act
    final result = add(a, b);

    // Assert
    expect(result, equals(5));
  });
}

✅بهترین و مدرن ترین گزینه xunit هست. JUnit وصله پینه زیاد داره و با فرهنگ حال و حاضر مچ نیست‌، ولی قابل قبوله و همچنان یه گزینه خوب محسوب میشه.

✅دارت شبیه JUnit هست.

@purecoder_ir

پترن ها مثل الفبا و زبان مشترک کدنویسی هستن.

توسعه دهنده های فریمورک ها باید به همه ی اون ها مسلط باشن و تجربه ی کافی در استفاده از اون ها رو داشته باشن.

بدون تسلط کامل به همه ی اونها امکان توسعه ی فریمورک خوب وجود نداره و با درک اون ها، درک فریمورک های استاندارد راحت میشه چون که همگی از یک زبان مشترک پیروی میکنن.

فریمورک های خوب رو از طریق نحوه ی استفاده شون از پترن های استاندارد تشخیص بدید.

پترن ها در جریان همین توسعه ها و چالش ها ابداع شدن و کاملن از دل تجربه بیرون اومدن و من درآوردی نیستن.

@purecoder_ir

یه بنده خدایی بود چندین سال پیش آموزش معماری کلین میداد ( الان خدا بیامرز شده و اصلن نیستش، نگین داری مدرس ها رو بدنام میکنی)

این بنده خدا برای هر موجودیتی چنتا کلاس کپی کپی هم می‌ساخت و توی لایه های مختلف میذاشت...

مثلن
UserDo
UserData
User

اون که پسوند Do داشت رو میذاشت توی domain و اون که Data داشت هم که مشخصه و اون که هیچی نداشت هم توی view.

نمیدونم چرا خدا بیامرز از کلمه ی Do استفاده می‌کرد.
ما هم کپی میکردیم و مثل اون میرفتیم😂😂

@purecoder_ir

برق که میره اینترنت قطع میشه، وسایل گرمایشی کار نمیکنن، آب قطع میشه و ...

معلوم میشه اینا خوب دیزاین نشده و خیلی بهم دیگه دپندنسی دارن😳

خونه ی ما تلفن هم قطع میشه 😳 دپندنسی ها خیلی زیاده

تقصیر دولت نیست، اینایی که خونه ها رو دیزاین کردن مقصرن😳

ایسوس هم مقصره که باتری لبتاب هاش انقدر بیخودین😳

@purecoder_ir

توی اپ مون قراره برای کاربران پیامک ارسال کنیم برای این منظور قراره از ارائه دهنده های سرویس پیامک مختلف استفاده کنیم.

مثلن sms ir و ملی پیامک و ‌...

در نتیجه ی کش و قوس های فراوان تصمیم میگیریم که یه اینترفیس بذاریم و بعدش کلاس های مختلف داشته باشیم که implement اش میکنن ( برای هر ارائه دهنده ی سرویس پیامک یک کلاس)

توی بعضی آگهی های استخدامی مثلن میزنه به توسعه دهنده ی ارشد یا توسعه دهنده ی سنیور نیاز داریم و میزان حقوق رو ۲۵ تومن میزنه یا ۳۰ تومن میزنه یا ....

ممکنه در نگاه اول به ذهنت بیاد که کدوم سنیوری ۲۵ یا ۳۰ میگیره؟

توجه به یک نکته اهمیت زیادی داره که این واژه ها تعریف مطلقی ندارن و خیلی نسبی هستن و تعریف تو از ارشد و سنیور ممکنه با تعریف یه نفر دیگه تفاوت داشته باشه، پس به جای تمرکز کردن روی عنوان اگهی، نیازمندی ها و توضیحات آگهی رو بخون و با توجه به اون سبک سنگین کن که میرزه یا نه.

حتا بعضی مواقع بعد از مصاحبه باید تصمیم نهایی رو بگیری.

حتا ممکنه به ذهنت بیاد که من ارشد و سنیور نیستم و آگهی رو بیخیال شی.
باز هم تاکید می‌کنم که تعاریف متفاوت هست، نیازمندی ها رو ببین و با توجه به اون ها تصمیم بگیر که تو مناسب اون موقعیت هستی و یا نه.

این داستان از اون طرفش هم هست، مثلن ممکنه که بزنه توسعه دهنده میدلول لازم داریم و تو پیش خودت بگی من که سنیورم و برام افت داره رزومه بفرستم. ممکنه توی دنیای خودت سنیور باشی و جاهای دیگه ... .

@purecoder_ir

🔥SQL

توی کوئری های پیچیده، دونستن این ترتیب برای اینکه بدونیم داره چه اتفاقی میوفته مهمه...

@purecoder_ir

بنظرتون این نام گذاری خوبه؟

foreach(var s in students)
{
    //....
}

درصد قابل توجهی گفتن که این نام گذاری خوب نیست.

احتمالن بخاطر مخفف بودن این رو گفتن.

درحالیکه این نام گذاری خوبه و ایرادی نداره.

توی نام گذاری باید به اسکوپی که اون variable استفاده میشه دقت کنیم. اینجا قراره توی یه اسکوپ کوچیک استفاده بشه و نام هاي کوچیک و جمع و جور خیلی هم مناسب هستن و فهم کد رو سخت نمیکنن.

در واقع برای کلین بودن کد باید خود بدنه ی for کوچیک باشه(تا جای امکان یک خطی باشه)

حتا میشه از نام های دیگه استفاده کرد.

مثل x

خیلی هم بهترن و همه ی Loop ها رو شبیه به هم میکنه و به راحتی ابجکتی که داره پیمایش میشه رو تشخیص میدیم.

توی کل کدتون از یه قرارداد ثابت استفاده کنید.

@purecoder_ir

❓آیا فقط برای لیست ها هست؟

✅خیر.

✅هر دیتااستراکچری که داشته باشیم، حتا یه Tree، میشه از این پترن براش استفاده کرد تا بدون اینکه ساختار داخلی خودش رو به بیرون درز بده, الگوریتم دلخواه خودش برای پیمایش کردن Element خودش رو پیاده کنه و همچنین همه ی دیتااستراکچر ها یه زبان مشترک داشته باشن.

✅دیتااستراکچر هایی که این پترن رو پیاده کرده باشن میتونن توی for loop قرار بگیرن...

@purecoder_ir